Hacker News Reader

Comment by blef | Hacker News Reader

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

View on HN

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.

The multi app structure is really good and enables extending your project with other apps and gaining all their migrations and everything else.

Its one thing I didnt appreciate until I tried fastapi and found it wasn't there.

Agree to disagree.

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.

> 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.

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.

https://forum.djangoproject.com/t/revisiting-types-in-django...

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.

You just set the alembic version yourself in the alembic.version table. It’s not rocket science.

Yes, I know how to fix it. I’m saying that it’s absurd to have to drop down to SQL to get an ORM to play nicely; Django handles this with a flag.

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.

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.

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.

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

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.

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.

I don't think it's unreasonable that devs should have to learn about database details to correctly use a database.

Could you list some specific examples where things broke because of SQLAlchemy's design?

Managing connections, connection looking and transactions was something that was always an issue with SQLalchemy for us. Migrations were significantly more terrible as well.

The only footgun is pretending that using an ORM means not having to learn SQL.

Exactly!

I like my ORMs based on SQL concepts, not OOP concepts.

So you do have to know SQL, but you get more convenient ways of generating it.

https://github.com/codr7/tyred

That's not what I said though.

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.

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.

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.

Last time I used it you had to commit session, so no actual change in the database is made until this. It's sill annoying that an update is scheduled though.

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

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

Reply on news.ycombinator.com