Databases: SQL vs NoSQL — Part 2: Architecture

maang.io System Design Series

What is this?

Back in our office records room from Part 1, the ledger and its rivals don't just look different — they're organized differently, and that organization decides what's fast and what's painful.

The accountant keeps each fact in exactly one place and reconstructs the full picture when needed (more flipping pages, never any contradictions). The clerk who maintains the cabinet of paper forms does the opposite: each folder is already a complete, ready-to-hand answer, even if that means the customer's name is written on twelve different forms. One optimizes for never repeating yourself; the other optimizes for grabbing one folder and being done.

The one-line idea: the relational world models your data around what it is and joins it together per question; the NoSQL world models your data around the questions you'll ask and stores the answers pre-assembled — which is why the single most important NoSQL skill is modeling by access pattern.

In Part 1 we met the four families and the schema divide. Now we look at how each one stores and is queried, the normalization decision that flows from that, how transactions differ, and — at altitude — how each model scales. Let's go.