Case Study: SQL vs NoSQL

Concept. The SQL-versus-NoSQL choice has flipped twice. When data first outgrew one machine, teams dropped SQL's ACID guarantees for NoSQL's horizontal scale; now distributed SQL, plus JSONB and vector columns inside Postgres, gives most of that scale back without giving up SQL. For most apps, start with SQL and specialize only when scale demands it.

Intuition. One modern Postgres row can hold a rigid user_id, a flexible JSONB preferences blob, and a vector taste profile, so "we need NoSQL for flexible data" mostly disappears. You reach for a dedicated key-value or graph store only for the narrow cases (sub-millisecond lookups, friend-of-a-friend traversals) where a specialized engine genuinely wins.

How to think of SQL and NoSQL in 2026

When your database balloons to terabytes, a single machine's memory isn't enough. That's where the real contrast lies: algorithms that shine on small data crumble at scale.

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.

Key-Value Stores → SQL absorbs most of the exceptions, but not all. The clearest case for a specialized store is the simplest one: a key and a blob.