Cargando...
Cargando...
Choose the right AWS NoSQL database — serverless key-value, MongoDB-compatible documents, or Cassandra-compatible wide-column
Three NoSQL databases, three data models, three migration paths — pick the one that fits your workload
| Feature | DynamoDB Serverless key-value at any scale | DocumentDB Managed MongoDB-compatible document store | Keyspaces Serverless Cassandra-compatible wide-column |
|---|---|---|---|
Data Model DynamoDB item size limit of 400 KB is a critical exam fact. DocumentDB's 16 MB document limit mirrors MongoDB. Keyspaces row size limit is 1 MB. | Key-value & document (JSON items up to 400 KB) | Document (BSON/JSON, MongoDB-compatible, documents up to 16 MB) | Wide-column (CQL-compatible tables, rows up to 1 MB) |
Primary Use Case If a question mentions 'migrating from MongoDB', answer is DocumentDB. 'Migrating from Cassandra' = Keyspaces. 'Serverless + millisecond latency at any scale' = DynamoDB. | High-throughput OLTP: gaming leaderboards, shopping carts, session management, IoT telemetry | Content management, catalogs, user profiles — teams migrating from MongoDB | Time-series, IoT, fleet tracking — teams migrating from Apache Cassandra |
Serverless / Managed Model Critical trap: DocumentDB is NOT serverless in the traditional sense — it requires cluster instances. DynamoDB and Keyspaces are both serverless. | Fully serverless — no servers, clusters, or instances to manage. On-demand or provisioned capacity modes. | Cluster-based (NOT serverless by default). Requires instance selection (e.g., db.r6g.large). DocumentDB Elastic Clusters offer elastic scaling. | Fully serverless — no servers or clusters. On-demand or provisioned capacity modes. |
Query Language / API Compatibility is the key differentiator. Existing MongoDB app code = DocumentDB. Existing Cassandra app code = Keyspaces. Greenfield high-scale = DynamoDB. | DynamoDB API (GetItem, PutItem, Query, Scan) + PartiQL (SQL-compatible). No full SQL joins. | MongoDB Query Language (MQL) — find(), aggregate(), $match, $group. Compatible with MongoDB 3.6, 4.0, 5.0 drivers. | Cassandra Query Language (CQL) — SELECT, INSERT, UPDATE, DELETE. Compatible with Cassandra 3.11+ drivers. |
Consistency Models DynamoDB strongly consistent reads consume 2x RCUs vs eventually consistent. DynamoDB Transactions cost 2x RCUs/WCUs. Keyspaces lacks full ACID transactions — important differentiator. | Eventually consistent reads (default) OR strongly consistent reads (per-request flag). Transactions via TransactWriteItems (ACID, up to 100 items or 4 MB per transaction). | Read preference: primary (strong), primaryPreferred, secondary, secondaryPreferred, nearest. Supports multi-document ACID transactions. | Eventually consistent (default). Supports LOCAL_QUORUM for stronger consistency. No multi-row ACID transactions (Cassandra model). |
Scaling Model DynamoDB is the clear winner for extreme scale (trillions of API calls, Amazon Prime Day). DocumentDB scales reads via replicas but writes are limited to primary instance. | Horizontal, automatic, infinite scale. Tables of virtually any size. Hundreds of customers with tables >200 TB. Over 500K requests/second peak. | Vertical (instance size) + horizontal read replicas (up to 15 read replicas per cluster). Storage auto-scales up to 128 TiB. | Horizontal, automatic, serverless. Scales to handle thousands of requests per second. Storage scales automatically. |
Global Distribution DynamoDB Global Tables = multi-active (any region can write). DocumentDB Global Clusters = active-passive (only primary region writes). Critical distinction for disaster recovery questions. | DynamoDB Global Tables — multi-region, multi-active (active-active) replication. Last-writer-wins conflict resolution. | No native global tables. Cross-region replication available via Global Clusters (active-passive). Requires manual setup. | Multi-region replication available. Single-region by default; multi-region keyspaces can be configured. |
Indexes LSI vs GSI is a top DynamoDB exam topic. LSI shares partition key and RCU/WCU with base table. GSI has its own provisioned throughput and eventual consistency only. | Local Secondary Indexes (LSI — same partition key, must be created at table creation) and Global Secondary Indexes (GSI — different partition key, can be added/removed anytime). Max 5 LSIs, 20 GSIs per table. | Rich MongoDB-style indexes: single field, compound, multi-key, text, geospatial, sparse, partial, TTL indexes. | Primary key (partition key + optional clustering columns). Secondary indexes supported. No joins. |
Item / Document / Row Size Limit 400 KB DynamoDB item limit is one of the most frequently tested limits. If you need larger objects, store in S3 and reference in DynamoDB. | 400 KB per item (including attribute names and values) | 16 MB per document (MongoDB-compatible limit) | 1 MB per row |
Throughput / Capacity RCU/WCU math is heavily tested for DynamoDB. Strongly consistent read = 1 RCU per 4 KB. Eventually consistent = 0.5 RCU per 4 KB. Transactional = 2 RCUs per 4 KB. | On-demand (pay-per-request) or Provisioned (RCU/WCU). Account-level and table-level quotas apply. One RCU = 1 strongly consistent read of up to 4 KB/s or 2 eventually consistent reads of up to 4 KB/s. One WCU = 1 write of up to 1 KB/s. | Instance-based throughput — determined by instance type (r6g, r5, t3, etc.). No RCU/WCU concept. | On-demand or Provisioned. Similar RCU/WCU model to DynamoDB but specific to Keyspaces. Read capacity unit = 4 KB read. Write capacity unit = 1 KB write. |
Backup & Point-in-Time Recovery (PITR) Both DynamoDB and Keyspaces PITR = 35 days. DynamoDB PITR must be explicitly enabled — it is NOT on by default. | On-demand backups (full, no performance impact) + PITR (continuous backups, restore to any second within last 35 days). Export to S3 supported. | Automated backups (1–35 day retention) + manual snapshots. PITR available. Backups stored in S3 (managed by AWS). | PITR supported (restore to any second within last 35 days). On-demand backups supported. |
Streams / Change Data Capture DynamoDB Streams + Lambda is the canonical serverless event-driven architecture. Change stream retention for DynamoDB Streams is 24 hours — commonly tested. | DynamoDB Streams — ordered log of item-level changes (24-hour retention). Integrates natively with Lambda for event-driven patterns. Kinesis Data Streams integration also available. | Change streams (MongoDB-compatible) — real-time change events. Integrates with Lambda and Kinesis. | No native change streams. CDC can be achieved via application-level patterns. |
TTL (Time-to-Live) DynamoDB TTL deletions are free (no WCU consumed). TTL is eventually consistent — items may persist for up to 48 hours after expiry. Common exam trap. | Native TTL — mark items with a Unix epoch timestamp attribute; DynamoDB automatically deletes expired items (no WCU cost for deletion). TTL deletions appear in Streams. | TTL indexes supported (MongoDB-compatible). Documents automatically expire. | Native TTL support at table or row level. Default TTL can be set at table creation. |
Encryption DocumentDB encryption must be configured at cluster creation — you cannot enable/disable it on existing clusters. | Encryption at rest with AWS owned key (default, free), AWS managed key (KMS), or customer managed key (CMK). Encryption in transit via TLS. | Encryption at rest with KMS (enabled at cluster creation, cannot be changed). Encryption in transit via TLS. | Encryption at rest with AWS owned key (default) or customer managed key (KMS). Encryption in transit via TLS. |
VPC / Network Access DocumentDB is VPC-only — this is a critical architectural constraint. DynamoDB Gateway VPC Endpoint is free and commonly recommended for security. Keyspaces uses Interface VPC Endpoints (costs apply). | Public endpoint by default. VPC Endpoints (Gateway type, free) available for private access. No VPC required. | VPC-only — cluster must reside in a VPC. Not accessible from public internet without bastion/VPN. | Public endpoint (cassandra.region.amazonaws.com). VPC Endpoints (Interface type) available for private access. |
Pricing Model DynamoDB has the most favorable permanent free tier. DocumentDB is the most expensive at low scale due to instance-based pricing (minimum ~$0.10/hour per instance). For cost optimization at low scale, DynamoDB on-demand wins. | Pay for: read/write capacity (on-demand per million requests, or provisioned RCU/WCU/hour) + storage (per GB/month) + optional: PITR, backups, Global Tables, DAX, Streams. Free tier: 25 GB storage, 25 WCU, 25 RCU/month permanently. | Pay for: instance hours (per instance type/hour) + I/O (per million requests) + storage (per GB/month) + backup storage. No permanent free tier (only 30-day trial). Higher baseline cost due to instance model. | Pay for: read/write capacity (on-demand per million requests, or provisioned RCU/WCU/hour) + storage (per GB/month) + PITR. Free tier: 30 million on-demand writes, 30 million on-demand reads, 1 GB storage/month for 3 months. |
DAX (Caching Layer) DAX is DynamoDB-only. It is API-compatible (same SDK calls). DAX does NOT support strongly consistent reads — they bypass DAX and go directly to DynamoDB. | DAX (DynamoDB Accelerator) — in-memory cache, microsecond latency, fully managed, API-compatible. Reduces read load. Write-through cache. | No native equivalent. Use ElastiCache (Redis/Memcached) separately. | No native equivalent. Use ElastiCache separately. |
Transactions (ACID) DynamoDB transaction limit: 100 items OR 4 MB per transaction (whichever is smaller). Cost is 2x normal RCU/WCU. | TransactWriteItems / TransactGetItems — up to 100 items or 4 MB per transaction across multiple tables. 2x RCU/WCU cost. | Full multi-document ACID transactions (MongoDB 4.0+ compatible). No extra cost per transaction. | Lightweight transactions (LWT) via CQL IF conditions — limited compare-and-swap semantics. Not full ACID multi-row transactions. |
Secondary Index Limits LSI must be created when the table is created — cannot be added later. GSI can be added/removed at any time. This is a common DynamoDB exam trap. | Max 5 LSIs per table (created at table creation only). Max 20 GSIs per table (can be added/deleted anytime). GSI has its own throughput. | Up to 64 indexes per collection (MongoDB limit). Rich index types supported. | Secondary indexes supported. Fewer index types than DocumentDB. |
Multi-AZ / High Availability DynamoDB and Keyspaces are inherently multi-AZ with no configuration. DocumentDB requires adding replica instances to achieve multi-AZ HA. | Built-in — data automatically replicated across 3 AZs within a region. No configuration required. | Multi-AZ via replica instances. Primary + up to 15 read replicas across AZs. Automatic failover in ~30 seconds. | Built-in — data automatically replicated across 3 AZs within a region. No configuration required. |
Migration Path From DocumentDB is NOT 100% MongoDB compatible. Some MongoDB features (e.g., certain aggregation operators, transactions in older versions) may not be supported. Always check compatibility. | Greenfield NoSQL apps. Migration from DynamoDB Local (dev). AWS Database Migration Service (DMS) can migrate data into DynamoDB. | MongoDB (self-managed or Atlas). Use mongodump/mongorestore or AWS DMS for migration. Not 100% MongoDB compatible — check compatibility matrix. | Apache Cassandra (self-managed). Use cqlsh COPY or AWS DMS for migration. Compatible with Cassandra 3.11+ drivers. |
Supported AWS Regions Keyspaces offers FIPS endpoints in us-east-1 and us-west-2 — relevant for government/compliance workloads. | Available in all commercial AWS Regions, GovCloud, and China regions. | Available in most commercial AWS Regions. Check regional availability for newer regions. | Available in multiple regions including us-east-1, us-east-2, us-west-1, us-west-2, eu-west-1, ap-southeast-1, ap-northeast-1, and more. FIPS endpoints available in us-east-1 and us-west-2. |
Compliance & Security Certifications All three are HIPAA eligible. For FedRAMP High, DynamoDB and Keyspaces are strong choices. Use IAM for all three rather than database-native credentials where possible. | HIPAA eligible, PCI DSS, SOC 1/2/3, ISO, FedRAMP (High). Fine-grained access control via IAM + condition keys. | HIPAA eligible, PCI DSS, SOC 1/2/3, ISO. IAM authentication supported. | HIPAA eligible, PCI DSS, SOC 1/2/3, ISO, FedRAMP. IAM authentication + Cassandra native authentication. |
Table / Keyspace / Collection Limits DynamoDB default 2,500 tables per region is a soft limit. For multi-tenant SaaS with one table per tenant, consider single-table design instead. | Default: 2,500 tables per region (soft limit, can be increased). No limit on items per table. | No documented hard limit on collections per cluster. Practical limits based on instance size. | Default quotas apply (e.g., tables per keyspace). Soft limits can be increased via Service Quotas. |
Summary
DynamoDB is the go-to choice for serverless, high-throughput, low-latency applications at any scale — it requires no server management and offers the richest AWS-native integration. DocumentDB is purpose-built for teams migrating MongoDB workloads who need rich query capabilities, complex indexes, and full ACID transactions without re-writing application code. Keyspaces is the ideal migration path for Apache Cassandra workloads, offering serverless operations with CQL compatibility and automatic multi-AZ replication.
🎯 Decision Tree
If 'migrating from MongoDB' OR 'need MongoDB compatibility' → DocumentDB. If 'migrating from Cassandra' OR 'need CQL' → Keyspaces. If 'serverless' AND 'millisecond latency' AND 'any scale' AND 'key-value or simple document' → DynamoDB. If 'global multi-active writes across regions' → DynamoDB Global Tables. If 'need DAX microsecond caching' → DynamoDB only. If 'item/document larger than 400 KB but under 16 MB' → DocumentDB. If 'time-series + wide-column + Cassandra drivers' → Keyspaces. If 'full ACID multi-document transactions without extra cost' → DocumentDB over DynamoDB.
DynamoDB item size limit is 400 KB — if a question describes storing objects larger than 400 KB (e.g., images, large JSON), the correct pattern is to store the object in S3 and store only the S3 reference/key in DynamoDB. This is one of the most frequently tested DynamoDB limits across all certification levels.
LSI vs GSI distinction is critical: LSIs must be created at table creation time (cannot be added later), share the table's partition key, and share the table's provisioned throughput. GSIs can be added or deleted at any time, can have a completely different partition key, and have their own separate provisioned throughput. GSI reads are ALWAYS eventually consistent — you cannot request strongly consistent reads from a GSI.
DocumentDB is NOT serverless — it requires you to choose and manage cluster instances (e.g., db.r6g.large). DynamoDB and Keyspaces are both fully serverless. If a scenario asks for 'serverless NoSQL' or 'no infrastructure management', eliminate DocumentDB unless the question specifically mentions MongoDB compatibility. DocumentDB Elastic Clusters add some elasticity but it is still not the same as DynamoDB's serverless model.
DynamoDB Transactions (TransactWriteItems/TransactGetItems) cost exactly 2x the normal RCU/WCU. The limit is 100 items OR 4 MB per transaction. For scenarios requiring ACID across many items or large documents, DocumentDB's multi-document transactions may be more cost-effective and have no item count limit per transaction.
DAX (DynamoDB Accelerator) is DynamoDB-exclusive and provides microsecond read latency. However, DAX does NOT support strongly consistent reads — strongly consistent read requests bypass DAX and go directly to DynamoDB. If a question asks about microsecond caching for DynamoDB, the answer is DAX. If it asks about caching for DocumentDB or Keyspaces, the answer is ElastiCache.
DynamoDB TTL deletions are free (no WCU consumed) and eventually consistent — expired items may persist for up to 48 hours after the TTL timestamp. TTL deletions DO appear in DynamoDB Streams, which allows downstream processing of expired items. Never rely on TTL for security-critical immediate deletion.
DynamoDB Global Tables provide multi-active (active-active) replication — any region can accept writes simultaneously with last-writer-wins conflict resolution. DocumentDB Global Clusters are active-passive — only the primary region accepts writes. This distinction is critical for multi-region write scenarios and disaster recovery RTO/RPO questions.
The DynamoDB free tier is PERMANENT (not time-limited): 25 GB storage, 25 WCUs, and 25 RCUs per month forever. DocumentDB has no permanent free tier (only a 30-day trial). Keyspaces has a 3-month free tier. For cost optimization questions at low scale or for small applications, DynamoDB is almost always the most cost-effective choice.
The #1 exam trap: Candidates assume DocumentDB is serverless because it is a managed AWS service. DocumentDB requires instance selection and cluster management — it is 'managed' but NOT 'serverless'. A question describing a need for 'serverless NoSQL database with no infrastructure management' should lead to DynamoDB (or Keyspaces for Cassandra workloads), NOT DocumentDB. Additionally, candidates confuse DynamoDB's 400 KB item limit with DocumentDB's 16 MB document limit — always remember 400 KB = DynamoDB, 16 MB = DocumentDB.
CertAI Tutor · DVA-C02, CLF-C02, DEA-C01, DOP-C02, SAA-C03, SAP-C02, SCS-C02 · 2026-02-22
Services
Comparisons