NoSQL — Why & When (CAP & PACELC Trade-offs)

Throughout the 1980s and 1990s, relational databases (Oracle, MySQL, PostgreSQL) scaled vertically (buying larger multi-socket enterprise servers with more CPU and RAM).

In the mid-2000s (Google, Amazon, Facebook), data volumes exploded from gigabytes to petabytes, exposing three fatal scaling limits of traditional RDBMS:

1. Vertical Scaling Physical & Financial Ceiling: A single server tops out at physical hardware limits (e.g. 128 cores, 2TB RAM). Beyond this ceiling, you must scale horizontally across hundreds of commodity server nodes.
2. Distributed SQL JOIN Inefficiencies: Running relational joins (JOIN) or foreign key integrity checks across 100 database nodes requires massive, high-latency cross-network data shuffling.
3. Rigid Schema Bottleneck: Adding a column to a 500-million-row MySQL table historically locked the entire table for hours, halting web traffic.

The NoSQL (Not Only SQL) Solution: Sacrifice complex multi-table SQL joins, strict foreign keys, and immediate ACID transactions in exchange for linear horizontal scaling, massive append-only write throughput, and schema flexibility.