I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using whatever constructs the builder library offers you. CTEs? Windows? Correlated subqueries? It's a lot. And they're always lazy, so you never really know when the N+1s are going to happen.
Just write SQL. I figured this out when I realized that my application was written in Rust, but really it was a Postgres application. I use PG-specific features extensively. My data, and database, are the core of everything that my application does, or will ever do. Why am I caring about some convenient abstractions to make it easier to work with in Rust, or Python, or whatever?
Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc.
I'm not doubting that it can be done, I'm just curious to see how it's done.
I love SQL and use it all day long to answer various business questions, but I would never use raw SQL in my code unless there is a good reason for it (sometimes there is). ORMs are there for maintainability, composability, type safety, migrations, etc.. trying to do all that with raw SQL strings doesn't scale in a large code base. You need something that IDE tools can understand and allow things like 'find all references', 'rename instances', compile time type checks, etc.. Raw SQL strings can't get you that. And managing thousands of raw SQL strings in a code base is not sustainable.
ORMs are one of those things that a lot of people think is a replacement for knowing SQL. Or that ORMs are used as a crutch. That has nothing to do with it. Very similar to how people here talked about TypeScript 10 years ago in a very dismissive way. Not really understanding its purpose. Most people haven't used something like Entity Framework either which is game changing level ORM. Massive productivity boost, and LINQ rivals SQL itself in that you can write very small yet powerful queries equivalent to much more complex and powerful SQL.
SQL is such a joy to work with compared to all the baggage ORMs bring. I’m not against ORMs but I like to keep them as thin as possible (mostly to map columns to data objects). I’ve been happily using JDBC and Spring Data JDBC (when I needed to use Repository pattern) for a long time in Java.
ORMs come with a lot of baggage that I prefer to avoid, but it probably depends on the domain. Take an e-commerce store with faceted search. You're pretty much going to write your own query builder if you don't use one off the shelf, seems like.
I'm curious if you have tried SeaORM? I've used it a little bit (not too extensively) and really like it. It's like sqlalchemy in that you can declare your tables and have a type checked query builder, which is a big win IMO. It's nice to add/change a field and have the compiler tell you everywhere you need to fix things.
I've definitely had issues when using sqlalchemy where some REST API type returns an ORM object that ends up performing many queries to pull in a bunch of unnecessary data. I think this is harder to do accidentally with SeaORM because the Rust type system makes hiding queries and connections harder.
Most of my usage of SeaORM has been as a type query builder, which is really what I want from an ORM. I don't want to have to deal with lining my "?" or "$1" binds or manually manipulate strings to build a query. IMO a good query builder moves the experience closer to writing actual SQL, without a query builder I find myself writing "scripts" to write SQL.
I've been using django & duckdb together, which keeps me from using the ORM. Was this a happy accident for me? For background, I have a scientist background; I don't have as much experience w/ software and designing database apps.
The cargo-cult shibboleth of "never put business logic in your database" certainly didn't help, since a lot of developers just turned that into "never use stored procedures or views, your database is a dumb store with indexes."
You may not need to use an ORM, but hand writing SQL, especially CRUD, should be a terminable offense. You _cannot_ write it better than a process that generates it.
One of the few things I have used in programming and technology consistently for over 25 years is SQL. Almost no time spent learning how to organize and query data has been a waste in my career.
If you do backend web development in 99% of software companies then being very good at whatever your RDBMS is is a superpower.
It's definitely worth learning SQL very well, but you also need to learn the data structures your RDBMS uses, how queries translate into operations on that data, and what those operations look like in a query plan.
You can go surprisingly far with just that knowledge.
The mere existence of Pandas makes me extremely grateful for SQL, because my job would be absolute hell if I had to use pandas or a similar syntax. It’s hard to overemphasize just how perfect SQL is for the job that it does.
Agree that Pandas is horribly irregular - the only worse query language I’ve had to work with is Mongo’s. After about a decade of regular Pandas use, switching to Polars was such a relief. It’s not perfect since it’s slightly limited by being a Python library rather than an embedded query language but it’s so much better designed than Pandas - even ignoring the huge performance improvement. In my circle, Pandas is being abandoned en mass for Polars.
I don't think SQL is "perfect" and I'm not sure it's rational to even be saying that. For instance, why is it that the syntax for an SQL query is "select A from B" when many SQL-inspired syntaxes have switched to something like "from B select A" to make it more compositional?
The relational model is pretty simple though. Pandas is an awful mess.
> the second programming language everyone needs to know
Do they though? I've been writing SQL for over twenty years, and my experience is that LLMs have been better at writing it than I am for at least most of 2025, for most use cases. I have zero doubt that I will only be writing SQL when I want to for fun no later than sometime 2027.
An LLM can respond to any online discussion about <x> is a good approach for solving a particular class of problems with LLMs can do <x> better than a human better than you.
SQL has been the main skill I have relied upon my entire career. Yes, I have worked with Pandas and other data libraries; my take away from working with Pandas is it is a pretty language but obfuscates the relational database with a non-relational lanuguage. Relational databases require a relational language which is what SQL is.
The basic thesis is that the relational model and SQL has been the prevailing choice for database management systems for decades and that won't change soon.
I’ve always hated SQL, but fortunately LLMs write it so well that it’s effectively become a read-only language now. You just need to know enough to check the output.
I agree. Claude Code writes superb SQL queries for very complex data. I was dealing with PostgreSQL recently, and it improved the query from 30 seconds to 5 seconds. I couldn't figure it out myself.
I’ve been heads-down on publishing a JavaScript full-stack metaframework before the end of the year. However, in the past two weeks I’ve been goaded by Claude Code to extract and publish a separate database client because my vision includes Django-style admin/forms. The idea is to use Zod to define tables, and then use raw SQL fragments with JavaScript template tags. The library adds a tiny bit of magic for the annoying parts of SQL like normalizing join objects, taking care of SELECT clauses and validating writes.
I’m only using it internally right now, but I think this approach is promising. Zod is fantastic for this use-case, and I’m sad I’ve only just discovered it.
My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies.
IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL). So that any invalid SQL parameters like "1;DELETE FROM users;--" would just fail to parse.
It may be called ABI, although it may be textual as well
(like json), not necessarily binary (like protobuf).
PostgreSQL already supports binary wire protocol, but I never seen it's being used, instead people prefer sending raw SQL strings designed for humans even from applications.
Somewhat tangential to the article, but why is SQL considered a programming language?
I understand that's the convention according to the IEEE and Wikipedia [1], but the name itself - Structured Query Language - reveals that its purpose is limited by design. It's a computer language [2] for sure, but why programming?
"structured query language" is actually a backronym, SEQUEL is indeed a programming language and the only mainstream 4GL. consider the output of the compiler (query planner) is a program with specific behavior, just that your sql code is not the only source - the other inputs are the schema and its constraints and statistics. it's an elegant way to factor the sourcecode for a program, I wonder if Raymond Boyce didn't die young what kind of amazing technology we might have today.
With support for Common Table Expressions (CTE), SQL becomes a Turing complete language. To be honest, it makes me somewhat uncomfortable that a query sent to a DB server could be non-terminating and cause a server thread to enter an infinite loop. On the other hand, the practical difference between a query that contains an infinite loop and one that runs for days is probably negligible.
To be honest, I'd like to chip in that it is technically possible to write brainf*ck, an esoteric programming language but nonetheless, its a programming language
Btw this runs in sqlite, you can try it yourself if you are interested.
Source: I was thinking of creating a programming language paradigm like sqlite/smalltalk once where resumed execution/criu like possibilities were built in. Let me know if someone knows something like this too. I kinda gave up on the project but I knew that there was this one language which supported this paradigm but it was very complicated to understand and had a lot of other first time paradigm like the code itself / the ast tree is sort of like a database itself but so the tangential goes.
Because stored procedures do exist, and there isn't a single production quality RDMS that doesn't go beyond DDL and DML, adding structured programming extensions.
Also, even within the standard itself, it allows for declarative programming.
Because "programming language" is an adjective or a descriptive term. Whatever looks like a programming language, can be called a programming language.
The advice to learn SQL is because it's everywhere. Now it has inertia, and a better way of doing things has an uphill battle. In 1980-s somebody compared working with SQL to drinking data through a straw, comparing to swimming in data with APL. We had a recent article comparing modern SSD delays and RAM sizes to those which defined architectures of SQL systems of recent decades - we can perhaps reengineer our databases better for modern opportunities. But all these approaches have to deal with SQL as an entrenched technology. Probably a task for a company of a Google class.
You should also be able to reliably generate working code with LLMs, but you can't. They aren't a good tool until they actually work when they are supposed to.
I've always gravitated towards query languages and SQL is one of my favourites. I've never really understood the need for ORMs and other abstractions but then I'm not a software developer.
If I was going to chose a "third" language I'd say regex.
I much prefer Kusto query language. SQL needs a few tweaks so that it's more type safe and supports auto completion. Some engines support From-first which is a good start.
The SQL standard defines more of an aesthetic than an actual language. Every database just extends it arbitrarily and anything beyond rudimentary queries is borderline guaranteed to be incompatible with other databases.
When it comes to procedural logic in particular… you have almost zero chance you’re dropping into that into another database and it working — even for rudimentary usage.
SQL-land is utterly revolting if you have any belief in standards being important. Voting for Oracle (itself initialized as a shallowly copied dialect of IBM SQL, and deviated arbitrarily) as the thing to call “standard” is just offensive.
petcat|2 months ago
Just write SQL. I figured this out when I realized that my application was written in Rust, but really it was a Postgres application. I use PG-specific features extensively. My data, and database, are the core of everything that my application does, or will ever do. Why am I caring about some convenient abstractions to make it easier to work with in Rust, or Python, or whatever?
Nah. Just write the good SQL for your database.
danem|2 months ago
I'm not doubting that it can be done, I'm just curious to see how it's done.
bottlepalm|2 months ago
ORMs are one of those things that a lot of people think is a replacement for knowing SQL. Or that ORMs are used as a crutch. That has nothing to do with it. Very similar to how people here talked about TypeScript 10 years ago in a very dismissive way. Not really understanding its purpose. Most people haven't used something like Entity Framework either which is game changing level ORM. Massive productivity boost, and LINQ rivals SQL itself in that you can write very small yet powerful queries equivalent to much more complex and powerful SQL.
microflash|2 months ago
b450|2 months ago
nacozarina|2 months ago
Paul-E|2 months ago
I've definitely had issues when using sqlalchemy where some REST API type returns an ORM object that ends up performing many queries to pull in a bunch of unnecessary data. I think this is harder to do accidentally with SeaORM because the Rust type system makes hiding queries and connections harder.
Most of my usage of SeaORM has been as a type query builder, which is really what I want from an ORM. I don't want to have to deal with lining my "?" or "$1" binds or manually manipulate strings to build a query. IMO a good query builder moves the experience closer to writing actual SQL, without a query builder I find myself writing "scripts" to write SQL.
biophysboy|2 months ago
HillRat|2 months ago
unknown|2 months ago
[deleted]
pjmlp|2 months ago
brettgriffin|2 months ago
You may not need to use an ORM, but hand writing SQL, especially CRUD, should be a terminable offense. You _cannot_ write it better than a process that generates it.
fredsmith219|2 months ago
vedaba|2 months ago
[deleted]
bitexploder|2 months ago
koolba|2 months ago
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships”
Some quotes stick with you throughout your whole career.
biophysboy|2 months ago
tdfirth|2 months ago
It's definitely worth learning SQL very well, but you also need to learn the data structures your RDBMS uses, how queries translate into operations on that data, and what those operations look like in a query plan.
You can go surprisingly far with just that knowledge.
A great resource is https://use-the-index-luke.com/
therobots927|2 months ago
derriz|2 months ago
ogogmad|2 months ago
The relational model is pretty simple though. Pandas is an awful mess.
gcanyon|2 months ago
Do they though? I've been writing SQL for over twenty years, and my experience is that LLMs have been better at writing it than I am for at least most of 2025, for most use cases. I have zero doubt that I will only be writing SQL when I want to for fun no later than sometime 2027.
gspr|2 months ago
cjs_ac|2 months ago
tete|2 months ago
Wow, bad career choices?
pjmlp|2 months ago
yawaramin|2 months ago
rawgabbit|2 months ago
FjordWarden|2 months ago
Tostino|2 months ago
schultzer|2 months ago
infogulch|2 months ago
The basic thesis is that the relational model and SQL has been the prevailing choice for database management systems for decades and that won't change soon.
Resubmitted because it's a good one: https://news.ycombinator.com/item?id=46359878
pavlov|2 months ago
system2|2 months ago
yawaramin|2 months ago
bikeshaving|2 months ago
I’ve been heads-down on publishing a JavaScript full-stack metaframework before the end of the year. However, in the past two weeks I’ve been goaded by Claude Code to extract and publish a separate database client because my vision includes Django-style admin/forms. The idea is to use Zod to define tables, and then use raw SQL fragments with JavaScript template tags. The library adds a tiny bit of magic for the annoying parts of SQL like normalizing join objects, taking care of SELECT clauses and validating writes.
I’m only using it internally right now, but I think this approach is promising. Zod is fantastic for this use-case, and I’m sad I’ve only just discovered it.
https://github.com/bikeshaving/zen
adamddev1|2 months ago
deepsun|2 months ago
IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL). So that any invalid SQL parameters like "1;DELETE FROM users;--" would just fail to parse.
It may be called ABI, although it may be textual as well (like json), not necessarily binary (like protobuf).
PostgreSQL already supports binary wire protocol, but I never seen it's being used, instead people prefer sending raw SQL strings designed for humans even from applications.
brettgriffin|2 months ago
SoftTalker|2 months ago
TomasBM|2 months ago
I understand that's the convention according to the IEEE and Wikipedia [1], but the name itself - Structured Query Language - reveals that its purpose is limited by design. It's a computer language [2] for sure, but why programming?
[1] https://en.wikipedia.org/wiki/List_of_programming_languages
[2] https://en.wikipedia.org/wiki/Computer_language
gfody|2 months ago
derriz|2 months ago
Imustaskforhelp|2 months ago
https://www.reddit.com/r/SQL/comments/81barp/i_implemented_a...
Btw this runs in sqlite, you can try it yourself if you are interested.
Source: I was thinking of creating a programming language paradigm like sqlite/smalltalk once where resumed execution/criu like possibilities were built in. Let me know if someone knows something like this too. I kinda gave up on the project but I knew that there was this one language which supported this paradigm but it was very complicated to understand and had a lot of other first time paradigm like the code itself / the ast tree is sort of like a database itself but so the tangential goes.
pjmlp|2 months ago
Also, even within the standard itself, it allows for declarative programming.
yawaramin|2 months ago
rawgabbit|2 months ago
randomNumber7|2 months ago
gjvc|2 months ago
avmich|2 months ago
The advice to learn SQL is because it's everywhere. Now it has inertia, and a better way of doing things has an uphill battle. In 1980-s somebody compared working with SQL to drinking data through a straw, comparing to swimming in data with APL. We had a recent article comparing modern SSD delays and RAM sizes to those which defined architectures of SQL systems of recent decades - we can perhaps reengineer our databases better for modern opportunities. But all these approaches have to deal with SQL as an entrenched technology. Probably a task for a company of a Google class.
mpalmer|2 months ago
That in itself is fine, of course. Less fine is the author's thoughtless assumption that their readers are all learning about it too.
jinwoo68|2 months ago
calebm|2 months ago
bigstrat2003|2 months ago
tete|2 months ago
namegulf|2 months ago
Put it together, it's pure gold!
ifh-hn|2 months ago
If I was going to chose a "third" language I'd say regex.
brikym|2 months ago
Kwpolska|2 months ago
chasil|2 months ago
https://en.wikipedia.org/wiki/Transact-SQL
SQL/PSM is a general ISO standard that grew out of Oracle PL/SQL, is rooted in ADA, and is implemented by a large range of databases.
https://en.wikipedia.org/wiki/SQL/PSM
Standards are important.
setr|2 months ago
When it comes to procedural logic in particular… you have almost zero chance you’re dropping into that into another database and it working — even for rudimentary usage.
SQL-land is utterly revolting if you have any belief in standards being important. Voting for Oracle (itself initialized as a shallowly copied dialect of IBM SQL, and deviated arbitrarily) as the thing to call “standard” is just offensive.
CommenterPerson|2 months ago
stevefan1999|2 months ago
marcusfrex|2 months ago
canyp|2 months ago
https://github.com/chunky/sqlraytracer