Database Types — SQL, NoSQL, NewSQL

In 1970, Edgar F. "Ted" Codd at IBM published a paper titled "A Relational Model of Data for Large Shared Data Banks." It proposed something radical: instead of navigating pointers through hierarchical or network databases, express data as relations (tables) and query them with a declarative language (what SQL would become). For 35 years, this was the only real game in town. IBM DB2, Oracle, Sybase, Informix, SQL Server, MySQL, and PostgreSQL all inherited Codd's design.

Then, between 2006 and 2010, something broke. Google published the BigTable paper (2006). Amazon published Dynamo (2007). Facebook released Cassandra (2008). 10gen released MongoDB (2009). The engineers at these companies had hit a wall: their workloads needed global scale, and traditional SQL databases couldn't provide it without giving up availability. A wave of NoSQL ("Not Only SQL") databases was born, each specialized for a specific data shape: key-value, document, wide-column, graph, time-series, search, and later vector.

In 2012, Google published Spanner — showing that with careful engineering (atomic clocks, TrueTime, Paxos), you could actually have distributed ACID transactions at planetary scale. This kicked off the NewSQL era: CockroachDB, TiDB, YugabyteDB — databases that look like SQL to your application but scale horizontally like NoSQL underneath. Today the landscape has ~9 major database families with hundreds of products, and the "which database?" decision is genuinely the most consequential choice in most system designs.

The three big families

Interactive: click any type to explore

Every serious database landing in one of 9 categories below. Click any to see: data model, query interface, real products, when to use it, and when to avoid it.

CREATE TABLE users (id INT, name TEXT, email TEXT);
SELECT users.name, orders.total FROM users
JOIN orders ON users.id = orders.user_id;

SQL vs NoSQL — the fundamental split

The most-asked interview question of the last decade. The honest answer: NoSQL is not one thing — it's 7 different specialized categories. But the split from SQL matters because they make opposite trade-offs:

The SQL family — relational + columnar + NewSQL

SQL databases split into three subfamilies based on what they optimize for.

The NoSQL family — seven data shapes

NoSQL is where the taxonomy gets fun. Each NoSQL category is specialized for a specific data shape and access pattern. Pick the wrong one for your workload and you'll fight the database forever.

The product landscape — real names, real categories

Interactive: which database should I use?

Answer 4 questions about your workload. Get a recommendation. (This is a simplification — real decisions need more nuance — but it's a great mental starting point.)

Applied in real systems — who uses what for what

Every serious tech company runs multiple databases — one per data shape. Here are some real production choices.

Key takeaways

• 3 families: SQL (Codd 1970), NoSQL (2007-10 wave), NewSQL (Spanner 2012 onward).
• SQL has 3 subfamilies: relational OLTP (Postgres, MySQL, Oracle), columnar OLAP (BigQuery, Redshift, Snowflake, ClickHouse), and NewSQL (CockroachDB, TiDB, YugabyteDB, Spanner).
• NoSQL is 7 categories, not 1: key-value, document, wide-column, graph, time-series, search, vector. Each specialized for a specific data shape.
• Trade-offs: SQL gives you flexible queries (JOIN, ad-hoc analytics), strict schemas, and ACID — within one node. NoSQL gives you horizontal scaling, flexible schemas, and specialized data models — but each category makes different consistency compromises.
• NewSQL closes the gap: distributed ACID with SQL semantics. The 2020s default for globally-consistent OLTP workloads.
• You will use multiple databases. Every serious tech company runs 3-8 databases in production, one per workload shape. Netflix, Uber, LinkedIn, Airbnb — all polyglot persistence.
• The 4 decision questions: consistency requirement (ACID or eventual?), query shape (JOIN or point lookup?), scale (single node OK or must distribute?), data shape (rows, docs, keys, graphs, time-series, blobs, vectors?). Answer these → category becomes obvious.

References

• Codd (1970) — A Relational Model of Data. CACM. The foundational SQL paper.
• Chang et al. (2006) — Bigtable. OSDI.
• DeCandia et al. (2007) — Dynamo. SOSP.
• Corbett et al. (2012) — Spanner. OSDI.
• Stonebraker & Cattell (2011) — "10 rules for scalable performance in simple operation datastores." A NoSQL-critical assessment.
• Kleppmann (2017) — Designing Data-Intensive Applications. Chapters 2-3 are the taxonomy reference.
• db-engines.com — real-time ranking of databases by popularity. Great for seeing the landscape.