Ask HN: Everyone is using Postgres, why are most scared to program it with SQL?

postgres is an incredibly rich and powerful database and its true power is unlocked when you program it directly with the language that it exposes to the world. postgres has become that standard for database for so many people and projects.

But strangely most are scared to program it with SQL.

Instead, almost everyone uses a database abstraction layer to avoid writing SQL - why is this? Why the obsession with avoiding "programming the machine"?

So instead of creating a lifelong, re-usable knowledge and skill of programming Postgres with SQL, developers are wasting their time learning abstractions and libraries and ORMs that may or may not hang around, and might not even be used at the next project you work on.

Why is it that people love postgres but they are afraid to program it with SQL?

Because SQL isn't properly composable. You can do simple stuff like parameters to avoid blatant injection attacks. But for any remotely complex branching logic, you're back to string concatenation. This is historically an area ripe for security flaws and bugs. Many devs rightfully seek out tools that provide a layer for composing logic with slightly more sanity.

That said, if you're using a generic SQL abstraction layer, you're not really using Postgres per se. You're using a small subset of it. JSONB documents, full text search, powerful aggregates, materialized views, derived columns, geospatial data operations, time series analytics, statistical inference engines... so much power available with a few SQL statements. It is a shame to see most of it lost behind an ORM.

I think the best we can do is use ORM-ish tools for the basic stuff but always have an escape hatch where you can (safely) drop down to raw SQL when necessary. We shouldn't be scared to use it, but it is a sharp weapon. Wield wisely.

> Why the obsession with avoiding "programming the machine"?

I think that programmers who think that ORMs improve upon SQL are making the same mistake that I infer from this quote of yours.

Of the two approaches, SQL is the high-level, abstract DSL for doing the business logic you want, and ORMs are the low-level, implementation-specific technologies which you can push around with loops and conditionals.

People who choose ORMs probably do so because they perceive them to be the higher-level abstractions. But that's why I choose SQL.

Well that's getting into the quality of the abstraction. Not all ORMs suffer this, most good ones give you a way around the n+1 problem.