Case Study: SQL vs NoSQL

Concept. The SQL-versus-NoSQL choice flipped twice. When data outgrew one machine, teams traded SQL ACID guarantees for NoSQL horizontal scale. Distributed SQL, plus JSONB and vector columns inside Postgres, provides most of that scale while keeping SQL. Most apps start with SQL and add specialized systems when scale forces the tradeoff.

Intuition. A modern Postgres row can store a fixed user_id, a JSONB preferences document, and a vector taste profile. Flexible fields no longer require a separate document store in many applications. Dedicated key-value and graph systems fit narrow cases such as sub-millisecond lookups and friend-of-a-friend traversals.

How to think of SQL and NoSQL in 2026

At terabyte scale one machine's memory runs out, and the algorithms that were fine on small data stop working with it. That limit is what drove teams off SQL, and what distributed SQL has since closed.

In the early Big Data days, teams dropped SQL and its ACID guarantees (the Module 4 rules that keep a bank balance accurate) for NoSQL's horizontal scale. Today distributed SQL runs across clusters without giving that up, so SQL and NoSQL are no longer at odds.

JSONB only became a first-class Postgres type in late 2014 (version 9.4); before that, storing documents inside SQL was not yet a credible alternative to spinning up a separate document database.

Modern SQL vs. Ultra-Specialized Systems

For most apps (Instagram, banking apps, school portals), a modern SQL database like PostgreSQL or MySQL is the right call. SQL used to mean rigid tables; today it absorbs documents, vectors, and geo types, so one table can do work that once needed several systems:

The Modern SQL Table: One Table, Three Worlds

User ID (Standard)	Name (Standard)	Preferences (JSONB)	Taste Profile (Vector)
101	Bob	`{"theme": "dark", "genres": ["Jazz", "Lo-fi"]}`	`[0.12, -0.98, 0.45, ...]`
102	Alice	`{"theme": "light", "notifications": false}`	`[0.88, 0.11, -0.23, ...]`

Standard Columns (The 80%): User ID and Name are classic SQL. Rigid, organized, and clean.
JSONB Column (The "NoSQL" part): Preferences let you add a "Favorite Color" for Bob without altering the whole table. Just add it to the JSON column, no table migration needed. This is why much of the NoSQL use case folded back into SQL.
Vector Column (The "AI" part): Taste Profile uses AI embeddings to capture music preferences.

When to go Ultra-Specialized? [The 2026 View]

If Modern SQL is so versatile, why bother with other systems? It's for the remaining 20% when specialization is key.

Ultra-Specialized Key-Value Stores: Needed for sub-millisecond text-based lookups (think Spotify's lyrics).
Ultra-Specialized Graph Databases: Crucial when relationships (like a social network's "friend of a friend") matter more than the data itself.

The goal for most developers in 2025 is to start with the 80% (SQL) and only pivot to specialized systems when scale demands it.

The NoSQL To SQL Migration

HBase Deprecation at Pinterest
Why Pinterest moved away from NoSQL back to SQL systems. A case study in choosing the right tool for the job.

Why NoSQL Deployments Are Failing at Scale
Industry analysis on NoSQL limitations and why companies are returning to SQL-based systems.

Why Companies Transitioned Data Stacks From NoSQL to SQL

Here's the paper on how Google's Spanner evolved from a pure key-value store into a full SQL system. Focus on the big picture and get a sense of the tradeoffs. (It's a PhD-level paper, so don't worry about understanding all the details.)

Can't see the embed? Open the PDF directly.