Amazon DocumentDB

A document model with a managed cluster architecture

Amazon DocumentDB (with MongoDB compatibility) is a purpose-built AWS document database for workloads that represent records as flexible, nested documents. Applications use MongoDB-compatible drivers and APIs supported by the selected DocumentDB engine version. This is valuable when domain objects map naturally to documents and the workload does not need relational joins to reconstruct each object from normalized tables.

An instance-based DocumentDB cluster separates database instances from a shared cluster volume. The cluster has a primary instance for writes and can include replica instances for read scaling and availability. The cluster volume is replicated across Availability Zones. Applications should use the appropriate cluster or reader endpoints rather than treating every instance as an independent copy of the database.

Indexes shape query cost and behavior

Indexes let DocumentDB locate matching documents without scanning every document in a collection. The correct index follows the fields and sort patterns used by important queries. The explain capability can be used to inspect query plans, while supported index hints can direct selection of an index in specific cases. Indexes also have a write and storage cost because changes to indexed documents must maintain the relevant index entries.

DocumentDB supports TTL indexes for age-based document expiration. TTL deletion is a background, best-effort process rather than an exact scheduler: an expired document is not guaranteed to disappear at the precise instant its TTL threshold is reached. Workloads that require an exact legal or business deletion timestamp should not equate TTL expiration with a hard real-time deletion guarantee.

• Use indexes for fields and query shapes that justify the additional write/storage maintenance.
• Use explain information to understand whether a query is using an intended access path.
• TTL indexes implement age-based cleanup, but deletion timing is best effort.
• MongoDB-compatible API behavior should be validated against DocumentDB's documented functional differences.

Scale reads and plan failover around instance roles

Replica instances can serve read traffic and can be placed across Availability Zones to improve availability. When the primary fails, DocumentDB can promote an eligible replica. Read scaling and availability are therefore related but not identical goals: a replica fleet used heavily for reads still needs enough capacity and placement to take over the writer role when the architecture expects it to serve as a failover target.

CloudWatch metrics expose cluster and instance behavior such as resource utilization and transaction or TTL-related signals. Because document workloads often evolve, production monitoring should be paired with query-plan review and working-set awareness. Scaling instance size without fixing an unindexed high-frequency query may simply postpone the same bottleneck.