Document NoSQL
Store self-contained JSON-ish documents per key, query on any field, no fixed schema.
What it is
Document stores keep records as semi-structured documents (JSON (JavaScript Object Notation), BSON, XML), where each document is a self-contained tree. Unlike pure KV stores, document stores support querying on arbitrary fields via secondary indexes, and the documents themselves can be deeply nested. There's no enforced schema, though most engines support optional validation. The mental model is 'a collection of JSON objects with indexes'.
Why senior interviewers ask
Document stores are the most-misused database category. Teams reach for MongoDB because 'schema-less is flexible', then a year later they're trying to do joins across collections and discover that's a mess. Knowing when documents fit (and don't) is a senior signal.
Key points
- Documents are the unit of atomicity — a single document write is ACID (Atomicity, Consistency, Isolation, Durability), multi-document is harder.
- Secondary indexes on nested fields (e.g., 'address.city') are first-class.
- Aggregation pipelines (MongoDB) provide SQL (Structured Query Language)-like analytics on a single collection.
- Cross-collection joins are bolted on (MongoDB $lookup) and slow compared to SQL.
- Schema flexibility cuts both ways — drift accumulates without write-side validation.
- Sharding requires picking a shard key; bad choices lead to scatter-gather queries.
- MongoDB now supports multi-document transactions but at a real perf cost.
Pros
- Natural fit for objects that don't decompose cleanly into tables (content, catalogs, configs).
- Schema evolution is cheap — add a field, no migration.
- Single-document operations are atomic and fast.
- Mature drivers in every language with idiomatic mappings.
- Horizontal sharding is built in.
Cons
- Cross-collection joins are painful — denormalize or accept slow $lookup.
- Lack of enforced schema accumulates technical debt as the codebase grows.
- Multi-document transactions exist but undercut the perf story.
- Aggregation pipelines are powerful but verbose compared to SQL.
- Schema drift bugs surface as runtime errors, not migration errors.
When to choose
- Each entity is a self-contained tree (a product with nested variants, a blog post with comments).
- Schema needs to evolve quickly during early product iteration.
- Access patterns are mostly 'get one document by id or query'.
- Content management, catalogs, user profiles with varied attributes.
- Mobile/web sync use cases (Firestore real-time listeners).
When to avoid
- Cross-entity transactions or joins are central to the domain (orders + inventory + ledger).
- Strong schema enforcement is required (regulatory, financial).
- Heavy analytical workloads — ship to a warehouse instead.
Real systems
Interview probe
'Why MongoDB over Postgres for this?' Answer: only if the data is naturally tree-shaped, schema will change a lot, and you don't need cross-entity joins. Otherwise Postgres with JSONB columns gives you the document model and SQL for free.