SQL (Structured Query Language) is a language for managing and querying relational data, first described by Edgar F. Codd in 1970, implemented by IBM in 1974, standardised by ANSI in 1986, and declared dead by the technology industry approximately once per decade since the 1990s — after which the technology industry quietly continues using SQL for everything, because SQL works, SQL is correct, and every alternative eventually reimplements it.
SQL is the COBOL of data: unsexy, undying, and processing the vast majority of the world’s structured information while the industry argues about its replacement. The replacement has been imminent for fifty-five years. SQL is still here. The replacements are SQL interfaces on top of non-SQL databases.
The Relational Model
Codd’s insight was mathematical: data should be stored in relations (tables), queried through relational algebra (set operations), and the physical storage should be independent of the logical model. The user should say what they want, not how to get it.
SELECT u.name, COUNT(p.id) AS post_count
FROM users u
JOIN posts p ON p.author_id = u.id
WHERE u.created_at > '2024-01-01'
GROUP BY u.name
HAVING COUNT(p.id) > 5
ORDER BY post_count DESC;
This query says what it wants: users created after January 2024 who have more than five posts, sorted by post count. It does not say how to find them — which index to use, which order to scan, whether to hash join or merge join. The database decides. The database has been deciding since 1974 and is better at it than you are.
This is SQL’s deepest strength: the separation of what from how. The developer describes the result. The query planner produces the execution path. The execution path can be optimised, rewritten, parallelised, and improved without changing the query. A SQL query written in 1990 runs faster in 2026 — not because the query changed, but because the optimiser improved.
No other query language has achieved this. GraphQL resolvers execute the plan the developer wrote. MongoDB queries execute the pipeline the developer specified. SQL queries execute the plan the database chose, which is why databases with fifty years of optimiser development produce plans that no human would write and that outperform everything a human would write.
The NoSQL Interregnum
From approximately 2009 to 2015, the technology industry experienced the NoSQL movement — a collective decision that SQL was the problem and that the solution was to store data in documents, key-value pairs, column families, and graphs, queried through bespoke APIs that were definitely not SQL.
The thesis: relational databases don’t scale. SQL is too rigid. Schema is a prison. The web needs something more flexible, more distributed, more webscale.
The thesis was partially correct: for specific workloads at extreme scale (Google, Facebook, Amazon), the relational model’s transaction guarantees were too expensive. These companies built custom stores — Bigtable, Dynamo, Cassandra — that traded consistency for availability and scale.
The industry then did what the industry does: it adopted Google’s solution for Google’s problems and applied it to applications with 200 users and a Heroku dyno.
The timeline:
2009: "SQL is dead. We're using MongoDB."
2012: "MongoDB lost our data. We're using Cassandra."
2014: "Cassandra is impossible to operate. We're using Postgres."
2015: MongoDB adds a SQL-like query language.
2016: Cassandra adds CQL (Cassandra Query Language — which is SQL).
2018: Google Cloud Spanner: a globally distributed database with... SQL.
2019: CockroachDB: distributed, scalable, and... SQL.
2020: "SQL is dead" → "SQL is back" (it never left)
2024: Every major NoSQL database has a SQL interface.
The NoSQL movement did not kill SQL. The NoSQL movement proved that SQL was so correct that even databases designed to replace it eventually reimplemented it. The query language won. The relational model won. The schema won. The alternatives added SQL interfaces because users kept asking “can I just write a SELECT?”
Yes. You can always just write a SELECT.
The Dialects
SQL was standardised in 1986 (ANSI SQL). The standard has been updated: SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011, SQL:2016, SQL:2023. Every database implements a subset of the standard plus proprietary extensions, producing dialects that are 90% compatible and 10% infuriating:
| Feature | PostgreSQL | MySQL | SQLite | SQL Server | Oracle |
|---|---|---|---|---|---|
LIMIT |
✓ | ✓ | ✓ | TOP |
ROWNUM |
ILIKE |
✓ | ✗ | ✗ | ✗ | ✗ |
UPSERT |
ON CONFLICT |
ON DUPLICATE KEY |
ON CONFLICT |
MERGE |
MERGE |
| String concat | || |
CONCAT() |
|| |
+ |
|| |
| Boolean type | ✓ | sort of | sort of | BIT |
no |
The 90% that is compatible is why SQL skills transfer across databases. The 10% that isn’t is why StackOverflow has 2.4 million SQL questions.
SQLite
Special mention: SQLite — the most deployed database in the world (trillions of instances), embedded in every phone, every browser, every operating system, and one particular notes indexer that insists it’s just a local-first markdown tool.
SQLite is SQL’s purest expression: the language without the server. No configuration. No network. No DBA. One file. The Lizard’s database philosophy made manifest:
The best database is one file.
That file speaks SQL.
The SQL is the truth.
lg uses SQLite with FTS5 (full-text search), WAL mode (concurrent reads), and zero configuration parameters. This is SQL as Codd intended: the developer says what they want, the database finds it, the file is the truth.
The Eternal Query
SQL’s survival is not an accident. SQL survives because it solved the right problem at the right level of abstraction:
- Declarative: say what, not how
- Set-based: operate on collections, not rows
- Optimisable: the database improves without changing queries
- Composable: queries can be nested, joined, unioned, windowed
- Readable: a non-programmer can understand
SELECT name FROM users WHERE active = true
Every attempt to replace SQL rediscovers these properties. GraphQL is declarative (for APIs). MapReduce was set-based (for distributed computation). Every ORM is an attempt to avoid writing SQL that eventually generates SQL. The abstraction leaks. The developer writes SQL. The query runs. The data returns.
Fifty-five years. The same language. Still winning.
Measured Characteristics
Year of Codd's paper: 1970
Year of first implementation: 1974
Year of ANSI standard: 1986
Years declared dead: 1995, 2005, 2010, 2015
Current status: alive
NoSQL databases that added SQL: most of them
StackOverflow SQL questions: 2.4 million
SQLite instances deployed: trillions
Queries Excel processes daily: more than you think
JOIN operations performed (daily, worldwide): billions
Time to learn SELECT: 5 minutes
Time to master window functions: years
ORMs that eventually generate SQL: all of them
Developers who write raw SQL and feel guilty: many
Developers who should feel guilty: none
The Lizard's query language: SQL
The file is the truth: always
