Research Data Engineering

Stonebraker et al (2018) - What Goes Around Comes Around: Data Management Cycles

Key Insights

  • A historical analysis of data management systems tracing the cycles from hierarchical to relational to NoSQL to NewSQL, arguing that specialization (one size does not fit all) is the enduring lesson.
Difficulty: Intermediate Type: Research

Edit on GitHub — registry.json

Background

Database history, read closely, is a series of revolutions that repeat themselves. Stonebraker's essay — an extended version of the classic 2005 "What Goes Around Comes Around" — narrates the cycles and extracts the lesson practitioners keep forgetting: the market does not converge on one system, and the reason is not marketing.

The Cycles

The arc runs from hierarchical systems (IMS) to network/CODASYL to the relational revolution (Codd, System R, Ingres) that won the 1980s with declarative SQL and cost-based optimization. Then object-oriented databases failed to displace relational for OLTP, and the 2000s NoSQL wave — Bigtable, Dynamo, Cassandra — rejected schema and joins to buy horizontal scale. The 2010s answer was NewSQL (Spanner, VoltDB, H-Store): ACID and SQL at scale, built fresh instead of patched.

Deep Dive

Each era is defined by three components — data model, language, and engine — and each cycle's mistake was the same: assuming one size fits all. The essay's evidence is specialization: row stores for OLTP, column stores for OLAP, stream engines for streaming, text engines for search, graph engines for graph workloads. Systems that tried to be everything (early OODBMS, early NewSQL over-relational rows) lost to focused engines. The 2018 update adds the modern lesson that this lesson has now been learned twice, and the data-stack split — OLTP database, warehouse, lakehouse, stream, search — is the stable end-state.

Why It Matters

For platform engineers the essay is the antidote to framework fatigue: evaluate engines by workload, not by trend. The "database-cycles" framing is also why the lakehouse debate is best understood as the latest iteration of specialization versus consolidation.

Key Takeaways

  • One size does not fit all: match engine to workload, not to fashion.
  • Relational won on abstraction (SQL, declarative queries), not on storage tricks.
  • Each cycle overclaims; the enduring pattern is specialization plus integration layers.
Article Metadata

Further Reading

  • Databricks Blog

    Lakehouse, Spark, Delta Lake, Unity Catalog — engineering blog

  • Apache Kafka

    Kafka documentation, KIPs, and ecosystem updates

  • Apache Flink

    Flink documentation and release notes

  • Apache Iceberg

    Iceberg table format — specs, REST catalog, performance

  • dbt Blog

    dbt Labs engineering blog — analytics engineering, Semantic Layer

  • Dagster Blog

    Dagster orchestration — software-defined assets, IO managers

Related Research

Related Lessons

Stay Updated

Get the latest research summaries delivered to your inbox.