A team proposes replacing PostgreSQL with a document store because "it scales better". Current load is 800 writes per second. What is your response?

What is being tested

Whether you demand evidence before accepting a large, mostly irreversible trade.

The reasoning

Eight hundred writes per second is a workload a single well-configured relational instance handles with substantial headroom. It is not near any limit that would justify giving up joins, transactions, constraints and ad-hoc querying.

The right question is not "which is faster" but "what specific access pattern is failing, and why?" Usually the answer reveals something else entirely:

• Slow queries that need an index or a rewrite.
• An N+1 pattern in application code, invisible in the slow query log.
• Missing connection pooling, so the database is spending its time on connection setup.
• A schema that is fine but is being queried in a pathological way.
• Deep offset pagination generating and discarding hundreds of thousands of rows.

Each of those is fixable in days. Migrating to a different data model is a quarter of work and permanently forecloses options.

What would justify the move

A concrete characteristic the relational engine genuinely cannot serve:

• Write volume beyond one machine with no natural partitioning boundary available.
• A requirement to accept writes during a partition — the original Dynamo case at Amazon, where a shopping cart had to remain writable because a customer unable to add an item is lost revenue, while a briefly odd cart is recoverable. That is a specific business asymmetry, applied to one operation, not a company-wide preference.
• Genuinely schemaless documents with no stable shape.
• Access patterns that are exclusively by known key and never change, at a scale where predictable single-digit-millisecond latency is a product requirement.

What is lost

The property people miss most is not joins — it is the ability to answer a question nobody anticipated. A relational schema plus an index answers a new query in an afternoon. A document store designed around three access patterns answers a fourth with a re-model or a secondary index that undermines the performance story that justified it.

The pragmatic path if the concern is real

Keep the relational database as the system of record and add the specialised store for the specific workload that needs it. That is a bounded, reversible decision. Replacing the primary store is neither.

What is wrong with the other options

Sharding PostgreSQL is premature at this volume and takes on cross-shard costs for no reason. A graph database as a "compromise" is not a compromise; it is a third unrelated answer to a question nobody asked.