What Goes Around Comes Around: Why Database History Keeps Repeating

TL;DR

Every few years, a new database paradigm claims it will kill SQL and relational databases. But they always end up adding SQL interfaces and relational features. History keeps repeating itself.

I've been building applications for long enough to watch the same database revolution happen three times. First it was object-oriented databases in the '90s, then NoSQL in the 2000s, and now vector databases are the hot new thing that's supposedly going to change everything.

Each time, the pitch is identical: "SQL is too slow, relational databases can't scale, and our new approach will solve all your problems." Each time, developers get excited, venture capital flows, and the tech blogs declare the death of traditional databases.

And each time, the exact same thing happens: the new paradigm quietly adds SQL interfaces and adopts relational features until it becomes indistinguishable from what it was supposed to replace.

This isn't just my observation. Michael Stonebraker wrote about this pattern in 2005, and then again in 2024. Twenty years later, he's still watching history repeat itself. Maybe it's time we learned something from it.

The Pattern Is Always the Same

Having lived through multiple database hype cycles, I can now predict how they unfold:

Phase 1: The Bold Claims

  • "SQL is fundamentally broken"
  • "Relational databases can't handle modern workloads"
  • "Our new data model is revolutionary"
  • "Developers will finally be free from the tyranny of schemas"

Phase 2: The Hype

  • Conference talks about the "post-SQL world"
  • Startups raise massive funding rounds
  • Big tech companies build internal systems using the new approach
  • Early adopters evangelize the technology

Phase 3: The Reality Check

  • Production deployments reveal edge cases and limitations
  • Missing features become painful (transactions, consistency, query optimization)
  • Developers realize they need to implement SQL-like operations anyway
  • The learning curve is steeper than promised

Phase 4: The Quiet Convergence

  • SQL interfaces get added ("for compatibility")
  • ACID transactions make a comeback ("for enterprise customers")
  • Query optimization layers appear
  • The revolutionary data model becomes just another storage option

I've watched this cycle play out so many times it's become predictable.

NoSQL: The Perfect Case Study

The NoSQL movement of the 2000s is the textbook example of this pattern.

The Original Promise: MongoDB, Cassandra, and CouchDB would free developers from the constraints of relational databases. No more schemas, no more complex joins, no more impedance mismatch between objects and tables.

What Actually Happened:

  • MongoDB added SQL support in 2021 through their Atlas service
  • Cassandra replaced their original API with CQL (Cassandra Query Language), which is basically SQL
  • Even Amazon's DynamoDB added PartiQL, their SQL-compatible query language

The "NoSQL" marketing eventually morphed from "No SQL" to "Not Only SQL." By 2020, every major NoSQL database had quietly added the features they originally rejected.

I remember having conversations with MongoDB evangelists in 2012 who insisted that SQL was a relic of the past. Those same people now write SQL queries against MongoDB collections.

Vector Databases: History Repeating Right Now

Vector databases are having their moment as the "next big thing" thanks to AI and machine learning hype. The pitch is familiar: traditional databases can't handle high-dimensional vectors, similarity search is the future, embeddings will revolutionize how we think about data.

Sound familiar?

I've been experimenting with vector databases for the past year, and I'm already seeing the pattern emerge:

What's happening now:

  • PostgreSQL added pgvector extension in 2021 - vector search in SQL
  • Oracle, SingleStore, and ClickHouse all added vector indexes in 2023
  • Traditional databases are handling vector workloads just fine
  • Vector "databases" are really just document databases with specialized indexes

What will happen next:

  • Vector databases will add more SQL-like features
  • They'll adopt ACID transactions ("for enterprise reliability")
  • Query optimizers will appear for complex operations
  • The specialized nature will become just another index type

The vector database vendors are following the exact same playbook as the NoSQL vendors a decade ago.

Why Does This Keep Happening?

After watching this cycle repeat, I think there are several forces at work:

Innovation Theatre: The database market is huge and competitive. Claiming your approach is "fundamentally different" gets attention and funding even if the differences are mostly superficial.

Solving Yesterday's Problems: Each new paradigm addresses real limitations that existed in previous systems. Object databases solved impedance mismatch issues. NoSQL tackled scaling problems. But by the time the new systems mature, the old systems have often fixed those problems too.

The Complexity Tax: Building a production database is incredibly hard. Query optimization, transaction processing, crash recovery, concurrent access - these aren't optional features. They're fundamental requirements that every serious database eventually needs.

Developer Expectations: Developers expect SQL. It's been around for 50 years, it's widely known, and despite its flaws, it works. Adding a proprietary query language means asking developers to learn something new for marginal benefits.

What Stonebraker Got Right

Reading both the 2005 and 2024 "What Goes Around Comes Around" papers, Stonebraker's central insight holds true: most "revolutionary" database ideas aren't actually new. They're rehashes of concepts from decades past.

Document databases? We had hierarchical databases in the 1970s with the same problems.

Key-value stores? Network databases in the '70s used similar models.

Graph databases? They're essentially network databases with better marketing.

Vector databases? They're array databases focused on one-dimensional vectors.

The data models keep cycling through the same basic patterns because there are only so many fundamental ways to organize information.

What I've Learned From All This

Don't bet the farm on revolutionary database technologies. By the time they mature enough for serious production use, they look remarkably similar to existing solutions.

SQL isn't going anywhere. It's not perfect, but it's universal. Every database that wants commercial success eventually adopts it.

Specialized databases serve niche markets. There's room for systems optimized for specific workloads, but they don't replace general-purpose databases.

The relational model is remarkably resilient. For 50 years, people have been predicting its death. It keeps evolving and absorbing the best ideas from competitors.

Hype cycles are profitable but don't reflect technical reality. The companies that make the most money are often those selling shovels during gold rushes.

The Current State of Play

In 2026, where are we?

PostgreSQL has become the Swiss Army knife of databases. It handles relational data, JSON documents, time series, full-text search, and now vector similarity. It's basically absorbed the key features from every database type.

Cloud providers offer managed versions of everything, which commoditizes database choice. Whether you choose PostgreSQL, MongoDB, or Cassandra matters less when AWS handles the operations.

SQL keeps evolving. JSON support arrived in SQL:2016. The 2023 standard adds graph queries and multi-dimensional arrays. SQL absorbs new paradigms faster than new databases can replace it.

My Prediction for the Next Cycle

Based on the pattern, here's what I expect to happen over the next decade:

  1. AI/ML databases will be the next hype cycle, promising to revolutionize how we store and query data with built-in machine learning capabilities.

  2. Vector databases will converge with traditional databases. The specialized vector systems will add more SQL features while PostgreSQL and others improve their vector support.

  3. A new paradigm will emerge around 2028-2030, claiming that current databases can't handle some new workload (quantum computing queries? neural network storage? who knows).

  4. The cycle will repeat with the same pattern: bold claims, hype, reality check, quiet convergence.

The Exception That Proves the Rule: Columnar Storage

Not every database innovation follows this hype-and-convergence pattern. Columnar storage is the rare example of a genuinely revolutionary approach that stuck.

In my current stack, I use ClickHouse for analytics alongside MySQL for transactions and DynamoDB for key-value lookups. This isn't database politics - it's using the right tool for the job.

Why columnar storage actually worked:

ClickHouse and systems like Snowflake solve fundamentally different problems than row-based databases. When you're analyzing billions of records and only need 3 columns out of 50, reading entire rows is wasteful. Columnar storage gives you:

  • Massive compression gains - similar data types compress 10-20x better than mixed rows
  • I/O efficiency - only read the columns you actually need
  • Vectorized processing - operations on entire columns are orders of magnitude faster

I've seen ClickHouse queries that would take hours in MySQL finish in seconds. That's not hype - that's a genuine architectural advantage for analytical workloads.

The key difference: Columnar databases didn't claim to replace everything. They focused on a specific problem (OLAP) and solved it brilliantly. They didn't try to be transactional systems or claim that row storage was fundamentally broken.

This is the pattern of successful database innovation: solve a real, specific problem better than existing solutions, rather than claiming to revolutionize everything.

The Real Lesson

The database world isn't broken. It's not stagnant. It's actually incredibly innovative - but the innovation happens through targeted solutions to specific problems, not universal revolutions.

The relational model and SQL have survived and thrived precisely because they're flexible enough to absorb new ideas while maintaining compatibility with existing systems. Meanwhile, specialized systems like ClickHouse coexist by solving problems that general-purpose databases handle poorly.

Instead of chasing the next revolutionary database, maybe we should appreciate this ecosystem approach: use relational databases for most things, and reach for specialized tools when you have specialized needs.

The next time someone tells you their new database paradigm will change everything, just remember: what goes around, comes around. And SQL will probably still be here when the hype fades.