Review the model before shipping it

Use this checklist during design reviews and before major schema changes.

Access patterns

• Are the most frequent queries written down?
• Are their filters, sorts, projections, pagination, and expected result sizes known?
• Have indexes been designed around those queries?
• Have representative execution plans been inspected?

Relationships and growth

• Are embedded arrays bounded or naturally small?
• Are unbounded relationships stored separately?
• Are relationship collections indexed for both important access directions?
• Are uniqueness rules represented with unique indexes where appropriate?

Consistency

• Is the source of truth for every duplicated field documented?
• Are snapshots distinguished from current values?
• Are critical updates conditional or transactional where required?
• Are retry and idempotency behaviors defined?

Data quality

• Are BSON types consistent?
• Are missing and null semantics intentional?
• Are validators and enum-like fields appropriate?
• Are schema migrations safe during rolling deployments?

Operational and security concerns

• Are large documents, hot documents, and write contention considered?
• Are retention and deletion policies explicit?
• Are sensitive fields accessible only to authorized services?
• Is there a way to audit, reconcile, and rebuild derived data?

Common anti-patterns

1. Embedding everything: creates oversized documents and large arrays.
2. Referencing everything: creates excessive round trips and complex reads when data is always co-accessed.
3. Unbounded arrays: grow without a retention or pagination strategy.
4. Duplicating mutable facts without a sync plan: produces inconsistent copies.
5. Mixing types in one field: makes queries and application code unpredictable.
6. Using transactions to compensate for a poor model: adds coordination without fixing an unnecessarily complex design.
7. Designing from toy data only: hides skew, growth, and contention.
8. Adding indexes without workload evidence: increases storage and write costs.
9. Treating references as enforced foreign keys: leaves dangling-reference behavior undefined.
10. Changing schema without a migration plan: breaks older application versions or leaves mixed shapes indefinitely.

Final rule

The best MongoDB schema is the one that expresses the domain clearly, supports required access patterns, controls growth, and makes consistency rules explicit. Validate the design with realistic workloads and revisit it when the workload changes.

const schemaReview = {
  accessPatternsDocumented: true,
  unboundedArraysIdentified: true,
  duplicateFieldSourcesOfTruthDefined: true,
  relationshipDeletionPolicyDefined: true,
  criticalWritesAndRetriesReviewed: true,
  validatorsTestedAgainstExistingData: true,
  indexesMeasuredWithExplain: true,
  migrationAndRollbackPlanReviewed: true
};

const readyForProduction =
  Object.values(schemaReview).every(Boolean);

print(readyForProduction);