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.<p>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?<p>Nah. Just write the good SQL for your database.
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'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.
Every Oracle rep I've ever met said every app should be a SQL app.
Indeed, Dapper, myBatis, jOOQ,...
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."
There's value in not having to hunt in several places for business logic, having it all in one language, etc. I was ambivalent on the topic until I encountered an 12 page query that contained a naive implementation of the knapsack problem. As with most things dogma comes with a whole host of issues, but in this case I think it's largely benign and likely did more good than harm.
> hunt in several places for business logic<p>But that is the result of having multiple applications needing to enforce valid states in the database.<p>"Business logic" is a loose term. The database is the effective store for state so it must enforce states, eg by views, triggers, and procedures.<p>Other "business logic" can happen outside of the db in different languages. When individual apps need to enforce valid states, then complexity, code, etc grows exponentially.
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.
Bingo.<p>"<i>Bad programmers worry about the code. Good programmers worry about data structures and their relationships</i>”<p>Some quotes stick with you throughout your whole career.
Any recommended resources you wish you had encountered earlier?
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.
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.
This is a nice coincidence.<p>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.<p>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.<p><a href="https://github.com/bikeshaving/zen" rel="nofollow">https://github.com/bikeshaving/zen</a>
> the second programming language everyone needs to know<p>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.
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.
Somewhat tangential to the article, but why is SQL considered a <i>programming language</i>?<p>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 <i>computer language</i> [2] for sure, but why <i>programming</i>?<p>[1] <a href="https://en.wikipedia.org/wiki/List_of_programming_languages" rel="nofollow">https://en.wikipedia.org/wiki/List_of_programming_languages</a><p>[2] <a href="https://en.wikipedia.org/wiki/Computer_language" rel="nofollow">https://en.wikipedia.org/wiki/Computer_language</a>
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<p><a href="https://www.reddit.com/r/SQL/comments/81barp/i_implemented_a_brainfck_interpreter_in_pure_sql/" rel="nofollow">https://www.reddit.com/r/SQL/comments/81barp/i_implemented_a...</a><p>Btw this runs in sqlite, you can try it yourself if you are interested.<p>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.
What is your definition of 'programming language'?
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.<p>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.
Learning SQL basically launched my career as a professional SWENG. Once I knew SQL, I found ways to apply it in even non-technical jobs.
I am quite found of PL/SQL, and stored procedures, no need to waste network bandwith with what can be done on the database.
The CM DB group YT channel is good place to learn about the basics and advanced topics: <a href="https://www.youtube.com/@CMUDatabaseGroup" rel="nofollow">https://www.youtube.com/@CMUDatabaseGroup</a>