Document or Relational: Read-Time or Write-Time Cost

Both models pay for the same thing at different times. The relational one keeps a single copy and assembles shapes on read, paying in join work; the document one stores assembled shapes and pays in duplication and write coordination.

AWS states the inversion in its own design guidance: “Instead of reshaping data when a query is processed (as an RDBMS system does), a NoSQL database organizes data so that its shape in the database corresponds with what will be queried.” The same page is explicit about the order of work — you are told not to design the schema until you know the questions it has to answer. What follows is where each side of that trade is cheap.

When does a document store fit the access pattern?

An order with its line items, shipping address, and status history is one document. The order page reads it with one request. There is no join because there is nothing to join — the boundary of the stored object is the boundary of what the page needs.

That is the case where a document store is not a compromise. The read is a single key lookup returning exactly the required bytes, and it stays a single key lookup at any data volume, because nothing about it scans.

The same property makes writes clean when they arrive at the same granularity. Adding a line item rewrites one document.

When does document modeling stop working?

A second access pattern with a different shape. Now you also need “all orders for a customer” and “all orders containing product X”. Neither is a lookup on the order key. The answers are a secondary index, or a second copy of the data keyed differently, and in DynamoDB’s single-table designs that is the explicit technique. The relational counterpart is another index on the same table, where the column order decides which predicates it can serve.

Each copy is a write amplification and a consistency obligation. Two copies of an order mean two writes, and something has to reconcile them if the second fails.

Ad-hoc questions. “Orders over 500 euros from customers in Portugal placed last March” is a query nobody modeled. Relationally it is a WHERE clause — one that still depends on the planner deciding an index is worth using, but one that needs no schema change to run. In a document store it is a full scan, or an analytics copy of the data kept somewhere else.

Unbounded embedding. A document that grows with activity — an audit trail, a comment thread — eventually hits the size limit, which in MongoDB is 16 MiB, and degrades long before that because every read transfers the whole document. Embed bounded collections; reference unbounded ones.

Which bill is smaller

Embedding bounded collections and referencing unbounded ones is one instance of the trade the opening named: a shape you store cheaply now is a shape you pay to keep correct later.

The join work is paid by whatever assembles the shape, and an ORM that assembles it lazily pays it as one query per element of the collection. The duplication is paid by whatever keeps the copies agreeing, on every write rather than on the reads that benefit from it.

Which is cheaper depends on the read/write ratio and on how many distinct shapes exist. A small number of well-known access patterns with a high read rate favors the document model strongly. A large or growing number of shapes favors the relational one, and the growth is usually not predictable at design time.

What would change the conclusion

That balance holds only while the number of shapes does, and two things move it.

If a new access pattern appears every quarter, the document model accumulates copies and the cost of each new shape rises. If the access patterns are fixed by a narrow API contract, they do not.

And if the workload requires transactions across aggregates, the argument weakens considerably. MongoDB supports multi-document transactions, but needing them regularly is a signal that the aggregate boundary was drawn in the wrong place — which is a modeling problem, not a technology problem.