I'm not sure why people have been downvoting you - it's really not an unreasonable question (I've upvoted to try to counter that). To be honest it's been so long since I used the django ORM so my initial assessment my no longer be so true.
SQLA handles pretty much everything. It's built in really clean layers with the Core implementing all of the sql abstractions. If you can write it in sql, you can write it in SQLA. The ORM is just another abstraction which sits on top of that. This architecture makes it really extensible and flexible. We've bent Alembic (the migration tool) to our will and it's amazingly easy to hack on. For me it's one of the greatest pythonic tools.
One of the deeper more subtle issues is that if you architect using something like the django orm, it's assumed to be there and all the libraries / plugins etc will have a structure that's insidiously tied to the underlying data loader (this is a django problem, not a django orm one). Depending on what you're doing that might be ok, but for some projects that's going to bite you over the lifetime of the project.
I always thought every project should have a few well thought out and relevant "invariants" - assumptions that it's easier to rewrite than change, that the whole architecture is built around. They can be a data structure, a library, a way data flow is structured, whatever, as long as they make the rest of the architecture naturally fall into place around them.
On database-heavy projects like CRUD web-apps it makes a lot of sense for the ORM to be such an invariant. And I've never hit the point where I was sad to have my ORM so entangled with my code. So it's really hard for me to get this perspective, although I hear it so much around me.
I guess my takeaway from this conversation would be to study the SQLA architecture as a shining example of correct layers of abstraction, but keep using Django ORM in practice until I encounter a situation where I wish I wasn't.
How did you "bend the migration tool to your will"? What did you need it to do that it didn't do natively? What other things did you need to do that an opinionated generic ORM like Django's considered "against the grain"?
Agree with you, and it totally depends on how the project is going to unfold.
Alembic works by introspecting the db (using sqla) and then creating a script, in sqla, that migrates the current db to match the model defined in code. You can hook in to change that process. In our case, we wanted to create a fully automated Choice type using native python enums. We then added a hook to alembic so it could detect the inconsistency in between the constraints in the db and the code and update them accordingly. The whole thing is about 50 lines. There was a bit to learn, but with sqla / alembic you just slowly start peeling back the layers. Ironically that's all probably something that django has covered!
SQLA handles pretty much everything. It's built in really clean layers with the Core implementing all of the sql abstractions. If you can write it in sql, you can write it in SQLA. The ORM is just another abstraction which sits on top of that. This architecture makes it really extensible and flexible. We've bent Alembic (the migration tool) to our will and it's amazingly easy to hack on. For me it's one of the greatest pythonic tools.
One of the deeper more subtle issues is that if you architect using something like the django orm, it's assumed to be there and all the libraries / plugins etc will have a structure that's insidiously tied to the underlying data loader (this is a django problem, not a django orm one). Depending on what you're doing that might be ok, but for some projects that's going to bite you over the lifetime of the project.