Database field guide · 33
DocumentDB Internals
BSON emulation, query planning, and index execution
Understand DocumentDB implementations through their compatibility boundary, BSON representation, multikey rules, query planner, and PostgreSQL extension architecture.
Franck Pachot7 chaptersDocumentDB · BSON · query planning · indexing
Build the mental model before choosing the mechanism.
This minibook was AI-generated from Franck Pachot's archived blog posts. Links to the original articles are included for source context and verification.
01
Compatibility is an observable contract
DocumentDB names cover systems with different storage engines and execution layers. Wire compatibility and accepted syntax do not guarantee identical null, array, transaction, index, or planner behavior.
- Identify the exact product and release.
- Test application-visible semantics, not branding.
- Retain explain output with every compatibility claim.
02
A PostgreSQL extension adds translation layers
A document API implemented over PostgreSQL parses document commands, represents BSON, translates operators, and maps them to PostgreSQL access methods. Each boundary can affect semantics and cost.
- Separate protocol, query translation, and storage behavior.
- Inspect generated plans when the product exposes them.
- Do not assume native MongoDB internals beneath a compatible API.
03
Flexible paths still need physical order
Document fields can be indexed through generalized access methods such as RUM, but equality, sort, and range work best when the physical key order matches the query shape.
- Design from equality-sort-range requirements.
- Distinguish path discovery from ordered retrieval.
- Measure rechecks and rows removed after index access.
04
Arrays create multikey semantics
An array can produce several index keys for one document. This changes uniqueness, compound-key combinations, covering eligibility, and whether predicates refer to the same array element.
- Test compound predicates on arrays explicitly.
- Use same-element semantics where required.
- Include fan-out in write and storage estimates.
05
Aggregation can exploit ordered indexes
A covering or distinct scan can answer selected grouping shapes from ordered index entries without reading every document. Eligibility depends on group key, accumulator, ordering, and projection.
- Compare keys examined with documents examined.
- Verify the hinted and unhinted planner choices.
- Treat a specialized fast path as shape-specific.
06
Planner versions change evidence
A new query planner may alter index choice, pushdown, and explain vocabulary. Performance conclusions must therefore retain engine version, statistics state, query shape, and returned cardinality.
- Capture before-and-after explain evidence.
- Test selective and nonselective values.
- Keep semantic tests separate from performance tests.
07
Field manual
Concrete mechanics, diagnostic evidence, and executable patterns to carry into a real system.
01
Record the implementation boundary
Capture server identity, compatibility version, query, index definitions, and explain output before attributing behavior to DocumentDB.
db.runCommand({ buildInfo: 1 })
db.collection.getIndexes()
db.collection.find(query).explain('executionStats')
02
Measure multikey fan-out
Array elements can create multiple keys per document. Compare keys examined, documents examined, and returned rows for the exact compound predicate.
db.orders.find({lines: {$elemMatch: {sku: 'A', qty: {$gte: 2}}}})
.explain('executionStats')
03
Test an equality-sort-range path
Place equality, sort, then range requirements into a deliberate ordered index and verify whether the implementation can preserve order without an extra sort.
db.events.createIndex({tenantId: 1, createdAt: -1, score: 1})
db.events.find({tenantId: 7, score: {$gte: 10}})
.sort({createdAt: -1}).limit(20).explain('executionStats')
04
Verify aggregation fast paths
A distinct or covering group optimization is shape-specific. Compare examined keys and documents with and without the candidate index.
db.sales.aggregate([
{$sort: {category: 1, createdAt: -1}},
{$group: {_id: '$category', latest: {$first: '$createdAt'}}}
], {explain: true})
08
Source articles
Optional deep dives with the complete experiments and product-version context behind this guide.