The Origins of SQL: The Language That Refused to Die
Technology rarely lasts. The tools, languages, and frameworks that dominate one decade are often footnotes in the next. SQL is a striking exception. It was designed in the 1970s, built on a theory from 1970[1], and it still sits underneath the data layer of nearly every web application running today. It has been written off repeatedly, most loudly during the NoSQL movement, and each time it came back. The story of why SQL refuses to die is really a story about getting the fundamentals right the first time.
It started with a theory
SQL begins not with code but with a paper. In 1970, a researcher at IBM named Edgar F. Codd published "A Relational Model of Data for Large Shared Data Banks."[2] At the time, databases stored information in rigid structures that tied the data tightly to the programs that used it, which made them brittle and hard to change. Codd proposed something more abstract: organize data into relations, which we now call tables, made of rows and columns, and let people query that data using mathematics rather than by navigating pointers and physical layouts by hand.
The key insight was the separation of the logical shape of the data from how it was physically stored. You could ask questions about the data without knowing or caring how it sat on disk. That idea was powerful enough to define an entire industry.
From SEQUEL to SQL
Codd's model needed a practical way to express queries. In the mid-1970s, two IBM researchers, Donald Chamberlin and Raymond Boyce, designed a language[3] for exactly that as part of a prototype database system called System R[4]. They called it SEQUEL, for Structured English Query Language, because the goal was a query language readable enough that people who were not career programmers could use it.
The name had to change. SEQUEL turned out to be a trademark held by another company, so it was shortened to SQL. Many people still pronounce it "sequel" out of habit, which is a small living fossil of the original name. System R proved that Codd's relational theory could be built into a real, working, high-performance database, and SQL was the way you talked to it.
Oracle beats IBM to market
IBM invented the relational database and the language to query it, and then a smaller competitor beat it to market. A company called Relational Software, led by Larry Ellison, read IBM's published research, saw the commercial potential, and shipped a relational database using SQL in 1979[5], before IBM productized its own. That company later renamed itself Oracle after its flagship product and grew into a giant. It is one of the clearer cases in tech history of a startup turning a larger company's published research into a market before the larger company could.
The competition that followed, with IBM's DB2, Oracle, and others, pushed SQL into the mainstream. It was standardized by ANSI in 1986 and by ISO in 1987, which gave the industry a common target even as each vendor added its own extensions.
Declarative by design
Part of SQL's durability comes from a design decision that still feels modern. SQL is declarative. You describe the result you want[6], and the database figures out how to produce it.
SELECT name, email
FROM users
WHERE created_at > '2026-01-01'
ORDER BY created_at DESC;
You never told the database which index to use, in what order to read the rows, or how to sort them efficiently. A component called the query optimizer decides all of that for you, and it can change its strategy as your data grows without you rewriting the query. Separating what you want from how to get it has aged extremely well, and it is a large part of why SQL learned to handle data sizes its creators never imagined.
The NoSQL challenge and the return
In the late 2000s and early 2010s, as web companies hit enormous scale, a movement called NoSQL argued that SQL and the relational model were the wrong fit[7] for the modern web. New databases offered flexible schemas and the ability to spread across many machines more easily, and for a while it looked like SQL might be relegated to legacy systems.
What actually happened is more interesting. NoSQL databases found their niches, especially for specific high-scale or flexible-schema problems, but SQL did not go away. The relational model proved more adaptable than its critics claimed. Many NoSQL systems added SQL-like query languages back because developers kept asking for them. A category sometimes called NewSQL emerged, offering the familiar relational model and SQL at the massive scale NoSQL had promised. The challenge made SQL better rather than killing it.
What it means today
SQL is everywhere a web application stores structured data. PostgreSQL and MySQL run countless back ends, SQLite is embedded in phones, browsers, and applications[8] by the billions, and the major cloud providers all offer managed SQL databases as core services. Learning SQL remains one of the highest-return skills a developer can pick up, because the knowledge transfers across decades and across nearly every system you will touch.
The lesson of SQL is that a sound foundation outlasts fashion. Codd got the model right in 1970, Chamberlin and Boyce gave it a usable language a few years later, and that combination has survived every wave of technology that was supposed to replace it. More than fifty years on, when you ask a website for your order history or your account details, the request almost certainly ends in SQL.