Why SQL kept winning
Every NoSQL wave rediscovered constraints under a new name. The relational model was never the bottleneck — wrong data was.
SQL is the most unfashionable success in software. Conference stages have declared it dead since the 2000s. Document stores, wide-column engines, graph databases, and "web scale" memes all promised liberation from joins and migrations. Postgres and friends kept winning payroll, anyway — not because DBAs are conservative, but because businesses run on invariants SQL expresses cleanly.
The NoSQL-everywhere fad was not stupid at the origin. Google and Facebook had problems most companies do not have. Denormalization, eventual consistency, and partition tolerance are real tools when traffic and availability constraints demand them. The fad became costly when venture-backed startups with fifty thousand rows treated schema design as oppression and rebuilt relational integrity in application code — poorly, expensively, at 2 a.m.
MongoDB became the punchline, then grew up — transactions, adult defaults, ops stories — because ridicule is expensive and customers voted with renewal checks. Elasticsearch and Redis thrive as specialists, not as replacements for the system of record. Even the "modern data stack" largely orchestrates files and streams back into warehouses queried with… SQL.
The lesson is not "never use anything but Postgres." The lesson is that joins, uniqueness, and transactional boundaries are product requirements wearing math. When you skip them at the database layer, you pay interest in services, cron jobs, and angry finance teams. Most CRUD products discover they needed ACID when the first reconciliation failed — not when the first million users arrived.
ORM-heavy frameworks compounded the confusion by making SQL feel ugly while hiding query cost. Developers who never learned to read EXPLAIN plans blamed the database when N+1 queries ate latency. That is a tooling and education failure, not evidence that relations were wrong.
Blockchain-for-CRUD repeated the same mistake with more steps: immutable ledgers for workflows that needed mutable business data and auditors who already accepted signed rows in Postgres. The technology changed; the delusion that storage novelty replaces domain modeling did not.
SQL kept winning because wrong data costs more than any license fee. Fashion cycles; invoices from bad inventory, double-spend, and unreportable revenue do not. Boring relational models are still the default for a reason — and the reason is not lack of imagination. It is scar tissue from every team that tried to outsmart Codd with enthusiasm.
Related tech
Patterns
Cases