When the relational model is the wrong fit

Everything so far assumed tables, rows and a schema. That model has been the default for decades because it is genuinely good. It is not always right.

The families

What is actually given up

The honest summary is that these systems trade joins and transactions across records for easier horizontal partitioning.

A relational join needs both rows available together. Partition the data across twenty machines and a join may need to reach all of them, which is slow and sometimes not offered at all. Document stores avoid the problem by keeping related data in one record.

That is also the cost. Duplicated data means updating it in several places, and nothing enforces that you did.

Consistency

Many distributed stores offer eventual consistency: a write will be visible everywhere, later. For a product view count, fine. For a bank balance, not fine.

The CAP theorem is usually quoted here and usually overstated. What it says is narrow: during a network partition, a system must choose between refusing requests and serving possibly stale data. It says nothing about normal operation, and it does not say you must give up consistency in general.

Choosing, honestly

Start relational. It handles more scale than most people expect, it gives constraints and transactions for free, and the schema catches mistakes early.

Move when there is a specific reason you can name:

• the data genuinely has no fixed shape, per record
• write volume exceeds what one machine can take, and sharding is unavoidable
• the queries are about relationships several steps deep, which is a graph
• you need a cache, which is a key value store and always has been

"It scales better" is not a reason on its own. Postgres on one large machine serves an enormous amount of traffic, and most teams that switched for scale discovered their bottleneck was a missing index.