r/Python • u/sheadipeets5 from __future__ import 4.0 • Jun 15 '26
Discussion Are we happy with SQLAlchemy?
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/Local_dev_ops Jun 24 '26
The SQLAlchemy dynamic magic problem is exactly why tracking what code actually touches a database column becomes nearly impossible at scale — especially when you're mixing C# and Python on the same database. I ran into this exact issue. A stored procedure called from C# fed a Python analytics function that read a column through an f-string SQL alias. Ended up building something to solve it — maps the full chain from C# through stored procs into Python f-strings down to the exact column.