SQLAlchemy was just more expressive in previous years and was a requirement for projects that had more advanced data types and didn't want to use raw sql (or build their own ORM pieces).
Django is sealing its fate with the opposition to type annotations. I hope sqlc continues to grow on the Python side because it is wonderful in Go.
alembic is also much better than Django's migrations for the ability to expose the tree like structure with operation commands to manage it.
If Django would add some concept of project level migrations I would be much happier. When I build internal software I prefer one app to rule the domains so I have one set of migration history to manage. But everyone leans extra hard into over packaging into Django apps as a mechanism for name spacing domains and then cross app references / foreign keys make long term migration management a giant pain.
Yeah the Django typing situation is a bit sad. It's obvious that if Django wants to scale to larger teams types would help a lot, especially around getting things like string-field-named annotated query fields onto objects typechecking.
I was going to say this. To eschew types means a bunch of attrs boilerplate to include it if you aren’t doing pydantic. sqlalchemy is just better suited for getting the job done using a pretty standard interface from other orms.
The multi “app” structure is confusing as hell to someone who is writing an… app. It reminds me of JBOSS from Java and no one likes JBOSS app servers anymore.
I’d rather utilize requirements.txt or pyproject.toml to include a library than add an app to my app.
No. I refuse to operate like Wordpress. Glad it’s fine for you but it doesn’t with me for a variety of reasons. The biggest being is now you have multiple apps running in your app so who is to blame when it fails? You? The inner app provider? Django? Accounting? When utilizing libraries, we can utilize testing that can test our code against them either directly or using mocks. Separating ourselves from our dependencies, in case our dependencies change. Django’s model would have you add apps on apps with model definitions spread all over the code base making it near impossible to tell what your schema is…
The JBOSS App Server model is so dead. If I had it my way, Django would be deprecated in favor of FastAPI, Pydantic, and SQLAlchemy.
In person the opinions have been strong amongst vocal community members and some core devs.
In writing they are much more diplomatic.
Here is (one of?) the most recent discussion but, again, it's not representative of the past 4 years so please don't read that and think I have drawn the wrong conclusions :) Django is mature and popular enough to be careful with changes like this but compared to the speed the rest of the community packages have embraced type annotations it is time to move. I was not present at DjangoCon US last month and have no clue if things are improving and movement is happening.
Alembic cannot fake a migration, which is a continual source of pain for me at my current job. There are many migrations that I simply don’t trust development teams to do. The inability to easily tell Alembic to get over itself and trust that something has occurred is frustrating.
That's fair. Especially in environments in 2025 where it's common to only care about a DB URL for the app config and pretty much never manually jump into the DB.
I run into this with lots of tools and I just shrug and move on... I've actually never given this a second thought until you pointed out this inconsistency.
Django is sealing its fate with the opposition to type annotations. I hope sqlc continues to grow on the Python side because it is wonderful in Go.
alembic is also much better than Django's migrations for the ability to expose the tree like structure with operation commands to manage it.
If Django would add some concept of project level migrations I would be much happier. When I build internal software I prefer one app to rule the domains so I have one set of migration history to manage. But everyone leans extra hard into over packaging into Django apps as a mechanism for name spacing domains and then cross app references / foreign keys make long term migration management a giant pain.