SQL vs NoSQL: The Decision Rubric

Around 2010, engineering forums were a battlefield. "MongoDB is web scale" became a meme with its own animated video; relational databases were declared legacy technology walking; and every startup pitch deck had a slide explaining why their to-do app needed the storage architecture of Google. The flame war had exactly two camps, and the question that named it — SQL vs NoSQL — is still, sixteen years later, one of the most-asked questions in system design interviews.

Here's how the war actually ended. PostgreSQL — the most conservative, most relational database alive — is now used by 58.2% of professional developers, the most popular database in the 2025 Stack Overflow survey by an eighteen-point margin, its biggest yearly jump on record. Meanwhile MongoDB ships multi-document ACID transactions and a SQL-ish query layer, YouTube serves 2.49 billion users on MySQL, and the 2024 Stonebraker–Pavlo retrospective's verdict — the one this course keeps returning to — is that data models converged toward relational while engine architectures specialized. Nobody won the war. The sides merged.

Which leaves the interview question — and the real architectural decision behind it — in a strange place. "SQL or NoSQL?" is a fake binary. It bundles at least six independent decisions into two tribal flags, and the flags tell you almost nothing: you spent nine lessons learning that key-value, document, wide-column and graph stores are four different bets, not one movement.

So this lesson does the only honest thing left: it unbundles the question. Six questions, each answerable with vocabulary you already own, each visibly pushing the answer — and then you'll run the instrument yourself, on four real workloads. The flame war gets one wink and no more. We do engineering here.

"NoSQL" was never one idea. Under that flag, around 2009, at least four separate rebellions marched:

• a data-model rebellion — "my data isn't tables" (documents, graphs, key-value blobs),
• a consistency rebellion — "I'll trade transactional guarantees for availability and speed",
• a scale-mechanics rebellion — "I need writes spread across machines, and 2009's relational tooling couldn't",
• and a schema-discipline rebellion — "stop making me run migrations" (which the document lesson already dismantled: the schema moved into your code; it didn't disappear).

Four rebellions, four different remedies — and crucially, you can want any one of them without the others. A ledger that needs horizontal write scale but ironclad transactions (the scale rebellion without the consistency one) points at distributed SQL, not at a document store. A product whose data is genuinely a graph but fits on one machine points at a graph engine with no distribution at all. The two flags collapse exactly the distinctions that matter.

The map lessons gave you the sharper vocabulary: every store is a layout bet on a question shape, and work is proportional to how well the bet matches. So the real decision was never "which tribe." It's six specific questions about your workload — and after ten lessons, you can answer every one of them.

Q1 — What's the shape of your hottest question? Not all your queries — the one the product asks ten thousand times a second. By key? Flexible and relational? A whole aggregate? A traversal? A time window? Words? Similarity? A scan-and-aggregate? That's the family map, applied. Your hottest question nominates a candidate; the rest of the rubric confirms or vetoes it.

Q2 — Do multiple facts have to change together? When an order is placed, stock decrements and a payment records — all or nothing. If invariants like that sit at the heart of your domain (anything with money usually qualifies), the constraint shields and transactions from the relational lesson stop being nice-to-haves. This question carries veto power: an eventually-consistent primary store under a ledger is not a trade-off, it's a bug you scheduled.

Q3 — Do you know tomorrow's queries? Codd's bargain — describe data by its natural shape, get query freedom forever — versus the wide-column doctrine — the table IS the query, new question ⇒ new table. Both are honorable; they price change differently. If you genuinely cannot list next year's questions (true for almost every young product), the freedom-forever side is worth real money. If the questions are locked by the product's physics (a message feed is a message feed), pre-shaping is pure profit.

Q4 — What are your honest numbers? Not "we might be big someday" — numbers. Data size, write rate, growth curve. Then remember the ladder: one well-tuned box goes further than anyone believes (Stack Overflow served over a billion pageviews a month on roughly four SQL Server boxes); read replicas carry read-heavy loads; and past that, relational still scales — Slack runs about six thousand servers of sharded MySQL under Vitess. The question isn't "is my data big?" It's "do I genuinely need writes spread across machines, with numbers that prove it?"

Q5 — How stale may each read path be? Straight from the OLTP vs OLAP lesson: read-your-writes paths (the confirmation screen) versus minutes-stale paths (the dashboard, the feed's unread count). Strictness everywhere is expensive; staleness declared per-path opens cheap options — replicas, caches, analytical copies — without betting the primary store on it.

Q6 — Who carries the pager? A boring answer that decides real architectures: a four-person product team should weight managed services and ecosystem gravity heavily (everyone can hire for Postgres; your cloud has a checkbox for it). A platform team with database SREs can afford exotic choices. The best database you can't operate at 3 AM is worse than the second-best one you can.

Notice what's not on the list: fashion, fear of missing out, and "scale" as a mood. Every axis is a property of your workload, not of the year's conference talks. Now run it —

Rubrics are cheap to write and easy to doubt, so here are the receipts — famous migrations in both directions, each one the rubric applied by someone with production scars.

"SQL can't scale" — dead, with numbers. YouTube grew MySQL to 2.49 billion users by building Vitess, a sharding layer that makes a fleet of MySQL servers answer like one database — billions of rows, millions of queries per second. Vitess graduated into a CNCF project; Slack runs ~6,000 servers on it; GitHub and Square ride the same rails; the largest known deployment is around seventy thousand servers. And for global-write cases, Spanner (2012) proved horizontally scalable, strongly consistent SQL was possible — CockroachDB and friends made it installable. The "SQL wall" was an operational wall, circa 2009. Tooling ate it.

"Real scale means NoSQL" — also dead. Pinterest, mid-hypergrowth, ran Cassandra and MongoDB and dropped both — their engineering blog is blunt about immature systems "crashing in spectacular ways" — and scaled to tens of billions of pageviews a month on sharded MySQL, memcache and Redis. And the decade's most-read database post-mortem, Sarah Mei's "Why You Should Never Use MongoDB" (2013), documented Diaspora discovering that social data is secretly relational: every new feature wanted a link across document boundaries, and the aggregate bet punished each one. That's our Q3 failing in public — they did not know tomorrow's queries, and they'd bought the store that punishes surprise.

And the honest other direction. Discord's messages outgrew MongoDB's write path (Q1: append-heavy, key-clustered, known queries — the wide-column shape from our map), so they moved to Cassandra in 2017. The family was right and stayed right; the engine wasn't — the cluster grew fifteen-fold to 177 nodes and trillions of messages, tail latencies souring — so in 2022 they migrated to ScyllaDB, same data model, 72 nodes, better tails, the whole transfer done by a Rust migrator in nine days instead of a projected three months. Model ≠ engine, one more time: pick the family with the rubric; hold the vendor loosely.

Every one of these teams was rational. The migrations disagree in direction because the workloads disagreed in shape — which is the entire thesis of this lesson.

If the rubric has a definitive production run, it's this one. In October 2019, Amazon's consumer business turned off its final Oracle database — the end of a years-long migration covering roughly 7,500 databases and 75 petabytes, across more than a hundred teams: Alexa, Prime, Prime Video, Fresh, fulfillment, payments.

Here's the part that matters for this lesson: Amazon — the company that invented Dynamo, the company with the strongest possible incentive to declare NoSQL the winner — did not pick a side. They routed each workload by its shape: low-latency key-access workloads went to DynamoDB and ElastiCache; transactional workloads with hard consistency needs went to Aurora and RDS — relational; analytics went to Redshift — columnar, the OLTP vs OLAP lesson at petabyte scale. Cost fell by more than sixty percent, with barely any downtime.

Read that as a sentence: the biggest database migration ever completed treated "SQL vs NoSQL" as a per-workload routing decision, not an identity. Seven thousand five hundred rubric runs, batched. When an interviewer asks you "SQL or NoSQL?", this is the shape of a staff-level answer: "for which workload?" — followed by the six questions, out loud.

So what's left of the word? In 2026, "NoSQL" usefully means: a set of specialized engines you reach for when a specific bet is real — and you can now name every bet. Microsecond key access under brutal write load (the coat check). Aggregates that live and die whole (the document bet, arrays bounded). Sorted, partitioned width at petabyte write rates (the cabinet with folders). Relationships at variable depth. Time, words, similarity. Each one earns its place by matching your Q1 — never by tribe.

Meanwhile the merger keeps merging from both sides. MongoDB added multi-document ACID transactions (4.0, 2018) and increasingly SQL-shaped querying — conceding Q2 and Q3 mattered. Relational engines absorbed JSON columns, vector indexes and graph queries — conceding the data-model rebellion had a point. The convergence bell from the landscape lesson rings loudest exactly here: the models converged; the architectures specialized. The tribal question dissolved into engineering.

One writing habit will mark you as someone who was paying attention: stop saying "a NoSQL database" as if it names a thing. Say the family. "A wide-column store, because the write path is append-heavy and the queries are known" is an argument; "NoSQL, because scale" is a mood — and you now know the receipts against it.

Collapse the whole lesson into a doctrine and it fits in three lines:

Start with Postgres (or MySQL — the boring, load-bearing default the industry measurably converged on). It answers seven of the eight family questions well enough at small-to-mid scale, keeps Codd's query freedom while your product discovers what it is, and everyone you'll ever hire can run it.

Specialize when a workload proves it — with numbers, not vibes. A named query shape outgrowing its welcome (Q1 + Q4), an invariant the default can't hold cheaply, a staleness budget that opens a cheaper door. The specialist arrives as a sidecar with a job description — a cache, a search index, a time-series store, an analytical copy — while the system of record stays boring as long as it can.

And re-run the rubric when the answers change. It's not a wedding; it's a routing decision, and Discord re-ran it twice on the same table.

That's the store decided. But a store is only half a data design — the other half is the shape of the data inside it, and shaping data by your access patterns is its own discipline with its own traps. That's next: model the queries, not the world.