Hacker News Reader

Comment by Daishiman | Hacker News Reader

They all say that until your business logic is so convoluted that maintaining several dozen SQL queries begets more work than sensible so you end up inventing your own query builder which is fine until you realize you really need business objects so you make up your own ORM and then you realize you needed SQLA or some similar piece of tech all along.

Tale as old as time.

View on HN

I agree and I've seen a similar argument a few times before. All of those times had the same ending.

SQLAlchemy is a beast for sure. But the complexity is not for fun. It gives you a lot in return. If your needs are simple, it's probably overkill. And this library is not for running queries, it's an ORM. Which has a component that will eventually need to send the queries to the database but it's a lot more than that.

You're not entirely wrong. But SQLAlchemy's approach and design are still awful and confusing. There are much, much better tools/libraries out there.

I don't disagree that it's tremendously overpowered. You can use SQLModel with FastAPI if you want a more minimal API surface that uses SQLA under the hood. As a user I just don't have to deal with most of its complexity on a day to day basis so it doesn't bother me and I don't think it's a bad end state for a swiss-army knife of a query library.

Well, neither SQLModel nor FastAPI existed at the time. So those weren't really options. And SQLAlchemy was still many years away from v2. So whatever it has done in the meantime to improve (I honestly have no idea) was not part of the library at the time.

Reply on news.ycombinator.com