Case Study: SQL vs NoSQL
Concept. Many early NoSQL systems gained horizontal scale by narrowing their data models and transaction features. Distributed SQL systems later combined horizontal scale with relational schemas, SQL, and transactions. PostgreSQL also added JSONB, while extensions added vector search. Most applications can begin with SQL and add a specialized store for a measured access pattern.
Intuition. One Postgres row can hold a fixed user_id, a JSONB preferences document, and a vector taste profile. That combination covers many workloads that once required separate systems. A specialized key-value or graph store still makes sense when its access pattern dominates the workload.
How the tradeoff changed
Early relational databases were easiest to operate on one machine. When workloads outgrew that machine, teams adopted systems designed to partition data across a cluster. Many early NoSQL systems prioritized horizontal scale and predictable access paths over joins and general multi-row transactions.
Distributed SQL narrowed that gap by combining sharding and replication with relational schemas, SQL, and transactions. PostgreSQL 9.4 added JSONB in December 2014, making indexed documents a first-class part of a relational database. Extensions such as pgvector later added vector types and indexes.
One table, three data types
A modern SQL database can combine structured columns, JSON documents, and extension-provided vector types in one table:
| 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 give frequently queried fields declared types and constraints.
-
JSONB lets each user carry optional preferences without adding a column for every possible setting.
-
A vector extension stores an embedding for similarity search.
Add a specialized store for a specialized access pattern
-
Key-value stores fit workloads dominated by direct reads and writes through a known key.
-
Graph databases fit workloads dominated by multi-hop relationship traversals, such as finding friends of friends.
Start with the data model and queries you need. Add another system when measurements show that a specialized access path justifies its operational cost.
What migrations actually show
Pinterest retired HBase after maintenance cost, missing transaction and query features, and workload-specific alternatives outweighed its benefits. Pinterest moved different workloads to different systems, including TiDB, Druid, StarRocks, and an internal key-value store. The migration shows why workload fit matters.
Why Spanner added SQL
Google added relational schemas, SQL, and distributed query execution to Spanner while preserving its global distribution and transactional guarantees. The paper explains the query and storage machinery required to combine those properties.
Can't see the embed? Open the PDF directly.
Takeaway
SQL and NoSQL describe different collections of design choices. Modern SQL systems cover more workloads than they once did, while specialized stores remain valuable for specific access patterns. Choose from the queries, guarantees, and scale your application actually needs.