NoSQL without the hype: what it solves and what it only complicates

NoSQL emerged as a response to real limitations of relational databases under specific load scenarios. That is an honest and understandable story. But over a few years a different story built up around it - that relational databases are obsolete, that "serious" projects do not work that way, that schema flexibility is always a good thing.

I have met teams that chose NoSQL not because they needed it, but because it seemed more professional. It cost them dearly. The same pattern applies to Hadoop - choosing a tool for the wrong task is expensive regardless of how modern that tool is.

What NoSQL actually solves

There are several scenarios where NoSQL approaches deliver a real advantage:

• High write throughput with horizontal scaling. If you need to ingest millions of events per second from distributed sources, a relational database becomes the bottleneck. Systems like Cassandra or HBase were designed for exactly this scenario.
• Flexible document structure. If each object can have a different set of fields and the schema changes quickly, a document model (MongoDB, CouchDB) is more convenient than ALTER TABLE.
• Graph relationships. If the task is to traverse links between entities many levels deep, a graph database handles this more naturally than JOINs.
• Key-value pairs with low latency. Cache, sessions, counters - Redis handles this better than any relational database.

In all of these cases the choice is justified by a specific technical requirement you can point to.

What NoSQL does not solve - and often complicates

Schema flexibility easily becomes a source of problems. When documents have no rigid structure, responsibility for data integrity moves into application code. That means: multiple schema versions in the same collection, migration logic spread across different places, hard-to-read queries.

Transactions are a separate story. Most NoSQL systems at the time of their emergence did not support multi-object transactions with ACID guarantees. For operational systems - accounting, orders, finance - this is not an academic question. It is a question of data correctness.

Aggregations and reporting are also harder. SQL remains the most expressive tool for analytical queries. Attempting complex aggregations in a document store or a key-value store usually ends either in map-reduce or in moving the data back into a relational system.

Three questions before choosing

I use three parameters as a filter:

Consistency. Is it acceptable for different clients to see different versions of the data at the same moment? For an event feed - yes. For an account balance - no.

Load. Do you have actual measurements showing that a relational database cannot handle the required volume? Or is this an assumption about future load? Premature choice for a hypothetical load is one of the most common sources of unnecessary complexity.

Cost of maintenance. Does the team have people who understand how this database behaves under failure, how to back it up, how to migrate the schema? Operational maturity matters.

Relational databases are not dead

PostgreSQL today can store JSON documents, do full-text search, work with arrays, and supports replication. This does not mean it replaces specialised NoSQL systems in extreme scenarios. But it does mean that for most mid-market tasks, a relational database with a proper schema is a defensible choice - not a sign of being behind the times.

A short filter

Before choosing a NoSQL solution, it is worth answering honestly:

1. What specific limitation of a relational database are we working around?
2. Do we have load data, or are we making assumptions?
3. Who will maintain this solution in a year?
4. What do we lose in transactional integrity and how do we compensate?

If these questions have no clear answers, a relational database is probably the reasonable choice. NoSQL is a tool for a job, not a philosophy.