I've used several ORMs and database tools, including Entity Framework, DrizzleORM, and Go's sqlc. SQLAlchemy is probably the most capable option in Python, but I often find it more verbose and difficult to reason about than tools in other ecosystems.nnFor the past five months, I've been building a Python alternative inspired by sqlc and powered by sqlglot. It keeps SQL explicit while adding dynamic filters, sorting, and partial updates. It also uses one parameter style across PostgreSQL, MySQL, SQLite, DuckDB, and ClickHouse. I adapted sqlc's end-to-end tests, and the implementation now passes them all.nnIt has replaced SQLAlchemy in several of my microservices, and I'm considering continuing development. Planned features include migrations with automatic generation where possible, support for additional languages, and other code-generation features.nnDo Python developers actually need a tool like this, or does SQLAlchemy already cover the important use cases well enough?
4 Answers
SQLAlchemy is still the most complete and battle-tested option in Python. Its Core and ORM can be used separately, which is a major advantage: you can build composable queries without committing to the full session and mapping model. It may feel verbose, but that verbosity gives you control over generated SQL, dialects, transactions, and unusual database features.
The strongest argument for continuing is not that everyone dislikes SQLAlchemy. It’s that you’re solving a different problem: explicit SQL with generated Python types, consistent dialect handling, and support for dynamic query pieces. That could appeal to teams coming from sqlc, people working across multiple languages, and projects where generated or reviewed SQL matters. Keep the scope focused, publish side-by-side examples, and measure generated SQL, performance, migrations, and onboarding time against SQLAlchemy.
I’d avoid positioning it as a universal ORM replacement. Showing a few concrete cases where it is simpler or safer will be much more convincing than arguing that SQLAlchemy is generally bad.
There’s definitely a real niche for a SQL-first, type-safe tool. A lot of teams prefer writing SQL directly because it is easier to inspect, optimize, and review than a long chain of ORM expressions. Generated models and checked parameters could provide the safety and convenience people want without hiding the query itself. Dynamic filtering is the difficult part, so that is probably where your project needs to be especially clear and predictable.
I’d also look closely at joins, eager loading, pagination, transactions, and the N+1 problem. Those are the areas where a simple code generator often becomes complicated once applications grow.
I’m generally happy with SQLAlchemy, but I mostly use Core rather than the ORM. The newer select-and-where style is readable, and it handles dynamic conditions well. For small CRUD services, SQLModel or a simpler ORM can be more approachable; for complex systems, many teams either use SQLAlchemy Core or write parameterized SQL directly. Your approach could be useful if it makes those choices easier without trying to replace every feature SQLAlchemy has accumulated.
That matches my experience: the biggest difference is less about whether SQLAlchemy works and more about how much abstraction and configuration a service needs.
That’s fair. I’m trying to keep the explicit-query benefits while reducing the amount of runtime machinery and handwritten mapping code. The main question is whether that difference is valuable enough to justify another project.