5 ms·

Every ORM is bad. Especially the "any DB" ORMs. Because they trick you into thinking about your data patterns in terms of writing application code, instead of

Every ORM is bad. Especially the "any DB" ORMs. Because they trick you into thinking about your data patterns in terms of writing application code, instead of writing code for the database. And most of the time their features and APIs are abstracted in a way that basically means you can only use the least-common-denominator of all the database backends that they can support. I've sworn off ORMs entirely. My application is a Postgres application first and foremost. I use PG-specific features extensively. Why would I sacrifice all the power that Postgres offers me just for some conveniences in Python, or Ruby, or whatever? Nah. Just write the good code for your database.

pier25 1y ago
I use PG with Entity Framework in .NET and at least 90% of my queries don't need any PG-specific features. When I need something PG specific I have options like writing raw SQL queries. Having most of my data layer in C# is fantastic for productivity and in most cases the performance compared to SQL is negligible.
- romanhn 1y ago
  Entity Framework really is such a time saver. The PG adapter makes it a breeze not just with common queries, but also more recent stuff, like working with embeddings for vector search.
- theshrike79 1y ago
  Coming from Javaland to C#, Entity Framework is a breath of fresh air. The Npgsql driver automatically applies PG-specific tricks without me having to do anything special The only path I had to do myself is the data ingress point that had some race condition issues, everything else seems to perform pretty well out of the box.
reillyse 1y ago
Every ORM except Active Record is awful. Active Record is amazing.
- irjustin 1y ago
  I moved from Rails -> Django and man my life is so painful. The Django ORM is an exercise in patience. To be fair, Prisma's `OR` clause looks so good. Way better than ActiveRecord.
- globular-toast 1y ago
  Except active record can barely be considered an ORM IMO. Doing a literal one to one mapping between records and objects is not that impressive. A real data mapper ORM at least gets you true entities that are decoupled from the db. That way you could totally swap out your data layer without affecting your domain layer. Active record leads to big ball of mud architecture.
- MrPapz 1y ago
  I still dream about a JS version of Rails' Active Record.
evantbyrne 1y ago
Nah. The most prolific backend frameworks are all built on ORMs for good reason. The best ones can deserialize inputs, validate them, place those object directly into the db, retrieve them later as objects, and then serialize them again all from essentially just a schema definition. Just to name a few advantages. Teams that take velocity seriously should use ORMs. As with any library choice you need to carefully vet them though.
- wredcoll 1y ago
  ORMs are pretty much the definition of technical debt. Sometimes debt is worth it. Sometimes the interest rate is too high.
- marcus_holmes 1y ago
  The "good reason" is that modern web devs do not consider SQL a core skill, and plain do not understand databases. To be a competing modern web framework you have to include an ORM so these people will consider you. Trying to explain to a modern web dev that the optimum data storage structure is not the same as the optimum application layer data structure, so you can't just take one and map them across 1:1 to the other, is really painful. Developing without an ORM is just as quick as developing with one (because the time you save on routine queries you will more than lose on the tricky edge cases that the ORM completely screws up on). But you need to know SQL and databases to do it.
  - evantbyrne 1y ago
    Could this be selection bias? I've never worked with a backend engineer that couldn't write SQL. I've worked on plenty of projects were there were bugs in hand written SQL though.
    - marcus_holmes 1y ago
      Basic SQL yeah, probably. Actually knowing SQL and how to write good SQL and understanding the tradeoffs between different query plans (and the tradeoffs between different schemas). That's rare. And yeah, obviously, there will be bugs in your SQL. And writing good tests for the database layer is always tricky because there's usually some pushback to setting up a database on the CI instance, and so on. It's not simple, but ignoring it by using an ORM doesn't make it simpler, it just means you have less options when it goes wrong.
CuriouslyC 1y ago
SQL Alchemy is pretty good, because it's mostly a sql engine that has an ORM bolted on top of that, and the docs actively try to point users towards using the sql engine rather than using the ORM for everything.
globular-toast 1y ago
It's actually even worse than this, many Django applications are straight up Postgres applications. They use Postgres specific bits of the ORM without hesitation. So they're learning these weird ORM incantations instead of just learning the underlying SQL, which would be knowledge you could apply anywhere. People just hate embedding SQL into other languages. I don't know why.
cess11 1y ago
That's a tradeoff that sometimes makes sense. MICROS~1 SQL Server heavily leans into the 'use specific features extensively', and countless applications on it consist mainly of stored procedures. It does however cause a lock-in that might not be attractive, your customers might be sensitive to what database engine you run their stuff on and then you need to figure out the common ground between two or more alternatives and build your application in that space. It's not as uncommon as one might think, one of the big products in public sector services where I live offers both SQL Server and Oracle as persistence layer so they can't push logic into stored procedures or similar techniques. But just sketching out some schemas and booting PostgREST might be good enough for forever, if that's the case, go for it. As for ORM:s, I kind of like how Ecto in Elixir settings does things, it solves a few tedious things like validation and 'hydration', and has a macro DSL for generating SQL with concise expressions.

pier25 1y ago

I use PG with Entity Framework in .NET and at least 90% of my queries don't need any PG-specific features. When I need something PG specific I have options like writing raw SQL queries. Having most of my data layer in C# is fantastic for productivity and in most cases the performance compared to SQL is negligible.

romanhn 1y ago
Entity Framework really is such a time saver. The PG adapter makes it a breeze not just with common queries, but also more recent stuff, like working with embeddings for vector search.
theshrike79 1y ago
Coming from Javaland to C#, Entity Framework is a breath of fresh air. The Npgsql driver automatically applies PG-specific tricks without me having to do anything special The only path I had to do myself is the data ingress point that had some race condition issues, everything else seems to perform pretty well out of the box.

reillyse 1y ago

Every ORM except Active Record is awful. Active Record is amazing.

irjustin 1y ago
I moved from Rails -> Django and man my life is so painful. The Django ORM is an exercise in patience. To be fair, Prisma's `OR` clause looks so good. Way better than ActiveRecord.
globular-toast 1y ago
Except active record can barely be considered an ORM IMO. Doing a literal one to one mapping between records and objects is not that impressive. A real data mapper ORM at least gets you true entities that are decoupled from the db. That way you could totally swap out your data layer without affecting your domain layer. Active record leads to big ball of mud architecture.
MrPapz 1y ago
I still dream about a JS version of Rails' Active Record.

evantbyrne 1y ago

Nah. The most prolific backend frameworks are all built on ORMs for good reason. The best ones can deserialize inputs, validate them, place those object directly into the db, retrieve them later as objects, and then serialize them again all from essentially just a schema definition. Just to name a few advantages. Teams that take velocity seriously should use ORMs. As with any library choice you need to carefully vet them though.

wredcoll 1y ago
ORMs are pretty much the definition of technical debt. Sometimes debt is worth it. Sometimes the interest rate is too high.
marcus_holmes 1y ago
The "good reason" is that modern web devs do not consider SQL a core skill, and plain do not understand databases. To be a competing modern web framework you have to include an ORM so these people will consider you. Trying to explain to a modern web dev that the optimum data storage structure is not the same as the optimum application layer data structure, so you can't just take one and map them across 1:1 to the other, is really painful. Developing without an ORM is just as quick as developing with one (because the time you save on routine queries you will more than lose on the tricky edge cases that the ORM completely screws up on). But you need to know SQL and databases to do it.
- evantbyrne 1y ago
  Could this be selection bias? I've never worked with a backend engineer that couldn't write SQL. I've worked on plenty of projects were there were bugs in hand written SQL though.
  - marcus_holmes 1y ago
    Basic SQL yeah, probably. Actually knowing SQL and how to write good SQL and understanding the tradeoffs between different query plans (and the tradeoffs between different schemas). That's rare. And yeah, obviously, there will be bugs in your SQL. And writing good tests for the database layer is always tricky because there's usually some pushback to setting up a database on the CI instance, and so on. It's not simple, but ignoring it by using an ORM doesn't make it simpler, it just means you have less options when it goes wrong.

CuriouslyC 1y ago

SQL Alchemy is pretty good, because it's mostly a sql engine that has an ORM bolted on top of that, and the docs actively try to point users towards using the sql engine rather than using the ORM for everything.

globular-toast 1y ago

It's actually even worse than this, many Django applications are straight up Postgres applications. They use Postgres specific bits of the ORM without hesitation. So they're learning these weird ORM incantations instead of just learning the underlying SQL, which would be knowledge you could apply anywhere. People just hate embedding SQL into other languages. I don't know why.

cess11 1y ago

That's a tradeoff that sometimes makes sense. MICROS~1 SQL Server heavily leans into the 'use specific features extensively', and countless applications on it consist mainly of stored procedures. It does however cause a lock-in that might not be attractive, your customers might be sensitive to what database engine you run their stuff on and then you need to figure out the common ground between two or more alternatives and build your application in that space. It's not as uncommon as one might think, one of the big products in public sector services where I live offers both SQL Server and Oracle as persistence layer so they can't push logic into stored procedures or similar techniques. But just sketching out some schemas and booting PostgREST might be good enough for forever, if that's the case, go for it. As for ORM:s, I kind of like how Ecto in Elixir settings does things, it solves a few tedious things like validation and 'hydration', and has a macro DSL for generating SQL with concise expressions.