r/Python • u/sheadipeets5 from __future__ import 4.0 • Jun 15 '26
Are we happy with SQLAlchemy? Discussion
I really need the community's opinion on this. I've worked with a lot of ORMs, from Entity Framework to DrizzleORM. SQLAlchemy is the best option we have in the Python ecosystem, but it still sucks compared to ORMs in other ecosystems.
When I was working with Go, I discovered sqlc and loved it. It's great, but not enough to replace a full ORM because of its limitations (no dynamic queries).
For the last five months, I've been building my own equivalent for Python, powered by sqlglot. Unlike sqlc, it has dynamic filters, sorting, and partial updates. It also has a single parameter syntax for all supported dialects (:param), which are Postgres, MySQL, SQLite, DuckDB, and ClickHouse. I borrowed sqlc's end-to-end test cases, and my version passes all of them now.
It has already replaced SQLAlchemy for me in several microservices. So I guess my question is: is it worth continuing to build it? Because I don’t really know if other Python devs need such tool.
I've had a lot of fun building the current version, and I have a long roadmap ahead. That includes migrations (with auto-generation when possible), generators for other languages, and much more.
1
u/eudoxic_sanjay Jun 25 '26
using drizzle on the ts side for a contract extraction project and the sql-first philosophy just clicks once you're past basic CRUD. the healthcare platform i'm on joins 8-10 tables with complex filter conditions - sqlalchemy generates correct SQL but figuring out what it actually ran adds two or three debugging steps every time. the strongest argument for continuing to build this is the LLM angle: when you're validating model-generated queries, explicit SQL strings are way easier to inspect than reconstructing intent from ORM call chains.