Document Stores
JSON/BSON documents with secondary indexes. Schema-on-read, query-on-fields.
Level: intermediate
What is it?
A document store persists records as structured documents, commonly JSON-like objects with nested fields and arrays. It typically supports key lookups and indexes or queries on selected document fields.
Why does it matter?
Document stores can fit variable-shaped entities and aggregate-like reads without decomposing every nested object into separate tables. Schema flexibility shifts some validation and migration discipline to application design.
Mental model
Treat each document as an aggregate boundary chosen around common reads and updates. Embed data that is naturally owned and used together; reference data that changes independently or must be shared widely.
How it works
- Documents often have a unique identifier and may be indexed by selected fields or paths.
- Embedding supports locality but can duplicate facts and enlarge writes when nested values change.
- Referencing avoids some duplication but may require extra round trips or joins/lookups.
- Schema flexibility does not mean no schema; applications still need validation and backward-compatible migrations.
- Atomicity, transaction boundaries, indexing, and consistency differ across document databases.
Steps
- Model the data around the document's access patterns and update boundaries.
- Choose which fields to embed and which to reference.
- Define required fields, types, indexes, and versioning rules.
- Test common queries and updates against realistic document sizes and cardinality.
Real-world usage
- Product catalogs, content metadata, event payloads, and nested aggregate records.
- Workloads where entities have variable fields and are usually read together.
Common mistakes
- Embedding unbounded arrays that make documents too large or updates expensive.
- Assuming flexible fields remove the need for validation and migrations.
- Denormalizing shared facts without a plan to keep copies consistent.
Interview questions
When would you embed instead of reference a document's related data?
Embed when the data is bounded, owned by the parent, and usually read/updated together; reference when it is shared, unbounded, or independently managed.
Does schema flexibility eliminate schema design?
No. Applications still need validation, versioning, index design, and rules for fields that readers and writers expect.