NoSQL Data Modeling Rules

Model a document database around how the data will be read, not around eliminating duplication — normalization is a relational-database goal; a document database rewards shaping each document so the application's actual queries need one read, not a join.

Design for access patterns

• Start modeling by listing the application's actual queries ("get a user's last 10 orders with item names") before designing the document shape — the shape exists to serve those queries efficiently, and designing the shape first and figuring out queries later routinely produces a schema that needs a redesign once real query patterns show up.
• Expect the same underlying data to be shaped differently in two different collections if two very different access patterns both need fast reads of it — this intentional duplication is normal in document modeling, not a mistake to "fix" by normalizing.

Embed vs. reference

• Embed related data in the same document when it's always read together with the parent, has a bounded size, and doesn't need to be queried independently (an order's line items inside the order document) — embedding turns a would-be join into a single document read.
• Reference (store an ID, query separately) when the related data is large, grows unboundedly, is shared across many parents, or needs to be queried/updated independently of the parent (a product referenced by many orders) — embedding a shared or growing entity duplicates it everywhere it's embedded and makes updating it require touching every copy.
• Default to embedding for one-to-few relationships and referencing for one-to-many-or-more and many-to-many — this single heuristic resolves the large majority of embed-vs-reference decisions correctly.

Denormalization discipline

• When duplicating a field across documents for read performance (denormalizing a user's display name onto every comment they wrote), identify explicitly at design time every place that copy lives and how it gets updated when the source changes — denormalization without an update plan is how "Jane's old name" quietly survives in stale comments for years.
• Prefer denormalizing only fields that rarely change (a display name, not a live status) — the update fan-out cost scales with both the number of copies and how often the source changes, so pick fields where at least one of those is small.

Unbounded arrays

• Never let an array field inside a document grow without bound (all of a user's activity events pushed into one array on the user document) — MongoDB documents have a hard size limit, and even below that limit, a large unbounded array degrades read/write performance on every operation touching the document long before the size limit is reached.
• Move unbounded or fast-growing collections of related data into their own collection with a reference back to the parent, not into an array on the parent — this is the same one-to-many signal as the embed-vs-reference decision above.

Indexing

• Create indexes based on the application's actual query filters and sort fields, not speculatively on every field — an index that doesn't match a real query pattern costs write performance and storage for no read benefit.
• Build compound indexes that match the exact combination of fields a query filters and sorts on, in the order the query engine can use them (equality fields before range/sort fields) — a compound index built in the wrong field order silently fails to serve a query it looks like it should.

Schema validation

• Apply schema validation (JSON Schema validators, or the ORM/ODM layer's schema definitions) even though the database itself won't enforce structure — "schemaless" means the database doesn't require a fixed shape, not that the application should tolerate documents with inconsistent, unvalidated shapes; unvalidated writes are how a collection silently accumulates several incompatible document shapes over time.
• Version the document shape explicitly (a schemaVersion field) when a shape change can't be applied to every existing document atomically, so application code can handle both the old and new shape during migration instead of assuming a shape that not every document actually has yet.