Django: One ORM to rule all databases(paulox.net)
paulox.net
Django: One ORM to rule all databases
https://www.paulox.net/2025/10/06/django-orm-comparison/
84 comments
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.
The problem with ORMs is that they're a very leaky abstraction. Database performance matters a lot for any non-trivial application, and in order to use an ORM performantly you need to understand both the underlying SQL+database but also all of the nuances of how the ORM maps to SQL.
So basically you end up with two situations:
1. You need to hire engineers with double the expertise (not just a SQL engineer, but a SQL+ORM engineer).
1a. You hire a SQL engineer who now has to learn Yet Another ORM.
2. You hire engineers who only know the ORM but not SQL, and your app ends up having shit performance.
Basically, ORMs are simply complicated SQL generating macro frameworks. They are way too leaky to provide a useful level of abstraction like most programming languages.
LLM coding tools may displace ORMs, because they can take away a lot of the tedium with integrating application SQL, which is what ORMs are supposed to do.
So basically you end up with two situations:
1. You need to hire engineers with double the expertise (not just a SQL engineer, but a SQL+ORM engineer).
1a. You hire a SQL engineer who now has to learn Yet Another ORM.
2. You hire engineers who only know the ORM but not SQL, and your app ends up having shit performance.
Basically, ORMs are simply complicated SQL generating macro frameworks. They are way too leaky to provide a useful level of abstraction like most programming languages.
LLM coding tools may displace ORMs, because they can take away a lot of the tedium with integrating application SQL, which is what ORMs are supposed to do.
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.
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.
I worked on the pokemon.com website for several years. It has over 2 million LoC in python (~2.5 once you add in frontend JS). It's a Django site that uses Django's ORM; I can't recall ever seeing any raw SQL. As you might imagine, the site has high traffic and high performance requirements. We never found the ORM layer to be either a hindrance or a performance barrier.
Before the invention of SQL, people wrote software using VSAM files and navigational databases with extremely limited computing and memory resources and it worked.
That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.
That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.
How? Stored procedures?
I find that to be insane.
How do you version that code, and how do you reason with the business logic split all over the DB and code?
I find that to be insane.
How do you version that code, and how do you reason with the business logic split all over the DB and code?
> How? Stored procedures?
Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.
My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.
SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.
> How do you version that code
You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.
> how do you reason with the business logic split all over the DB and code
You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.
[1] https://www.jooq.org/
[2] https://sqlc.dev/
[3] https://github.com/sivers/store
Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.
My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.
SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.
> How do you version that code
You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.
> how do you reason with the business logic split all over the DB and code
You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.
[1] https://www.jooq.org/
[2] https://sqlc.dev/
[3] https://github.com/sivers/store
I don’t get this at all, and I tried to understand it.
I'm good at SQL. When necessary (maybe once a year), I can drop into pure SQL instead of Django ORM like it's nothing.
The thing is, I can't imagine why I would ever want to.
All these anti ORM comments read like they want to be as close to the DB as possible.
This is not what I want. I don't care about guaranteeing the most efficient query, because it is never the bottleneck, not even close.
I want to be as expressive as I can be in the business logic, and I don't feel like I am using pure SQL.
I'm good at SQL. When necessary (maybe once a year), I can drop into pure SQL instead of Django ORM like it's nothing.
The thing is, I can't imagine why I would ever want to.
All these anti ORM comments read like they want to be as close to the DB as possible.
This is not what I want. I don't care about guaranteeing the most efficient query, because it is never the bottleneck, not even close.
I want to be as expressive as I can be in the business logic, and I don't feel like I am using pure SQL.
Again, performance is not my point. If you want maximum performance, use a low-level key-value store, hence my VSAM analogy. On the contrary, for me it is about simplicity.
SQL is the most high level language in common use. It abstracts away everything: Storage, memory, concurrency, and, most importantly, control flow. Complexity comes from complecting things, simplicity comes from decomplecting [1] things. SQL decomplects the what (data flow) from the how (control flow) which means less cognitive load, higher developer productivity and better maintainability.
In my experience, writing business logic in SQL results in fewer bugs and less code. I have replaced 50-line Java methods with 15-line SQL projections multiple times. With Python, the ratio is closer to 2:1, but it's still impressive.
And all of this without having to consider type impedance, eager versus lazy loading, result set mappings, second-level caching, dirty tracking, lifecycle management, OCC, or obscure savepoint bugs. Performance is just a nice, but welcome side effect.
[1] https://www.youtube.com/watch?v=SxdOUGdseq4
SQL is the most high level language in common use. It abstracts away everything: Storage, memory, concurrency, and, most importantly, control flow. Complexity comes from complecting things, simplicity comes from decomplecting [1] things. SQL decomplects the what (data flow) from the how (control flow) which means less cognitive load, higher developer productivity and better maintainability.
In my experience, writing business logic in SQL results in fewer bugs and less code. I have replaced 50-line Java methods with 15-line SQL projections multiple times. With Python, the ratio is closer to 2:1, but it's still impressive.
And all of this without having to consider type impedance, eager versus lazy loading, result set mappings, second-level caching, dirty tracking, lifecycle management, OCC, or obscure savepoint bugs. Performance is just a nice, but welcome side effect.
[1] https://www.youtube.com/watch?v=SxdOUGdseq4
The results would be opposite for me.
I need dynamic query building in most places.
Doing those inline in SQL would result in a mess of unmaintainable manual string concatenation and parameter interpolation.
A code uglier does not exist.
I need dynamic query building in most places.
Doing those inline in SQL would result in a mess of unmaintainable manual string concatenation and parameter interpolation.
A code uglier does not exist.
jOOQ is also a great option if you do like stored procedures
I cannot imagine a 2MLOC codebase with rdbms persistence that does not need custom SQL. I believe you, but I also think that's a special case.
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.
We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name.
Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.
ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name.
Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.
> They are an abstraction to map the data in your database to objects in your code and vice versa.
Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language.
Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language.
Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Okay, so what's the round peg that goes in the round hole, here? Forgetting about objects and just passing around dicts or whatever with no type information?
> Forgetting about objects and just passing around dicts or whatever with no type information?
Why would you need to drop the type information when you stop using hierarchical structures for your data?
Why would you need to drop the type information when you stop using hierarchical structures for your data?
You're working with bits. It's turtles all the way down.
The way it integrates into Django is more than just an abstraction to SQL. It's also an abstraction to your table schema, mapped to your model. In short, it's the Pythonic way of fetching data from your models in Django.
It allows for functional programming, as in building queries upon other queries. And predefined filters, easily combining queries, etc. And much more.
Of course you don't need all of that. But in a big project, where you might query some particular tables a lot of the times, and there are common joins you make between tables, then sometimes it is nice to have predefined models and columns and relations, so you need less verbosity when building the queries.
You do of course need to learn a new tool to build queries, but it does pay off in some cases.
It allows for functional programming, as in building queries upon other queries. And predefined filters, easily combining queries, etc. And much more.
Of course you don't need all of that. But in a big project, where you might query some particular tables a lot of the times, and there are common joins you make between tables, then sometimes it is nice to have predefined models and columns and relations, so you need less verbosity when building the queries.
You do of course need to learn a new tool to build queries, but it does pay off in some cases.
Mostly, I think, the problem is SQL injection, and raw SQL is a great place for people to forget to escape their strings.
ORM's are not the only solution to SQL injection, pyscopg for example handles string escaping etc for you.
Yeah, if you remember to use it properly. SQL injection was pretty rampant before ORMs and web frameworks started being used everywhere.
ORMs let anyone make CRUD apps without needing to worry about that sort of thing. Also helps prevent issues from slipping through on larger teams with more junior developers. Or, frankly, even “senior” developers that don’t really understand web security.
ORMs let anyone make CRUD apps without needing to worry about that sort of thing. Also helps prevent issues from slipping through on larger teams with more junior developers. Or, frankly, even “senior” developers that don’t really understand web security.
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 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.
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 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.
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.
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.
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...
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.
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.
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?
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
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 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.
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.
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?
I used to love the Django ORM when I didn't know any SQL. Then I had to learn SQL so that I could model data properly, and optimize access patterns.
These days I hate working with the ORM because it uses weird abstractions that make your life harder as you try to do more complicated stuff with your data. I had a small bug lately where a queryset would aggregate twice because I filtered an aggregated queryset, and this caused it to aggregate again on top of the previous result. I wouldn't have this bug if I was writing my own SQL, or if I used a query builder instead of an ORM. This is just a small example, I have many more annoying things that will cause me to use SQL directly instead of an ORM for my next project.
These days I hate working with the ORM because it uses weird abstractions that make your life harder as you try to do more complicated stuff with your data. I had a small bug lately where a queryset would aggregate twice because I filtered an aggregated queryset, and this caused it to aggregate again on top of the previous result. I wouldn't have this bug if I was writing my own SQL, or if I used a query builder instead of an ORM. This is just a small example, I have many more annoying things that will cause me to use SQL directly instead of an ORM for my next project.
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.
And this is how we become experienced SWEs.
> use SQL directly instead of an ORM
Me too.
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 included these features just to show what the final matrix could look like, to help start a discussion in the community. Do not use them for any real analysis or decisions."
OK...so....we'll come back when you've written it? What are we looking at?
"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 included these features just to show what the final matrix could look like, to help start a discussion in the community. Do not use them for any real analysis or decisions."
OK...so....we'll come back when you've written it? What are we looking at?
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.
Don't know if AI had anything to do with this but what you quoted reminded me of it.
[deleted]
> What are we looking at?
AGI ;-)
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.
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).
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).
I have made this tiny module to use it wherever I want it.
https://github.com/domingues/djangify-package
https://github.com/domingues/djangify-package
nice!
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?
What does that mean? Like you can't use the library's ORM without exposing a webserver?
More like "on a long-running process that is not a full-blown Django server"
Sad not to see SQL Server listed, if only because my first ever open source contribution was a patch to that driver for Django around 0.96 (the Internet seems to have no memory of it). I guess it’s not surprising as the fix was simply to correct a typo in the word “python” IIRC, so that spoke to the level of love it was going to see.
SQL Server was the only “real” database available to me at work at the time.
SQL Server was the only “real” database available to me at work at the time.
SQL Server is actually supported in Django with this backend by microsoft https://github.com/microsoft/mssql-django
I like the ORM but Django has stagnated in so so many ways.
Most of my startup friends basically use Ruby on Rails for their startup webap, and python microservices these days.
If you know python (hate ruby) and like javascript well enough FastAPI and javascript frontends seems way better.
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
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
We use the Django ORM for the data that the web app directly creates. We use plain SQL for the data that exists independent of the Django application.
Footnote: as long as it's SQL, you stick to hierarchical relations, have enough memory, and can write difficult queries by hand
> 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.
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.
For many people, it's a gateway to back-end development. You don't have to learn all those weird, ancient tools, you just write a bit of Python. Look at this simple example! And then they get stuck on it.
Exactly. Then you learn SQL when needing complexer queries or more performance.
The result:
https://www.reddit.com/r/Entrepreneur/s/SMqhSBxje7
The result:
https://www.reddit.com/r/Entrepreneur/s/SMqhSBxje7
No indexing ... I can definitely see how that happens.
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.
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.
This is good. It would be nice to include MSSQL even though its third party (it doesn't support distinct on columns which was a suprise).
I really, really love the Django ORM. We had some good times together, and we still occasional work together.
But at the end of the day, SQL is text. That's life. Sorry - i know it sucks.
I've fallen in love with lightweight frameworks like pypika.
Part of this is the fact that AI smoothes over the rough spots. I would hate to have do an extremely complex query - highly complex case statements with unusualy datatypes - in pypika without AI. But with AI it gets really easy.
More broadly, AI makes using low-level frameworks much more practical. Requests is on the way out, and the socket framework is back.
The Django ORM is still amazing, especially when it comes to speed and handling multiple different types of databases.
But if you want to do something like create soft deletes (including cascading), it get's really hard really fast.
But at the end of the day, SQL is text. That's life. Sorry - i know it sucks.
I've fallen in love with lightweight frameworks like pypika.
Part of this is the fact that AI smoothes over the rough spots. I would hate to have do an extremely complex query - highly complex case statements with unusualy datatypes - in pypika without AI. But with AI it gets really easy.
More broadly, AI makes using low-level frameworks much more practical. Requests is on the way out, and the socket framework is back.
The Django ORM is still amazing, especially when it comes to speed and handling multiple different types of databases.
But if you want to do something like create soft deletes (including cascading), it get's really hard really fast.
Awesome, nice write-up, thanks. TLDR: use PostgreSQL. Only use Oracle under extreme duress.
hnuser(1)
ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory.
ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.