What ORMs have taught me: just learn SQL (2014) • Hacker News Board

Re: What ORMs have taught me: just learn SQL (2014)

#91

Post by vandahm » Sat, Jul 04, 2026, 4:56 PM UTC

I generally like ORMs but recognize that they have a lot of problems. The most common problem that I've seen is when an ORM makes it easy to select records in a way that looks efficient but really is not. Strictly speaking, this isn't a failure of the ORM itself -- it's the fault of the developer who is using the ORM and also the developer that didn't catch it in code review. But it's a case where the ORM is making work for everyone and obscuring legibility into the code instead of saving time and providing clarity.

I've written complicated stuff where an ORM isn't appropriate, but if I'm honest, a large fraction of what I've done in my career is just making boring software to automate menial clerical work, and ORMs are good enough for those kinds of projects.

Re: What ORMs have taught me: just learn SQL (2014)

#92

Post by 7bit » Sat, Jul 04, 2026, 4:57 PM UTC

hatefulheart wrote: post #80

7bit wrote: post #76

Earlier quoted context omitted.

Great anecdote. Doesn't validate your claim

Looks like I’m not the only one, check the thread.

Still just anecdotes. Who cares about those

Re: What ORMs have taught me: just learn SQL (2014)

#93

Post by hatefulheart » Sat, Jul 04, 2026, 4:58 PM UTC

airstrike wrote: post #63

hatefulheart wrote: post #40

Earlier quoted context omitted.

I’m not sure why you thought I meant code clarity and not performance? It’s clear in all cases the correct SQL query will be more performant. Confused at what you’re evening trying to say here. Are you suggesting that 100 lines of application layer code is easier to understand than 15 lines of SQL?

The correct SQL query will be more performant than what? The correct ORM call will build the same correct SQL query. ORM is ultimately SQL

So there is no CPU cycles for the ORM itself? That’s free?

Re: What ORMs have taught me: just learn SQL (2014)

#94

Post by hparadiz » Sat, Jul 04, 2026, 4:58 PM UTC

bot403 wrote: post #60

hatefulheart wrote: post #35

Earlier quoted context omitted.

What optimizations are you making here when at the end of the day performance is dictated by the schema, the query planner and the network?

I read it as "I've optimized the orm to be minimal overhead over raw sql a lot of the time".

I've actually benchmarked the overhead for my ORM against every major PHP orm that exists.

https://the-php-bench.technex.us/runs/1

But the speed is irrelevant as long as it's good enough. Notice Laravel's Eloquent at the bottom of the list yet thousands of projects are being built with it regularly.

Re: What ORMs have taught me: just learn SQL (2014)

#95

Post by robertclaus » Sat, Jul 04, 2026, 5:02 PM UTC

There are simple "ORM"s that just map classes to tables and columns to attributes. Basically focused on serialization instead of query generation. I find those to be a good balance.

Re: What ORMs have taught me: just learn SQL (2014)

#96

Post by DanielHB » Sat, Jul 04, 2026, 5:04 PM UTC

stephen wrote: post #15

I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from tabl…

The main problem of mixing sql and orm together is that most orms don't provide a way to do raw queries in a type safe manner that plays well with non-raw-sql queries.

Re: What ORMs have taught me: just learn SQL (2014)

#97

Post by geophile » Sat, Jul 04, 2026, 5:04 PM UTC

I used to love ORMs so much that I built one for Java, in the early 90s, and it was one of the main offerings of a startup that I joined. I have come around 180 degrees. My rethink started when a developer at a Wall Street bank said: having Oracle on my resume is valuable. Having your ORM on my resume is not.

And then there’s the “now you have two problems” dynamic. You not only have to write high-performing queries, but you have to get the ORM to generate that query for you. And sometimes you don’t want objects. And the schema mapping has to track schema changes.

Just write the damned SQL, it’s not that difficult.

Re: What ORMs have taught me: just learn SQL (2014)

#98

Post by Arch-TK » Sat, Jul 04, 2026, 5:07 PM UTC

valzam wrote: post #7

The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.

A query builder is not an ORM.

ORMs build queries for you, but a query builder does not need to be an ORM.

Re: What ORMs have taught me: just learn SQL (2014)

#99

Post by dmeijboom » Sat, Jul 04, 2026, 5:08 PM UTC

My point of view (after 18 years of programming): DO use frameworks (compile-time checked queries if you can) but skip ORMs that hide/obfuscate SQL completely as it will result in slow queries, extra round-trips, etc

Re: What ORMs have taught me: just learn SQL (2014)

#100

Post by tengbretson » Sat, Jul 04, 2026, 5:09 PM UTC

I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances.

That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform.

ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations.