SQL was born in 1973 at IBM, survived the NoSQL rebellion, and now powers 55.6% of all developers. Here's how.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
In 1979, a small company called Relational Software Inc. shipped something called Oracle V2. They called it "V2" despite there being no V1 — because, as co-founder Larry Ellison later admitted, nobody would trust a product called Version 1. That product was built on a language called SQL, created six years earlier by two IBM researchers who thought it might be useful for querying data.
Forty-seven years later, SQL is used by 55.6% of all developers worldwide, runs a database market worth $150 billion, and has outlived every technology that was supposed to replace it. This is the story of how a language born in an IBM research lab became the most enduring piece of software in computing history. And why it'll probably outlast whatever you're building right now, too.
The story starts with Edgar F. Codd, a British mathematician working at IBM's San Jose Research Laboratory. In June 1970, Codd published "A Relational Model of Data for Large Shared Data Banks" in the Communications of the ACM. The paper described a way to organize data using mathematical relations — essentially, tables with rows and columns where relationships between data were defined by values, not physical pointers.
This was radical. In 1970, databases meant either hierarchical models (IBM's IMS) or network models (CODASYL). Both required you to know the physical structure of the data to query it. Want to find all customers in California? You needed to know exactly how the data was stored, which pointers to follow, and in what order. Change the physical layout? Rewrite your queries.
Codd's vision was different: a software architecture that would enable users to access information without expertise in, or even knowledge of, the database's physical blueprint. Separate the logical structure from the physical storage. Let the system figure out the how. You just describe the what.
IBM's management wasn't thrilled. They had a massive revenue stream from IMS — why cannibalize it? But Codd's paper caught the attention of researchers, and IBM eventually funded a project to prove whether the relational model could actually work in practice.
In 1973, IBM started the System R project — an industrial-strength implementation of Codd's relational model. The team included Don Chamberlin and Raymond Boyce, who designed the query language that would become SQL, and Patricia Selinger, who developed the cost-based query optimizer that made relational databases practical for real-world use.
Chamberlin and Boyce originally called their language SEQUEL — Structured English Query Language. The goal was to make data retrieval feel like English. Instead of procedural code that said "start here, follow this pointer, check this condition, return that value," you could write something like:
SELECT name, salary
FROM employees
WHERE department = 'Engineering'
ORDER BY salary DESC;
Declarative, not procedural. You describe what you want, not how to get it. This distinction sounds minor but it changed everything. It meant non-programmers could query databases. It meant the system could optimize execution paths without changing the query. It meant the physical storage could be completely restructured without breaking a single query.
The name changed from SEQUEL to SQL for trademark reasons — the British aircraft company Hawker Siddeley already owned "SEQUEL." But the language kept its pronunciation: most people still say "sequel" rather than "S-Q-L," though both are technically correct.
Here's the thing IBM didn't count on: while they were being methodical about System R, someone else was paying very close attention to their published research papers.
Larry Ellison read Codd's papers and saw something IBM's management missed: the commercial potential of relational databases. In 1977, Ellison, Ed Oates, and Bruce Scott founded Software Development Laboratories. By 1979, they had built and shipped Oracle V2 — the first commercially available relational database.
IBM didn't release their first commercial relational database product, SQL/DS, until 1981. DB2 followed in 1983. By then, Oracle had a multi-year head start and was already selling to government agencies and large enterprises.
This pattern — IBM invents something fundamental but gets beaten to market by a more aggressive competitor — has repeated throughout computing history. But in the SQL story, it had a specific consequence: it proved that the relational model and SQL weren't just academic ideas. They could be built, sold, and run at scale. The market took notice.
Through the 1980s, the database market exploded:
| Year | Event |
|---|---|
| 1979 | Oracle V2 ships — first commercial RDBMS |
| 1981 | IBM releases SQL/DS |
| 1983 | IBM releases DB2 for mainframes |
| 1984 | Sybase founded (later became the basis for Microsoft SQL Server) |
| 1986 | ANSI adopts SQL as a standard (SQL-86) |
| 1989 | Microsoft SQL Server 1.0 released (based on Sybase code) |
| 1995 | MySQL first released |
| 1996 | PostgreSQL first released (as a fork of Postgres) |
By the late 1980s, SQL wasn't just a language. It was the language. And the ANSI standardization in 1986 ensured it would stay that way.
SQL becoming an ANSI standard in 1986 was a turning point. Before standardization, each vendor had their own dialect. Oracle SQL was different from DB2 SQL was different from SQL/DS. Standardization meant (in theory) that SQL code could be portable across databases.
In practice, vendors kept their proprietary extensions. They still do. But the core language stabilized, and each revision added features that pushed SQL from a simple query language into something far more powerful.
Here's the evolution of the SQL standard, and why each version actually mattered:
| Standard | Year | Key Features | Why It Mattered |
|---|---|---|---|
| SQL-86 | 1986 | Basic SELECT, INSERT, UPDATE, DELETE | Established the baseline |
| SQL-89 | 1989 | Integrity constraints, referential actions | Data integrity enforcement |
| SQL-92 | 1992 | JOINs syntax, subqueries, CASE, temp tables, new data types | Foundation of modern SQL; most cited standard |
| SQL:1999 | 1999 | CTEs, recursive queries, window functions, triggers, regex | Analytical power; self-referencing queries |
| SQL:2003 | 2003 | XML support, MERGE statement, sequences, identity columns | Enterprise integration; ETL patterns |
| SQL:2006 | 2006 | Enhanced XML features (XQuery) | XML era features |
| SQL:2008 | 2008 | TRUNCATE, enhanced MERGE, INSTEAD OF triggers | Operational convenience |
| SQL:2011 | 2011 | Temporal tables (system-versioned) | Time-travel queries; audit trails |
| SQL:2016 | 2016 | JSON support, row pattern matching | NoSQL response; modern data formats |
| SQL:2023 | 2023 | Property graph queries, enhanced JSON, ANY_VALUE | Graph database integration |
SQL-92 deserves special attention. It's the most influential SQL standard and the one that most tutorials still reference. It formalized the JOIN syntax we use today (INNER JOIN, LEFT JOIN, RIGHT JOIN), introduced CASE expressions, added subqueries, defined transaction isolation levels, and created temporary tables. If you know SQL, you know SQL-92 — even if you've never heard the name.
SQL:1999 was the quiet revolution. Common Table Expressions (CTEs) and window functions transformed SQL from a row-retrieval language into a serious analytical tool. Before window functions, calculating a running total or ranking results required self-joins or application code. After:
-- Before window functions (painful)
SELECT e.name, e.salary,
(SELECT COUNT(*) FROM employees e2
WHERE e2.department = e.department
AND e2.salary >= e.salary) AS rank
FROM employees e;
-- After window functions (clean)
SELECT name, salary,
RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS rank
FROM employees;
Window functions are, in my opinion, the single most important feature added to SQL since its creation. They turned SQL into a language that could handle complex analytics without leaving the database.
SQL:2023 is the latest standard, formally adopted in June 2023. The headline feature is Property Graph Queries (SQL/PGQ) — a whole new part of the standard that lets you query relational data as if it were a graph database. It also enhanced JSON support with a native JSON data type and simplified dot-notation syntax, and added functions like ANY_VALUE, GREATEST, LEAST, LPAD, and LTRIM that developers had been writing vendor-specific workarounds for.
Then came the NoSQL movement, and for a while, SQL looked like it might actually die.
In 2009, Johan Oskarsson organized a meetup in San Francisco to discuss "open-source distributed, non-relational databases." The term "NoSQL" stuck — and it carried a message: SQL is old, rigid, and can't handle the scale of modern web applications.
The timing was perfect. Facebook, Google, Twitter, and Amazon were dealing with data volumes that traditional relational databases genuinely struggled with. Google had published papers on Bigtable and MapReduce. Amazon had built Dynamo. These companies needed horizontal scalability across thousands of commodity servers, and the relational model's emphasis on consistency and joins made that hard.
MongoDB launched in 2009. Cassandra was released as open source in 2008 and adopted by Apache in 2009. Redis, CouchDB, and Neo4j followed. The message was consistent: relational databases are a bottleneck. Schema-free is the future. Joins are a code smell. SQL is dead.
And for a few years, it looked plausible. Startups adopted MongoDB as their default database. "NoSQL" appeared in every job description. Conference talks about "post-relational" architectures drew standing-room crowds.
But here's what actually happened.
Companies adopted NoSQL databases for legitimate reasons — flexible schemas for rapidly changing data models, horizontal scaling for massive workloads, simple key-value access patterns. Some of those use cases were real and remain valid.
But many companies adopted NoSQL because it was trendy, not because they needed it. They discovered the hard way that not having SQL was actually quite limiting. Each NoSQL database had its own query language. JOINs disappeared, which meant data had to be denormalized — stored redundantly — leading to consistency problems and data bloat. Transactions were often non-existent or limited.
One article I found particularly telling was titled "Why We Moved Back to Postgres After 4 Years of MongoDB Flexibility". That title captures a pattern I've seen repeated dozens of times: a team adopts a NoSQL database for schema flexibility, spends years building workarounds for the features they lost (transactions, joins, data integrity), and eventually migrates back to PostgreSQL when they realize the flexibility wasn't worth the trade-offs.
The pendulum swung back. Hard. Amazon's Aurora — a relational, SQL-compatible database — was described by AWS's CTO as "the fastest growing service in the history of AWS." Google built Spanner, a globally distributed database that uses SQL as its query language. CockroachDB and YugabyteDB emerged as "NewSQL" databases — distributed systems that provide horizontal scalability without giving up SQL or ACID transactions.
The NoSQL movement didn't kill SQL. It proved that SQL was the right abstraction. The distributed databases that companies actually use at scale? Most of them speak SQL now.
We're living in what I'd call SQL's golden age. Not because SQL is new — it's literally the oldest mainstream programming language still in daily use — but because the ecosystem around it has never been stronger.
PostgreSQL has become the default database for a new generation of developers. The 2025 Stack Overflow survey shows PostgreSQL at 55.6% developer adoption — the highest of any database — up from 48.7% just one year earlier. That 7-point jump is the largest annual expansion in PostgreSQL's history.
PostgreSQL wins on three fronts: it's open source (no licensing costs), it's genuinely excellent (JSON support, full-text search, PostGIS for geospatial data, pgvector for AI embeddings), and every cloud provider offers a managed version (Amazon RDS, Google Cloud SQL, Azure Database, Neon, Supabase).
What's remarkable about PostgreSQL's growth isn't just the numbers — it's the breadth. It's the default for web startups building on Rails or Django. It's the default for data teams that need JSON support alongside relational queries. It's the default for AI teams that need vector similarity search via pgvector. And it's increasingly the default for enterprise teams migrating away from Oracle to cut licensing costs. One database, serving use cases that would have required three or four separate systems a decade ago.
DuckDB deserves its own mention because it represents a genuinely new idea. It's an in-process analytical database — like SQLite for analytics. You pip install duckdb and suddenly you can run analytical SQL queries on Parquet files, CSV files, or even pandas DataFrames without setting up a server.
import duckdb
# Query a Parquet file directly with SQL — no ETL, no server
result = duckdb.sql("""
SELECT
department,
AVG(salary) as avg_salary,
COUNT(*) as headcount
FROM 'employees.parquet'
GROUP BY department
HAVING COUNT(*) > 10
ORDER BY avg_salary DESC
""")
DuckDB's adoption curve is steep. It's being bundled into analytics tools by default, and it's become the standard way to do local data analysis in Python and R workflows. The fact that its query language is SQL — not some new DSL — is the point.
SQLite deserves recognition as the most deployed database in the world. It's in your phone, your browser, your operating system, and most of the applications you use daily. It has no server, no configuration, and a single-file database format that's been stable for over two decades.
SQLite's success is a testament to SQL's design. The language is so well-suited to data management that it works at every scale — from a single file on a mobile device to a distributed cluster processing petabytes.
Most "Why SQL survived" articles give vague answers about "simplicity" and "community." Here's what I think actually matters.
1. Declarative beats procedural. Every time.
The single most important design decision in SQL's history: you describe what you want, not how to get it. This means the database engine can optimize execution without changing your query. A SQL query written in 1992 can run faster on a 2026 database engine without a single change to the code.
Every generation of programmers learns this lesson. Imperative data manipulation code is harder to write, harder to read, harder to optimize, and harder to maintain. SQL's declarative model has been validated by thirty years of attempts to replace it.
2. The relational model maps to reality.
Tables, rows, and relationships between them. Customers have orders. Orders have items. Items belong to categories. This maps naturally to how businesses think about data. It mapped naturally in 1970 and it maps naturally in 2026. The problem domain hasn't changed.
3. SQL absorbed its competition.
Every time a new data paradigm emerged, SQL adopted it:
SQL didn't stay rigid. It grew to encompass the use cases that were supposed to kill it.
4. The ecosystem is unmatched.
SQL has more tools, more tutorials, more Stack Overflow answers, more ORMs, more visualization tools, more ETL connectors, and more trained practitioners than any other data technology. This creates a network effect that's nearly impossible to disrupt. When you choose SQL, you choose an ecosystem of decades of accumulated tooling and knowledge.
Think about what "ecosystem" means practically. Every BI tool speaks SQL. Every programming language has SQL drivers. Every ETL tool can read from and write to SQL databases. Every cloud provider offers managed SQL databases. Every data engineering pipeline starts or ends with SQL. To replace SQL, you wouldn't just need a better language — you'd need to replace the entire ecosystem simultaneously. That's not going to happen.
5. SQL is learnable by non-engineers.
This gets overlooked, but it might be the most powerful advantage SQL has. Product managers can learn enough SQL to query their own data. Analysts can write complex reports without waiting for engineering. Business stakeholders can validate data independently. No other data technology has achieved this kind of cross-functional adoption. SQL's English-like syntax — Codd and Chamberlin's original design goal — turned out to be a massive competitive moat.
If you're starting a new project in 2026, here's how I'd think about database selection:
-- The decision in SQL form (because of course)
SELECT database_choice FROM options WHERE
CASE
-- Default starting point for almost everything
WHEN need = 'general web app' THEN 'PostgreSQL'
WHEN need = 'embedded/mobile/edge' THEN 'SQLite'
WHEN need = 'local analytics' THEN 'DuckDB'
-- Specific use cases where alternatives win
WHEN need = 'massive key-value cache' THEN 'Redis'
WHEN need = 'document store with flexible schema' THEN 'MongoDB'
WHEN need = 'real-time event streaming' THEN 'Kafka + ClickHouse'
WHEN need = 'global distribution with SQL' THEN 'CockroachDB or Spanner'
-- When in doubt
ELSE 'PostgreSQL (seriously, just start here)'
END;
The honest answer for 80% of projects: start with PostgreSQL. Add specialized databases when you have a specific, measurable need that PostgreSQL can't handle. Don't add MongoDB because you "might need flexible schemas." Don't add Redis because you "might need caching." Solve the problem you have, not the problem you imagine.
I'll say something that might sound boring but I think is genuinely important: SQL is the most successful programming language ever created, and it's not even close.
Consider the timeline. SQL was designed in 1973. JavaScript was created in 1995. Python in 1991. Go in 2009. Rust in 2010. Every one of those languages has a use case where it dominates. But SQL dominates a use case that every software project has: managing structured data. There is no modern application that doesn't need a database, and there is no database category where SQL hasn't become the default interface.
The NoSQL movement was the biggest threat SQL ever faced, and it ended with NoSQL databases adding SQL interfaces. MongoDB has the Aggregation Framework and Atlas SQL Interface. Cassandra has CQL, which is intentionally SQL-like. Even Elasticsearch added SQL support. The "Not Only SQL" movement became, quietly, the "Also SQL" movement.
Here's my stronger take: SQL's longevity proves that good abstractions are rare and permanent. The relational model and SQL are good abstractions for managing structured data. Not perfect — SQL's handling of NULL values is famously inconsistent, the syntax has accumulated weird corners over 50 years, and the lack of a proper module system makes large queries hard to manage. But the core idea — declarative queries over relations — is so right that it hasn't needed fundamental revision in half a century.
If you're early in your career: learn SQL deeply. Not just SELECT * FROM table. Learn window functions, CTEs, recursive queries, EXPLAIN ANALYZE for query optimization. Learn how indexes work and when they help (and when they hurt). Understand transaction isolation levels and why they matter. It's the single most transferable technical skill in software engineering. Languages change, frameworks die, but SQL survives because the problem it solves never goes away.
I've interviewed hundreds of candidates over the years. The ones who know SQL well — who can write a recursive CTE or debug a slow query with EXPLAIN — consistently outperform the ones who know the latest framework but can't write a proper JOIN. SQL knowledge compounds over a career in a way that framework knowledge simply doesn't.
Every company has data. Every dataset needs queries. SQL handles both.
Fifty-three years and counting.