Databases: SQL vs NoSQL — Part 3: Advanced & Comparisons

maang.io System Design Series

What is this?

A well-run kitchen doesn't own one universal tool. It has a chef's knife, a paring knife, a cleaver, and a peeler — because cutting isn't one job, it's five, and a single blade good at all of them would be great at none. Hand a serious cook a "does-everything" knife and they'll smile politely and reach for the right one.

A serious system is the same. Our records-room office from Parts 1 and 2 didn't actually pick one way of keeping records — the ledger, the folders, and the corkboard all coexist, each owning the job it's best at. That's the mature view of databases, and it has a name.

The one-line idea: polyglot persistence — use the right database for each job within one system — and the way you choose each one is by matching the access pattern to the model, then sanity-checking where that database lands on the consistency-vs-availability map.

In Part 1 we learned the families; in Part 2, how to model for them. Now we put it together into real decisions: a decision tree, where named databases actually sit on CAP, the OLTP/OLAP split, NewSQL, and the discipline of not reaching for NoSQL when SQL is the right answer.