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

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

#51

Post by jdw64 » Sat, Jul 04, 2026, 4:25 PM UTC

Use it where it fits, and don't use it where it doesn't.

If you don't use an ORM, you'll end up with more boilerplate from mapping code with DTOs. The reason to use an ORM is dirty checking. It's hard to impose this kind of "state" with a relational database. But fundamentally, relational data doesn't fit well with OOP. In the end, you inevitably have to create a layer that absorbs this mismatch. Both approaches have their pros and cons anyway.

Isn't it just a matter of using it where it fits and not using it where it doesn't? I wonder if we really have to frame it as "never use this" or "always use that."

Actually, on second thought, I take it back. "Right tool for the right place" is harder. If you're on a team, it's probably better to just pick one: either don't use it at all, or use it everywhere. Because either way, friction is going to happen. My earlier thinking was too shallow.

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

#52

Post by marcosdumay » Sat, Jul 04, 2026, 4:28 PM UTC

stephen wrote: post #28

bluefirebrand wrote: post #22

Earlier quoted context omitted.

> Folks who dislike ORMs seem to have this false dichotomy that "the ORM _must_ be used for all queries", which is a self-imposed/unpractical restriction. I've always heard a major selling point of ORMs is "You don't have to write the actual SQL anymore" Because of that, I tend to not trust people who use ORMs to even know how to write queries by hand in the first place

You're right, that has been another "pro ORM" pitch that has gone awry and, taken to the extreme, is wrong imo. My nuanced articulation is "you don't have to write the _boilerplate_ SQL for the 90% of just-do-some-CRUD endpoints in your enterprise SaaS application, but you 100% need to 'know SQL' for the last 5-10% of ~reporting/analytics queries that the ORM is going to mess up".

AKA making the easy parts easier while making the difficult parts harder.

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

#53

Post by yieldcrv » Sat, Jul 04, 2026, 4:28 PM UTC

LLMs are better at writing raw queries now and knowing the consequences of how it fits in your architecture (if you ask)

So I think the ORM debate could be over

postgresql is a beast

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

#54

Post by exabrial » Sat, Jul 04, 2026, 4:29 PM UTC

The purpose of an orm is not to "stop writing SQL". In order to effectively use a layer abstraction, you must be able to use the layer below the abstraction.

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

#55

Post by capitainenemo » Sat, Jul 04, 2026, 4:29 PM UTC

I thought this was well put. https://web.archive.org/web/20160301022121/http://www.revisi...

A now defunct site discussing why ORM is a poor map.

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

#56

Post by pull_my_finger » Sat, Jul 04, 2026, 4:29 PM UTC

I wonder if the real problem isn't being able to write efficient queries, but that developers struggle to add (yet another) programming language. Just use AWK, just use SQL, just use jq, just use xyz. It's a lot of overhead. I would be OK to lose whatever fractional speed difference to be able to write my queries in a different scripting language. If I ever scaled so much that I needed to shave microseconds off my queries, there are already tons of DBs available, maybe just using a different tool or, even better, compile the DB with(out) different scripting support.

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

#57

Post by bot403 » Sat, Jul 04, 2026, 4:32 PM UTC

pull_my_finger wrote: post #56

I wonder if the real problem isn't being able to write efficient queries, but that developers struggle to add (yet another) programming language. Just use AWK, just use SQL, just use jq, just use xyz. It's a lot of overhead. I would be OK to lose whatever fractional speed difference to be able to write my queries in a different scripting language. If I ever scaled so much that I needed to shave microseconds off my qu…

I can't tell if you're arguing against SQL or orms. But I take your argument in favor of SQL because that's the native language of all the DBS and the dozens of frameworks and systems on top of them are "just use x...."

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

#58

Post by zadikian » Sat, Jul 04, 2026, 4:34 PM UTC

I never use ORMs. But slightly before 2014, there was still kind of a reason to use them, getting/setting a whole nested bag of fields at once that you don't care about individually. Json/jsonb now handles that better.

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

#59

Post by revetkn » Sat, Jul 04, 2026, 4:34 PM UTC

If you use Java and like to write SQL, check out https://pyranid.com

I stopped using ORMs around 2008 because they made the easy problems easier and the hard problems harder. I wanted to just write SQL and exploit all the power the DBMS has to offer instead of fighting with an abstraction layer, so I created Pyranid in 2015 and keep it actively updated.

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

#60

Post by bot403 » Sat, Jul 04, 2026, 4:35 PM UTC

hatefulheart wrote: post #35

hparadiz wrote: post #27

Earlier quoted context omitted.

I've written/worked on several ORMs from scratch. ORMs are the industry standard. When I see posts like this I simply can't take them seriously. All they are saying is "I won't be a team player" and "I don't actually understand the subject matter". The reality is at a certain scale there's an entire orm team that optimizes everything. But even when there's no team involved there's no way you can write anything more o…

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