Why SQL Will Outlast NoSQL: Lessons from 20 Years of Database Evolution

Never underestimate the power of good marketing for a bad product.

This favorite quote comes from a paper that explains why SQL and relational databases remain the best tools for transactional data.

A 2024 paper continues the influential 2005 Stonebraker work, exploring why SQL and relational databases won out over all data‑management innovations of the 1990s.

NoSQL’s 20‑Year Journey

You probably don’t remember XML databases because they didn’t survive.

In the early 2000s and again in the early 2010s, many web‑scale technologies experienced a NoSQL‑like wave.

Famous tech stacks you’ve heard of share these traits:

Removed from BigTech codebases (e.g., MapReduce)

Gained transaction support (e.g., Mongo)

Adopted SQL‑style APIs (e.g., DynamoDB, Spanner, Mongo)

Used mainly for analytical workloads (e.g., ClickHouse, DuckDB)

Downgraded to caches (e.g., Redis)

As a NoSQL fan, I’m not surprised: the more you use these tools, the more you realize they have narrow use cases, and you should use Postgres, MySQL, or even Oracle for core production data.

SQL’s Flexibility

Many engineers avoid SQL because it requires learning another language and has impedance mismatch with application code.

ORMs and frameworks hide this “dirty work,” and as domain complexity grows, developers often write raw SQL for clarity.

NoSQL promised “no more SQL,” but the problem is that NoSQL databases excel at reading data in ways engineers predict, yet they struggle with new queries, encoding time, and optimization.

Stonebraker notes that NoSQL systems clash with relational databases because relational engines can optimize ad‑hoc queries on production data.

Like SQL, these systems trade flexibility for familiarity, and many web‑scale technologies sacrifice ACID compliance for speed.

Atomicity, Consistency, Isolation, Durability

Databases ensure transactions that are atomic, consistent, isolated, and durable. Early web‑scale systems gave up these guarantees for eventual consistency, which proved hard to manage and error‑prone. Nowadays, more NoSQL systems are adding transaction support.

Data Is Eternal

Large tech startups have strong incentives to try new technologies, but data is sticky—once you have a usable database, you rarely switch because migration is daunting.

Even Google and its allies, with billions invested, eventually abandoned NoSQL when its impact fell short.

Systems like Cassandra, HBase, and Spanner now include some SQL and transaction support, but they still need to add these features to existing NoSQL stacks because data stickiness forces retention of underlying technology.

OLAP vs. OLTP

OLAP (online analytical processing) has shone over the past 20 years, with columnar databases widely adopted for analytics, data science, and data engineering.

Columnar stores flatten production OLTP data into highly denormalized, column‑oriented tables, enabling fast analytical queries through vectorized and parallel computation.

However, columnar databases have yet to prove they can handle production workloads efficiently, often being slower for row‑oriented operations.

Relational Databases Adopt the Best Features

Stonebraker observes a remarkable trend: new technologies keep emerging, while existing relational databases continuously adopt them.

Modern relational databases now support JSON columns, allowing document storage within a single column, and enable deep JSON queries, indexing, and full ACID guarantees.

With the rise of AI engineering, vector databases are gaining popularity, and relational databases are beginning to support vectors, combining relational modeling, ACID compliance, and SQL querying.

As Stonebraker puts it, “It’s a feature, not a database.”

The Biggest Problem with SQL and Relational Databases

Both SQL and relational databases suffer from the “first‑five‑minutes problem”: you must decide what you’re building, set up the database, create tables, and start working.

Some engineers dislike upfront planning, and NoSQL offers false promises that can lead to data collapse once user volume grows.

When data becomes massive and starts to break, it’s often too late; you’re forced to stick with NoSQL because data is sticky.

Therefore, whenever possible, choose SQL.

Cheers!

Compiled by Luo Yi Reference: https://swizec.com/blog/why-sql-is-forever/