That's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI
Alembic is certainly a bit of a challenge to grasp at first, especially if you want to do anything more complicated than create or alter tables. However, it does provide a great amount of flexibility if you want to implement more complex migration functionality. It allows library developers to add powerful features that would be very difficult to do with Rails/ActiveRecord or Django ORM.
FWIW I maintain the flask-audit-logger package. It allows users to maintain audit logs of specific tables using postgres triggers. Being able to create custom migration operations is really an amazing feat. The alembic docs are quite dense, but the code is well organized and very readable.
yeah, alembic feels especially "small" and obscure compared to the hyper exhaustive nature of SQLA for everything else. felt like a side project at first
Not to mention SQLAlchemy supports the unit of work pattern meaning you can update many objects at once. It tracks and figures out how to apply the updates all in one go. Django supports one object at a time.
With SQLAlchemy it's easy to build mappers to real domain objects that are independent of the database. Most Django people treat the Django models as entities or, worse, do business logic in views etc. It's possible to implement unit of work on top of Django, but that's then another layer you have to maintain yourself (which SQLAlchemy does for you).
But SQLAlchemy is harder. It's better but it's harder. Django is easier to get going with. But it bites you later (unless your app is just CRUD, in which case Django is all you need, well that and a better way to generate HTML).
I class the SQLAlchemy unit of work pattern as one of the harder things: in the cases where Django’s bulk update mechanisms wouldn’t work, it’s extremely easy for someone who isn’t an SQLAlchemy expert to get confused about when changes are committed or to inadvertently leak sessions.
It’s a powerful idea but having helped people with it I’ve mostly felt it reinforce my belief that less magic is usually better from a support perspective.
To each their own, nothing about the first syntax feels miserable to me, my IDE has got me fully supported on it. I don't dislike the SQL Alchemy one though it takes many more lines on my editor (no way I am going to inline all those nested dicts like that).
Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.