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.

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.

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.

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

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.

SQL Server is actually supported in Django with this backend by microsoft https://github.com/microsoft/mssql-django

Last night I was on a SaaS pricing page that said that some of the info on the page was generated by AI and might be inaccurate. On a static sales page? Who'd do business with an entity that can't be bothered to write its own pricing info, or at least proofread it to the point of not needing the disclaimer?

Don't know if AI had anything to do with this but what you quoted reminded me of it.

> What are we looking at?

AGI ;-)

I had to scroll all the way down to find this comment. I had the same thought - why include the table? Now that’ll be part of training data for the next llm, and the cycle of slop renews itself…

A brochure for the cult of PostgreSQL and Django by default without a compelling reason otherwise.

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

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

> outside Django sites

What does that mean? Like you can't use the library's ORM without exposing a webserver?

I have made this tiny module to use it wherever I want it.

https://github.com/domingues/djangify-package

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.

> and can write difficult queries by hand

So now I have to learn an ORM (with some kind of lifecycles, dirty tracking, eager/lazy loading config, etc.)... aaaaand I have to learn SQL as well, because the ORM's abstraction is leaky.

I see some benefits in ORMs for deleting and updating tables. But the benefits are slim and the cost (learning a library that requires understanding of quite a list of additional concepts) are significant. Considering that on-top-of learning the ORM I also need a proper understanding of SQL (for complex t queries or debugging ORM inefficiencies), I'd say it's not worth it.

Used to prefer Ruby and Rails.

Now I think Kotlin is basically a "typed Ruby". And projects like http4k[1] and terpal-sql[2] make webdev't a rather blissful experience.

1: https://www.http4k.org

2: https://github.com/ExoQuery/terpal-sql

I used to love PHP until I wrote a lot of it and gained experience with a list of other languages, now I hate it.

And this is how we become experienced SWEs.

> use SQL directly instead of an ORM

Me too.

Mixing ORMs and raw sql doesn't always work well with ORMs so you often end up in situations where the ORM made the easy parts easier and the hard parts harder.

I disagree to a point that I wrote an article about it.

https://dev.to/cies/the-case-against-orms-5bh4

> Most times ORMs are fine, sometimes they are not.

When fine is defined as "improves dev't speed" I think they are not "fine" for any serious (say 100kLOC+ size) project.

> It's not a law or a prescription.

They come with a lot of webFWs, to the point that a lot of web software is built on top of them. These FWs (Django, Rails, Laravel, Symfony, Play, etc.) promote the use of ORMs.

My problems with ORMs is that they are a solution in search of a problem most of the time.

We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.