Django: One ORM to rule all databases • Hacker News Board

Re: Django: One ORM to rule all databases

#11

Post by zelphirkalt » Sun, Oct 12, 2025, 1:45 PM UTC

leetrout wrote: post #3

blef wrote: post #2

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

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 tr…

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

Re: Django: One ORM to rule all databases

#12

Post by chuckadams » Sun, Oct 12, 2025, 1:48 PM UTC

Isn't Django the one embeds its logic into the names of keys in the arguments list? That might actually be worse than Laravel Eloquent's abuse of magic methods. Way back when I was doing Python, I was using SQLAlchemy, and I recall the design was much more sane.

Re: Django: One ORM to rule all databases

#13

Post by tgv » Sun, Oct 12, 2025, 1:49 PM UTC

Footnote: as long as it's SQL, you stick to hierarchical relations, have enough memory, and can write difficult queries by hand

Re: Django: One ORM to rule all databases

#14

Post by drcongo » Sun, Oct 12, 2025, 2:10 PM UTC

blef wrote: post #2

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

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

Re: Django: One ORM to rule all databases

#15

Post by porridgeraisin » Sun, Oct 12, 2025, 2:11 PM UTC

zzzeek wrote: post #7

what's the purpose of this blog post? "My goal is to help you see quickly where each database works well and where it has some limits. I also hope this can be useful for anyone who wants to improve Django, or just understand it better." OK, then I look at the feature matrix and see a lot of obvious errors, then I see: "The data in the table below is entirely fictional and intentionally provided only for example! I in…

> What are we looking at?

AGI ;-)

Re: Django: One ORM to rule all databases

#16

Post by WhyNotHugo » Sun, Oct 12, 2025, 2:15 PM UTC

Backslasher wrote: post #10

Is Django's ORM even supported outside Django sites? I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.

There's nothing forcing you to use the HTTP stack. It's very common for Django applications to also have a Celery worker for async tasks. The Celery worker is a separate process (possible on a separate host) which use the ORM without any of the HTTP portions.

You can also write custom standalone scripts which use the ORM. Django has a concept of "management scripts" which are also kinda like that (but with a bit more scaffolding).

Re: Django: One ORM to rule all databases

#17

Post by leetrout » Sun, Oct 12, 2025, 2:20 PM UTC

zelphirkalt wrote: post #11

leetrout wrote: post #3

Earlier quoted context omitted.

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 tr…

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

Re: Django: One ORM to rule all databases

#18

Post by Numerlor » Sun, Oct 12, 2025, 2:20 PM UTC

Backslasher wrote: post #10

Is Django's ORM even supported outside Django sites? I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.

We've been running Django's orm under litestar without any issues for maybe 2 years now. We just run django's setup with a minimal settings config as a part of the app startup

Re: Django: One ORM to rule all databases

#19

Post by reactordev » Sun, Oct 12, 2025, 2:20 PM UTC

leetrout wrote: post #3

blef wrote: post #2

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

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 tr…

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.

Re: Django: One ORM to rule all databases

#20

Post by Waterluvian » Sun, Oct 12, 2025, 2:25 PM UTC

chuckadams wrote: post #12

Isn't Django the one embeds its logic into the names of keys in the arguments list? That might actually be worse than Laravel Eloquent's abuse of magic methods. Way back when I was doing Python, I was using SQLAlchemy, and I recall the design was much more sane.

It’s basically a configuration language you learn. But you get to write it inside Python instead of some yaml file or whatnot.

I think it makes sense for something like Django where a lot of people are doing the same basic stuff a lot. So it works and somewhat justifies learning some special language.

But you can also just not use it.