We've all been there. You're in a technical planning meeting, and someone inevitably asks: "Should we use MongoDB for this?" The question hangs in the air like a challenge to your engineering credibility. Say yes, and you're modern, scalable, "cloud-native". Say no, and you risk being labeled as that developer who still thinks it's 2005.
But here's the uncomfortable truth: most applications reaching for NoSQL databases are solving problems they don't actually have yet, while creating new ones they definitely don't need.
Let me be clear from the start—this isn't an indictment of NoSQL technologies themselves. These databases exist because they solve real problems for real companies. The issue isn't with the tools; it's with how they're often positioned as the default choice for developers who often haven't yet encountered the specific problems they're designed to solve.
The seductive promise of "schema-free"
The NoSQL pitch is compelling, almost irresistible. Why constrain yourself with rigid schemas when you could have the freedom to evolve your data model on the fly? Why worry about JOINs when you can just embed everything in a single document? It sounds like liberation from the tyranny of relational thinking.
Except schema-free is a misnomer. Your application still has a schema—it's just implicit, undocumented, and scattered across your codebase. Every time you access something like user.preferences.notifications.email, you're making assumptions about a data structure. The difference is that PostgreSQL would have told you upfront when those assumptions were wrong. MongoDB waits until 3 AM on a Sunday to surprise you with a production error.
Consider this: how many times have you actually needed to store fundamentally different document structures in the same collection? Not variations of the same theme—like users with different sets of optional fields—but genuinely different shapes of data all co-mingling together. If you're honest, it's probably close to zero. Most of the time, we're storing users, orders, products, and other well-defined entities and interfaces that have well defined, predictable structures.
The operational complexity tax
Here's where the real cost reveals itself. SQL databases come with an ecosystem fifty years in the making. Every operations engineer knows how to backup, monitor, and optimize them. Performance analysis tools are mature. Recovery procedures are well-documented. The hiring pool is vast.
NoSQL databases, for all their promises, often feel like engineering archaeology. Each one has its own query language, its own performance characteristics, its own failure modes. MongoDB's working set memory requirements, Cassandra's compaction strategies, DynamoDB's hot partition problems—these aren't just operational concerns, they're specialized knowledge domains.
Your startup doesn't need a DynamoDB expert. It needs someone who can write efficient queries, understand indexing, and debug performance issues. These skills transfer across SQL databases. They don't transfer to whatever NoSQL solution seemed trendy last quarter.
The ACID reality check
Let's talk about transactions. NoSQL advocates often dismiss ACID properties as old-fashioned concerns, but data integrity isn't a legacy requirement—it's a fundamental necessity.
Imagine you're building a simple e-commerce application. A user places an order: you need to update your inventory, charge their card, and create an order record. In a relational database, this is a straightforward transaction. If any step fails, everything rolls back. Your data remains consistent.
In a NoSQL world, you're suddenly building a distributed systems expert. You're implementing saga patterns, dealing with partial failures, and building compensating transactions. You've transformed a simple business operation into a complex choreography of eventual consistency.
Was the complexity worth it? What problem did you solve that justified this operational overhead?
The premature optimisation trap
The dirty secret of most NoSQL adoptions is that they're premature optimisations disguised as architectural decisions. We're so focused on theoretical scalability that we ignore practical productivity.
SQL gives you immediate productivity wins that compound over time. Need to analyse user behaviour? Write a query. Want to generate a report? JOIN some tables. Debugging a data inconsistency? Follow the foreign keys. These aren't impressive technical achievements—they're the boring, reliable tools that let you focus on your actual business problems.
NoSQL databases excel in specific scenarios: time-series data, content management systems with truly variable schemas, or applications with genuinely massive scale requirements. But most applications are building user management, content publishing, or e-commerce functionality. These are well-understood problems with well-understood solutions.
The path forward
This isn't an argument against innovation or appropriate technology choices—it's a plea for engineering honesty about when to innovate. NoSQL databases have earned their place in the technology ecosystem by solving problems that relational databases genuinely struggle with. The challenge is distinguishing between situations where you need those solutions and situations where you're borrowing complexity from someone else's problem domain.
Choose your database based on your actual requirements, not your aspirational ones. Most importantly, understand that there's a natural progression to these architectural decisions.
Start with PostgreSQL. Use its JSON columns if you need document storage. Leverage its full-text search capabilities. Scale it vertically until you can't, then scale it horizontally. When you finally hit its limits, you'll have real data about your access patterns, your bottlenecks, and your scaling needs.
At that point, you'll know whether you need to migrate everything or split off some data into a time-series database, a graph database, a vector database, or maybe even a distributed document store. You'll make the choice from a position of knowledge rather than speculation. And when you do make that choice, you'll be using NoSQL databases for what they're genuinely good at—not as a substitute for learning how to use relational databases effectively.
The most radical thing you can do in today's engineering culture is to choose boring technology—at least until you understand why the exciting technology exists. Your users don't care about your database choice—they care about features that work reliably. Your future self will thank you for choosing the tool that solved your actual problems rather than the one that looked impressive in conference presentations.
Sometimes the best engineering decision is the one that lets you focus on engineering everything else.