Nested documents that keep changing

Product catalogues, user profiles, content and event payloads rarely fit one fixed table. A document database stores each record as a nested document, and documents in the same collection need not share fields or even field types. Data that is read together is embedded in one document, so a page can load with one read instead of several joins. New fields need no migration: old and new shapes live side by side, and the application handles both.

Flexibility shifts work rather than removing it. Without a schema, a typo becomes a new field, so look for optional validation rules that can be applied to only the parts that need them. Look for secondary indexes on nested fields and on array elements, atomic updates of a single field deep inside a document, and limits on document size. Relational databases cover part of this too: PostgreSQL’s jsonb type stores parsed JSON in a column and can index it with GIN for containment queries, which is often enough when only some fields vary.