SQL and NoSQL

The question is asked as a binary and is not one. “NoSQL” names four unrelated data models whose only shared property is not being relational, and the useful answer starts by refusing the framing: what is the access pattern, what invariants must hold, and what shape is the data?

The four families are not interchangeable

Grouping these as “NoSQL” is like grouping “not-a-hammer”. A key-value store and a graph database have nothing in common except the absence of tables, and choosing between them is a completely different conversation from choosing between either and Postgres.

Relational is the default, and here is why

Not tradition — the query you have not thought of yet.

-- Nobody designed for this. It works anyway.
SELECT c.region, count(*), avg(o.total)
FROM orders o JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > now() - interval '30 days'
GROUP BY c.region;

In a document store, that query requires either an aggregation pipeline over a shape that was not designed for it, a second denormalised collection kept in sync, or an export to something else. The relational model’s real product is ad-hoc queryability, and you spend it the moment you denormalise.

The second reason is invariants:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;   -- both, or neither

ACID is what lets you say “this cannot happen” rather than “we reconcile nightly”.

What ACID and BASE actually claim

Gotcha: “NoSQL means no ACID” is a 2015 claim and interviewers notice. As of 2026, MongoDB has had multi-document ACID transactions since 4.0 and DynamoDB has TransactWriteItems. The honest statement is that distributed transactions are available but expensive, and the systems are designed so that you avoid needing them.

The C in ACID and the C in CAP are also different things — constraint validity versus replica agreement. Conflating them is a common slip; see CAP, ACID, BASE, PACELC.

When a document store genuinely wins

Three conditions, and you want all three:

1. The aggregate is read and written whole — a product with its variants, a form with its answers.
2. The shape varies per record in ways a table would model as forty nullable columns.
3. You do not need to query across documents.

// One read, no joins — this is the win.
db.orders.findOne({_id: id})
// { _id, customer: {...}, lines: [...], payments: [...] }

Storing a relational model in documents and then joining in application code is the common mistake. You have taken on the denormalisation cost and kept none of the benefit.

Scaling, honestly

NoSQL scales writes horizontally more easily. That is real, and it is also the answer to a problem most systems do not have: a single Postgres instance in 2026 handles far more than people assume, and read replicas plus partitioning extend it a long way further.

The trade you make when you shard is permanent — no cross-shard joins, no cross-shard transactions without cost, and a partition key you cannot change without a migration. Exhaust vertical and read-replica scaling first, because that decision is reversible and sharding is not.

Polyglot persistence

The realistic production answer is several stores:

• Postgres as the system of record.
• Redis for cache and sessions.
• Elasticsearch or OpenSearch for text search.
• Object storage for blobs.

The cost is operational surface and consistency between them — every copy is a thing that can go stale, and CDC or an outbox is how you keep it honest. See Message queues.

Related

• NoSQL Decision Guide — Which Store, and When — choosing within NoSQL
• CAP, ACID, BASE, PACELC — CAP, properly stated
• Sharding and Partitioning — scaling relational