[blef]

I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike

[leetrout]

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.

[natdempk]

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.

[reactordev]

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.

[zelphirkalt]

> Django is sealing its fate with the opposition to type annotations.

Can you explain or link to how/where that opposition manifests? This is the first time I am hearing/reading about it.

[sgarland]

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.

[lloeki]

Fun story: I once worked on a C piece of industrial software that was running on AIX 3.x to 6.x; the goal was to have a nicer (web) status monitoring UI as well as being able to implement stuff in a "safer" language and onboard more people.

The main problem was that the "database" was IBM C-ISAM. Think MySQL MyISAM tables, except don't even dream about SQL, you interact directly with the internal primitives through a C API; when you'r used to SQL it feels like bitbanging in ASM.

The plan:

- Write a Python binding to the C-ISAM library

- Write a subset of the Django ORM from scratch that would use the above behind the scenes; of course it's more limited but whatever's there must behave the same.

- Write any new software using that subset; slowly port over the old code to the new software; of course it can't use _everything_ that one would otherwise use in a normal app; but then again C-ISAM was so constrained that expectations were incredibly limited anyway from the very beginning.

- [much later] pivot! swap out the mock-Django models and drop in the real Django ORM (basically s/from mockdjango import/from django import/g) and hit some mysql/psql/whathaveyou that you've populated with the C-ISAM schema and data

- All the software written is all the merrier and Just Works; the world's your oyster.

This was made possible because the Django ORM is _incredibly simple_: the PoC was done in an afternoon, the hardest part being understanding Python meta classes.

[siliconc0w]

I used Django to give a legacy java application an instant admin UI and REST interface. Django was able to introspect the database to generate the models, and even for an extremely crufty DB it worked reasonably well.

[stuckinhell]

This is super interesting, would you have the same approach trying to solve this issue in 2025 ?

[anticodon]

But why? Although I have way more experience with Django ORM, I find that SQLAlchemy is closer to SQL and I have to think less how to express complex queries. With Django ORM changing a few characters can change resulting query from LEFT JOIN to INNER JOIN, for example. I find it more difficult to write complex queries in Django ORM.

[izacus]

Being closer to SQL in my projects meant that it had more footguns than C++ and developers had to know a lot about DB details to not break things.

[sgarland]

Wait until you find out that the RDBMS optimizer may also sometimes convert your outer joins to inner joins.

I dislike all ORMs, but I especially dislike SQLAlchemy for its hideously bad docs.

[JodieBenitez]

I prefer working with Django ORM too by a large margin. But I think it's more opiniated than SQLAlchemy, which may be why SQLAlchemy is considered the reference (well.... this and the fact that Django ORM is not a standalone lib). It's great if your use case fits to it but if not, SQLAlchemy probably gives you more adaptability.

But yes, Django ORM any day... or just no ORM at all.

[dvdkon]

SQLAlchemy has one strongly-held opinion, that there should be a 1:1 mapping between objects in a database and in memory. So if you query the database then modify the result, the change will automatically also be made in the DB.

I strongly dislike this, since you always have to be careful not to make some unwanted change. When checking permissions, you have to check before you modify the object. You can't modify it and then run some permission checker. You also can't easily keep the old version around.

Sadly it seems most ORMs follow this style, and that Django's is the odd one out.

[drcongo]

If Django had SQLAlchemy's association proxies I might agree with you.

[rick1290]

Are you saying you'd start a new project with alembic/sqlalchemy nowadays?