Document databases let teams place related data together or store it separately and connect records by reference. Neither choice is inherently more modern or faster. The right model follows ownership, update frequency, query patterns, and the boundaries between parts. A SaaS product also needs tenant isolation and a plan for keeping copied information accurate when source records change.
Start with the business aggregate
Ask which facts are created, updated, and read together. An order may include line items that belong to the order's lifecycle. Keeping them in one document can make the common read and atomic update straightforward. A customer account or author profile may change independently and be shared by many items, so storing a full copy everywhere can create maintenance work. Avoid embedding an unbounded list that grows forever or forces a large document rewrite for a small change. Model around operations customers perform rather than around one page's initial shape.
Respect part ownership
Within a part, related items may be kept as separate records and connected through supported queries. Across part boundaries, a product may copy complete related data into a consuming item because parts can live in different physical databases and cannot rely on cross-database views. That copy needs a source of truth and a refresh strategy. It should not become an independent editable version of the same fact without a business reason. A public part operation can provide the snapshot the consumer needs, while preserving the owner's validation and permissions.
Compare read and write costs
Embedding can reduce repeated reads when the same fields are displayed together. Referencing can avoid updating many copies when a shared record changes. Measure how often each operation occurs and how large records become. A list card may need an author name and avatar, while a detail page may need the full profile. It can be sensible to embed a stable display summary and load the full item separately. Avoid solving an N plus one query by copying a huge related object into every document without considering update and storage costs.
Define consistency expectations
If a product name changes, should old invoices retain the historical name or display the current one? The answer determines whether a snapshot is correct or stale. For transactions, historical copies can be essential. For a live directory, customers may expect updates to appear everywhere quickly. Write down which fields are snapshots and which must synchronize. Use events or background updates only when the operational complexity is justified, and monitor failures. A stale copy that no one can detect can be worse than an extra bounded query.
Include tenant and security rules
Every reference or embedded copy must preserve tenant ownership. A query that resolves a reference by ID alone may attach another customer's record. Validate relationships at write time and check permissions when rendering sensitive data. Search indexes and caches may hold additional copies; include them in the update plan. If a tenant is deleted, define how references and embedded data are removed. Data modeling is part of isolation, not only performance. Test cross-tenant attempts with similar item names and known IDs.
Evolve the model in stages
Start with representative reads and writes, then adjust when metrics show a bottleneck or business rule changes. A migration from reference to snapshot needs backfill, new-write behavior, and a period when readers tolerate both shapes. Verify old documents, not only fresh test fixtures. For SMB software, the best model is one the current team can explain and maintain. Embed when ownership and lifecycle align; reference when independent identity and change matter; copy across part boundaries with an explicit consistency contract. Review the model when access patterns change, such as a new reporting requirement or a tenant-specific export. A document shape that is ideal for one read can be poor for another; measurements should guide whether to add a derived view or change the source model.