The “SQL vs. NoSQL” debate is misguided. These aren’t two competitors, one of which would “win”; they are two families of tools that solve different problems. The real question isn’t which one is better, but what the cost of inconsistent data is in your application.
The two families, in one sentence each
A relational database—PostgreSQL, MySQL—stores data in tables with predefined columns and ensures that the relationships between them remain valid. You cannot create an order linked to a nonexistent customer: the database will reject it.
A document-based database—MongoDB and its counterparts—stores documents whose format can vary from one record to another. It imposes no structure and does not validate relationships: your code is responsible for that.
The deciding factor: What is the cost of an inconsistency?
If incorrect data in your system means a lost payment, inaccurate inventory, an incorrect invoice, or a ticket sold twice, choose a relational database. Transactional guarantees aren’t a luxury for engineers: they’re what prevents an operation interrupted midway from leaving the system in an absurd state.
If incomplete data simply means an approximate display—a browsing history, an event log, a cache, or editorial content whose format varies—the flexibility of a document database comes at no cost.
This is the primary criterion. The others come second.
Secondary criteria, in order
The format of your data. Stable, interconnected entities—customers, orders, products, invoices—naturally correspond to tables. Heterogeneous objects, whose fields vary depending on the context, are better suited to documents.
The nature of your queries. If you’re going to cross-reference information from multiple entities—such as “revenue by region and quarter for customers registered this year”—a relational database can do this with a single query. In a document-based system, this translates to application code that must be written and maintained.
The actual volume. Performance is the most frequently cited argument—and the least relevant. A properly indexed relational database effortlessly handles millions of rows. Most projects that cite scalability concerns will never reach the volume at which the issue even arises.
What the team is capable of. A technology mastered by a single person becomes a risk the day that person is no longer available. SQL is a well-established language, taught everywhere, and easily transferable.
Three Real-World Examples
An online store: relational. Inventory, orders, payments, and customers are interconnected, and any inconsistency directly results in lost revenue or disputes.
A news site or media outlet: either approach works. The most widely used content management systems rely on relational databases, and that doesn’t pose a problem for them. The choice will be based on the available ecosystem and hosting options, not on the database itself.
A stream of events or metrics—logs, sensors, activity tracking: a document database or specialized database. There are massive volumes of writes, the structure varies, and a marginal loss is inconsequential.
What’s Almost Always Overlooked
Modern relational databases natively store and query documents. PostgreSQL handles JSON with indexing; MySQL does as well. In other words, you can have document-oriented flexibility where you need it, without sacrificing guarantees elsewhere. This is enough to resolve the vast majority of cases that seemed to require switching database families.
The second, more costly oversight: backup and restore. The question to ask isn’t “which database should I choose?” but “have I already tested a full restore?” A backup that’s never been restored isn’t a backup.
In Summary
| Your Situation | Reasonable Choice |
|---|---|
| Money, inventory, reservations, billing | Relational |
| Stable, related entities | Relational |
| Cross-analysis needs | Relational |
| Documents of variable format | Document-based, or JSON in a relational database |
| Logs, metrics, high write volumes | Document-based or specialized database |
| Uncertainty and a small team | Relational—it’s the most reversible choice |
When in doubt, start with a relational database. Not out of conservatism, but because it’s the least costly option to move away from: the data is structured, so it can be exported to anything else. The reverse is not true.
This type of decision is made at the design stage, and its consequences last for years—it’s one of the reasons why choosing who builds the application matters just as much as choosing the technology.