Learn SQL Once, Use It for 30 Years

> If you are a junior developer, “learn SQL properly” is the most valuable 40 hours you can spend. Not a tutorial. Not an ORM. Actual SQL: joins, subqueries, window functions, query plans. That investment pays you back at every job, in every stack, for decades

This is the power of low-level reasoning.

Today, even for a junior developers, even if they have AI that solves syntax problems, SQL teaches you to reason and approach problems logically. Without any wrapper masking low-level logic.

It's something like the letters of the alphabet that form concepts: why should they change?

>The Only Programming Language Built on Mathematics, Not Fashion

As a modern array language D4M is the natural successor for SQL [1].

D4M is based on mathematics like SQL, specifically associative array algebra but not relational unlike SQL. It's more generic since can it caters to most modern data abstractions including spreadsheets, database tables, matrices, and graphs [2].

You can achieve 100M database inserts per second with D4M and Accumulo more than a decade ago back in 2014 [3].

[1] D4M: Dynamic Distributed Dimensional Data Model:

https://d4m.mit.edu/

[2] Mathematics of Big Data: Spreadsheets, Databases, Matrices, and Graphs:

https://direct.mit.edu/books/monograph/5691/Mathematics-of-B...

[3] Achieving 100M database inserts per second using Apache Accumulo and D4M (2017 - 46 comments):

https://news.ycombinator.com/item?id=13465141

I’d say the most impactful thing is not to learn SQL, but set theory.

Well-written SQL is about thinking in sets. I cannot tell you how many poorly written procedural stored procedures I’ve replaced with a single performant SQL query over the years.

This is because the most impressive part of the SQL ecosystem is the DBMS engine’s query plan. Though, yes, you have to know how to influence it.

I find ORMs also tend to keep devs thinking procedurally.

Yes learn SQL! But don’t just learn the syntax. Learn the underlying mathematical models and ways of thinking that SQL supports implementing.

Learn SQL (because it's basically the only option) but much more importantly, learn databases. Know why atomicity, consistency, idempotency, and durability matter. Understand the wire protocol and the client-server model. Do relational data modeling; think beyond databases as a dumb store. Join. Know when to normalize. Internalize indexing strategies. Think deeply about what work belongs on the database server (work that can leverage relational set theory) and what work stays in the application. Once you figure the true capabilities of databases, SQL as the language interface is a side note - about as important as the leather on your steering wheel.

I've been slowly transitioning from using an ORM to just plain SQL. It's so much simpler. Less magic, more explicitness, and more control. Also, much better performance. I think the thing is to construct your model around the different queries you need to perform. In many cases, especially a CRUD-type situation, you'll end up with 10-20 different SQL queries, and that's it.

That's true. SQL knowledge is one of the few skills that didn't age.

1. C language.

2. *nix tools (shell and friends).

3. SQL.

4. Basic IPv4 networking.

These things I learned around 20 years ago, they didn't change much and they are useful for me to this day.

- I recently read that most programmers SQL knowledge is outdated by 20 years and it’s true for me. There are quite a lot of features in most DBs that feel very "new" to me.

- Comparing SQL to React weakens the argument. SQL is the language, React is a piece of software. You certainly can run 30 year old JS today in modern browsers.

> Edgar Codd formalised relational algebra in 1970. SQL sits on top of it as a declarative interface. You describe what you want. The database engine decides how to get it. The engine improves every year. Your query stays the same.

Although SQL is of course not relational Algebra (and others like Datalog and D4M are better), it's still cool. It inspired kSQL like Lil uses https://beyondloom.com/decker/lil.html#lilthequerylanguage , which inspired the code I'm most proud of: https://codeberg.org/veqq/declarative-dsls A common query language, a common idiom, for many data structures (arrays, hashmaps, datafremas) is liberating, permitting you to e.g. solve sudoku, make mandelbrot sets or calculate primes directly:

    (def n 40) # to reach primes up to, left is sqr of n, right n/2, then multiply them for rows
    (def composites
    (df/select :from (range 2 (+ 1 (math/floor (math/sqrt n))))
               :cross (range 2 (+ 1 (/ n 2)))
               :where |(<= (* ($ :value_left) ($ :value_right)) n)
               [[:value_left :value_right] :value
                |(* ($ :value_left) ($ :value_right))]))
    (df/select :from (range 2 (+ 1 n)) :exclude composites)

Or e.g.

    (import declarative-dsls/dataframes :as df)
    (def people (df/dataframe :name :age :job))
    (df/dataframe? people)
    
    (df/insert! {:name "Bob" :age 30 :job "Developer"} :into people)
    (df/insert! {:name "Alice" :age 27 :job "Sales"} :into people)
    (df/update! :set {:job "Engineer"}
             :where |(= ($ :job) "Developer")
             :from people)
    
    (df/save-csv people "people.csv" :sep "\\t")
    (def people2 (df/load-csv "people.csv" :sep "\\t"))
    
    (-> people2
       df/dataframe->rows
       df/rows->dataframe
       df/print-as-table)

The tests file has many such things (like the sudoku solver) and even datalog and minikanren implemented on top of this!

But you cannot learn it “once”. You need to continuously use it (over those 30 years, for example) to be proficient at it. It’s not that you can study sql for let’s say, 30 days, and never touch/study it again.

I did “learn” sql at uni… but had to study it again at every company i worked for (different problems triggered different solutions). Im still learning it.

I think the pretext of this articles is ridiculous.

Yes, SQL is based around relational algebra, but all programming languages are built on a theoretical foundation.

And SQL is very much a "fad" language - it just somehow managed to stick around. The goal was not some sort of mathematical purity, but rather to built a natural language data interface (sounds like something currently very hyped?) and it failed spectacularly at that goal.

It is so far from natural language that English speakers with statistical understanding won't be able to read it, but it is also inconsistent enough in its grammar design that it is unreasonably difficult to learn and needs large refactoring every time you want to query into the result of a query.

To continue my rant: Sometimes '=' is an identity test, sometimes it is `==`. Sometimes groups are called groups, sometimes they are partitions.

When creating a CTE, you put the name before "AS", but when creating a column, you put the name after "AS".

SQL is great because it is everywhere and it is definitely good enough, but it is not something great, that transcends other programming languages.

I’ve always felt that SQL is somewhat easy to grasp for basic queries, but gets complex and difficult for even moderate to higher complexity use cases. My eyes glaze over when I read long stored procedures that someone else has written. Any recommended resources to go from beginner/beginner-intermediate to advanced?

> The Only Programming Language Built on Mathematics, Not Fashion

Had to reread the title again since I thought I opened a different article about TLA+.

As for SQL, if you're referring to DBMS systems, here's what E.F. Codd, inventor of relational algebra, had to say about them and the departure from his work: https://thaumatorium.com/articles/the-papers-of-ef-the-coddf...

I've been using SQL for almost 40 years and I know for sure I will be using it for the next 20. Relational databases is about data sets used everywhere and SQL is the math behind it.

With AI it's even easier as it creates all the DB schema for me, all the dummy data to test my apps and all the complex queries needed.

My first job in 1994 was using RDB, very soon updated to RDB-Oracle 6 that was very compliant with my book about sql 92. I learned SQL during my studies, so my queries based on joins naturally performed well, unlike the nested SELECT statements in the legacy code. I learned to tune performances. After that, I've encountered Oracle with its share of non-standard syntax and behavior. Now, when I build a backend (flask or fastapi), my CLAUDE.md contains "use sqlite without sqlalchemy" so that I can understand how data is accessed and check that there is no hidden query inside a loop. When the SQL queries generated by AI become unreadable, it’s a sign that the system is no longer functioning properly. In my view, SQL is a good way to maintain control over an application that is largely generated by AI.

Not quite as simple as learning it once. SQL evolves like other languages, across vendor implementations.

The ClickHouse and DuckDB dialects for example extend the language with analytic options not found in ANSI SQL, nor T-SQL, Pl/PgSQL, etc. DuckDB QoL enhancements are greatly missed when not available.

The comparison with JavaScript as an exemplary imperative language is silly. You can find examples of C code from 40 years ago that still work perfectly with modern compilers. Like C, SQL is a technology that has far outlived its usefulness, though, for very different reasons. SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges. The best thing young developers can do is read a book like "Designing Data-intensive Applications" and learn how the fundamental technology behind databases work. Learning relational modelling is great, but learning SQL itself, unless you actively have to work with it, is a waste of time.

Additionally learn stored procedures.

Helps simplify complex SQL queries and no need to waste network traffic on data that client side is never going to use, and waste CPU cycles processing it.

Yes, what about database portability?

I am on my 50s and it only mattered on a single project, which was anyway a middleware for application servers.

I've learned SQL around 20 years ago, and in all this time I've felt it was just a poorly designed language. It was always infuriating to write because of its verbose nature. Keywords were split into two words. I'm still shocked it's not "GROUPBY". There is no composition and modularization of logic, queries become massive expressions.

I know I'm in the minority in places like this, but I've spent all my life using ORMs, and never once regretted it. And I'm the kind of person that actually likes low-level C from time to time. SQL just feels like a poor abstraction layer: either go higher or lower.

I learned SQL when I was 13 or 14 (I'm 37 now). Fully agree with the article, but it's a shame some choices behind the syntax make it so clumsy. Some choices (minimal), like allowing "," (commas) after columns in the SELECT clause even on the last column declared would be minor in terms of compilation and a GREAT improvement in ergonomics (and composability). Some more recent SQL idioms do allow for tweaks/improvements on these, but it's far from a standard - still niche. Long live SQL.

Having been working with computers professionally for almost 40 years now I've seen quite a lot of things come and go. I'm not convinced that LLMs will stick around for that long although they're currently doing better than "fuzzy logic", which is what it used to be called when they could run on 68HC11s ;-)

You know what has stuck around though?

Thumping great Unix boxes running SQL databases.

Yes, there's a lot wrong with the whole concept, but everything else is in some important way worse.

The real lesson is to learn low level details once and use it forever.

The advantage of abstractions that maintain backwards compatibility better than most (linux syscall, SQL, etc) is that they become low level in the sense of the above statement. There is absolutely no way most syscalls or SQL are actually low-level, but for the most part you can write your code as if they are.

Of course, these abstractions do leak, but for X% of usecases, they reduce the learning required to get the same output as you would have gotten with "true" low level knowledge.

The actual quality of the abstractions is completely moot, the backwards compat _alone_ means that their value exists at almost any value of X. See: the web platform, with a very low value of X.

This is why I love libraries and APIs that focus on backwards compat more than most. Everything else is unknown - you don't know how high quality your API is and how it will stand the test of time. But one thing is for sure, a backwards compatible API will _always_ be useful in some capacity.

I’ve been using Postgres for over 6 years (since I started), and I honestly think it’s one of the best investments you can make as a developer

> Now try this experiment with the JavaScript ecosystem. Take a React component from 2015. React.createClass, mixins, componentWillMount. It doesn't just look old, it throws TypeError: React.createClass is not a function the moment it loads. You rewrite it from scratch to ship it today. Ten years passed, and the framework cycled through three different mental models in that time.

Pretty absurd comparison. SQL is a language, React is not. SQL has been around for over 30 years, React has not.

This is what I refer to as React Derangement Syndrome.

> JavaScript is an imperative language that browser wars, framework trends, and open-source maintainer preferences reshaped every few years. It rewards you for keeping up.

> SQL rewards you for sitting still.

Again, this is apples and oranges. These technologies are in far different places in their history. JavaScript that worked 20 years ago still works today.

You can write an article about how great SQL is without having to bring React up. I promise it's possible.

May be of interest: A Critique of Modern SQL And A Proposal Towards A Simple and Expressive Query Language.

It is a critique of modern SQL and a suggestion for "SaneQL":

"SaneQL features a straightforward and consistent syntax, which improves its learnability and ease of implementation. Additionally, it provides extensibility, with the added ability to define new operators that integrate seamlessly with the existing built-in ones. Unlike most data frame APIs and NoSQL query languages, SaneQL fully embraces the core principles behind SQL, especially multiset semantics."

https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf

A colleague of mine is working on an implementation of these ideas:

https://github.com/wvlet/wvlet

I'm not sure I really consider SQL a programming language though. Certainly doesn't seem fair to compare it to anything turing complete (at least, unless you're going to lump in extensions such as PL/SQL or T-SQL.

Doesn't detract from the advice to learn it though. Picking up books on Perl and C as a teenager always left me feeling like I was missing something key that'd make programming more accessible, and I learned FAR later that what that was was an appreciation for making better use of structured data. In lieu of either larger data structures or microcontrollers, everything I looked at felt like a much more complicated and slightly more capable calculator; the access to large relational data models is really where the super powers of turing complete languages clicked.

> Learn SQL Once, Use It for 30 Years.

Well, during those 30 years you'd have to learn a few additions that were added to the SQL standard, like "OVER / PARTITION BY", and maybe a few non-standard extensions like "QUALIFY".

There have been 11 modifications to the SQL standard since the initial SQL-86 ANSI standard of 1986.

Alternatives come and go, SQL stays.

It's not that I like or dislike SQL, it is just that it has such raw power and mature tooling/resources, I wonder what an alternative could even offer me.

It's like C. It does such a great job at being structured assembly that it is hard to displace it for similar reasons.

Well-designed purpose-built tools stand the test of time. When you need a hammer you need a hammer. I learned to swing a hammer a very long time ago, and that skill has stayed with me on modern-day hammers - I didn't have to learn the New Way Of Hammering Things.

One of the best things that happened to me is my boss giving me a crash course in advanced SQL at my first job. In the database we used at work, he gave me increasingly difficult questions to answer with queries.

It was a great foundation and has served me well to this day.

> "JavaScript and its ecosystem is an environment where browser wars, framework trends, and open-source maintainer preferences reshaped every few years."

In general, I hate frameworks, and not just JavaScript frameworks. Firstly, for the reasons she describes; they do change quite frequently and break stuff. Secondly, I don't see it saving any more time than using several nice libraries. Not only do you have to learn JavaScript, Java, C#, etc. but you have to learn the framework syntax as well. I will, obviously, use a framework at work when I have to, but for my personal projects, I try to "hand roll" as much as I can with vanilla languages.

I'm an existence proof of this. I learned SQL following my previous employer dying a slow death > layoffs. Having worked in a narrow field, there weren't options to continue working in it. That was 25 years ago.

SQL was the foundation of a second career in business data analytics. Moderately interesting and paid the bills.

I must say, it's not just select *, joins and so forth. The human side was important. Always being on the lookout in Big Corp for people hungry for data (lots of them), and working to find quick solutions.

I thought this was about me.

I learned SQL 30 years ago and, well, pretty much stopped.

Through the years, as we added ORMs and were using the databases more for base dumb storage, and that I ventured away from report writing, focuses more and just services, workflow and CRUD, I never really learned modern SQL. I've just been able to muddle through with the SQL I learned long ago.

To the articles other point, I've been doing Java for almost 30 years, and while we have a much more modern language, the fundamentals of years ago are still sound and used every day.

For me SQL has long been the gateway to the world of development. I work in the UK non-profit sector and traditionally this kind of technical knowledge is rare, so for any team I've worked with I've built learning pathways that start with SQL before pushing out into Python, Linux, and other things. We're not exactly at the bleeding edge of current technologies, but SQL has consistently proved to be a great jumping-off point for novices who have even a passing interest in computing.

At my first job in 1997, I learned SQL & Relational DB design with the book "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design"

I love the idea of SQL but to this day after years of using it I still have a strong dislike for it.

The syntax never was intuitive and still isn't, I always mix it up, I found it syntax error always a pain to debug, the tooling is all over the place.

I do agree that it's a truly valuable skill and expect it to last more 30 years.

the main reason i dont like sql is the way it splits your query into parts that run in a different order and you can only have one of each. thats why you need things like ctes. if it was a more "functional" language with features like let bindings it would be easier to understand (and maybe to optimize):

  from customers as c
  let orders := all(orders where customer_id = c.id)
  select c.name, count(orders), avg(orders.price)

> JavaScript is an imperative language that browser wars, framework trends, and open-source maintainer preferences reshaped every few years. It rewards you for keeping up. > Take a React component from 2015

Javascript is actually fully backwards-compatible, to not break the Web. Any javascript from 10 years ago works in the browser. This is good but also a bit of a burden, since the language can only expand but not shrink. React is a library, and like all libraries it has breaking versions. Not understanding the basic difference between the two kinda undermines the credibility of the article.

Also, in a similar way, core, ANSI SQL is largely backwards compatible, but all the SQL dialects linked to various DBMS implementation are generally incompatible. Obviously that's not mentioned in the article.

> Not a tutorial. Not an ORM. Actual SQL: joins, subqueries, window functions, query plans.

Not text written by a human. Not a style that an real writer would ever use. Actual AI slop: Short sentences. Incorrect facts. Not X, Y.

I also feel like giving a shout out to the PDF version of the official PostgreSQL manual. It was one of the most enjoyable and engaging tech books I've ever read, and seems like pretty much the gold standard in what official documentation can look like. It took me a while to figure this out though, because the UX of the standard HTML version of the manual is pretty clunky.

I absolutely LOVED learning SQL on PostgreSQL, roughly 26-27 years ago (so, close to the 30 years cited there). I think I still retain at least 70-80% of all the knowledge I built back then, and it is the case probably because the way in which I learned was by DOING.