DynamoDB vs MongoDB: Serverless or Flexible? (2026)

Quick verdict

Short answer

Choose DynamoDB if you are committed to AWS, your access patterns are known and key-based (get a user, list a customer's orders), and you want a service with no instances, versions or patches to manage and pay-per-request pricing. Choose MongoDB (usually as Atlas) if you need ad hoc queries, aggregation, many secondary indexes, documents larger than 400 KB, or the option to run outside AWS. If you are looking at Amazon DocumentDB, note that it is a separate AWS service with MongoDB compatibility, not MongoDB itself.

How we know: This comparison is research-based: limits, capacity modes, consistency, transactions, global tables and pricing for DynamoDB were checked against the Amazon DynamoDB Developer Guide and AWS pricing pages, and MongoDB features and Atlas prices against the MongoDB documentation and pricing page, in October 2026. We have not run performance tests, so no speed claims are made.

Amazon DynamoDB is a fully managed NoSQL service from AWS. You create tables, not servers: there is no engine version to choose and no instance to size. Items are addressed by a primary key (a partition key, optionally with a sort key), can hold nested maps and lists, and are read with GetItem, Query and Scan or with PartiQL, a SQL-compatible language of which DynamoDB supports a subset. AWS states that on-demand capacity is the default and recommended throughput mode for most workloads. DynamoDB runs only on AWS; DynamoDB local is a downloadable version for development and testing.

MongoDB is a document database that stores BSON documents in collections and is queried with the MongoDB Query API, including aggregation pipelines. You can self-manage MongoDB Community Server (SSPL v1.0) or Enterprise Advanced anywhere, or use MongoDB Atlas, the vendor's managed service on AWS, Azure and Google Cloud. The current release in the MongoDB manual is 9.0.

A note on Amazon DocumentDB. AWS also sells Amazon DocumentDB (with MongoDB compatibility), which AWS describes as a managed service that lets you use the same drivers and tools you use with MongoDB. It is a separate AWS service with its own architecture, not DynamoDB and not MongoDB Atlas, so check its compatibility documentation if you consider it. This page compares DynamoDB with MongoDB.

Side by side

Aspect	DynamoDB	MongoDB
What it is	Serverless AWS service; no instances or versions to manage	Database software (self-managed) or MongoDB Atlas managed clusters
Where it runs	AWS only (DynamoDB local for development)	Anywhere self-managed; Atlas on AWS, Azure and Google Cloud
Data model	Items with a partition key and optional sort key; nested maps and lists	BSON documents in collections
Size limit	400 KB per item, including attribute names	16 MiB per document (GridFS for larger)
Querying	`Query` by key, `Scan`, PartiQL subset; no joins or server-side aggregation pipeline	Rich filters, aggregation pipelines, `$lookup` joins
Secondary indexes	Up to 20 global (default quota) and 5 local secondary indexes per table	Many index types: compound, multikey, text, geospatial, wildcard and more
Read consistency	Eventually consistent by default; strongly consistent reads on tables and LSIs, not on GSIs	Read and write concerns; default write concern `w: "majority"`
Transactions	Up to 100 items and 4 MB per transaction, within one account and Region	Multi-document ACID transactions on replica sets and sharded clusters
Multi-region	Global tables: multi-active, eventual (MREC) or strong (MRSC) consistency	Atlas multi-region and multi-cloud clusters; replica set members across regions
Pricing model	Per request (on-demand) or per provisioned capacity, plus storage	Atlas: hourly cluster tiers (Free, Flex, Dedicated); self-managed is free under SSPL
Main trade-off	No operations and fine-grained billing, but queries must be designed into keys and indexes up front	Flexible queries and portability, but you size and pay for clusters

Key differences

Serverless service versus database you deploy

DynamoDB has no servers, versions or maintenance windows exposed to you. You choose a capacity mode per table. In on-demand mode AWS describes pay-per-request pricing with no capacity planning; in provisioned mode you set reads and writes per second, pay for that capacity hourly whether or not you use it, and can add auto scaling. You can switch a table from provisioned to on-demand up to four times in a rolling 24 hours, and from on-demand to provisioned at any time.

MongoDB Atlas is managed, but you still pick a tier and cluster size (Flex or Dedicated tiers such as M10) and plan upgrades between MongoDB versions. Self-managed MongoDB gives you full control and full operational responsibility. The upside is portability: the same database runs on your laptop, in your data centre or on any of three clouds.

Data modelling: access patterns and single-table design

AWS's design guidance says you "shouldn't start designing your schema for DynamoDB until you know the questions it will need to answer" and that "you should maintain as few tables as possible". In practice this often leads to single-table design: several entity types share one table, with generic key attributes (for example PK and SK) whose values encode the entity, so that one Query returns a customer and their orders together. Global secondary indexes add alternative access paths.

# DynamoDB (AWS CLI): latest 10 orders for one customer
aws dynamodb query --table-name AppTable \
  --key-condition-expression "PK = :pk AND begins_with(SK, :sk)" \
  --expression-attribute-values '{":pk":{"S":"CUSTOMER#123"},":sk":{"S":"ORDER#"}}' \
  --no-scan-index-forward --limit 10

-- DynamoDB (PartiQL): the same key-based read
SELECT * FROM "AppTable"
WHERE PK = 'CUSTOMER#123' AND begins_with(SK, 'ORDER#');

// MongoDB (mongosh): orders collection with an index
db.orders.createIndex({ customer_id: 1, order_date: -1 })
db.orders.find({ customer_id: 123 }).sort({ order_date: -1 }).limit(10)

Queries that do not match a key or index in DynamoDB become a Scan, which reads the table page by page (each Query or Scan call returns at most 1 MB) and is charged for what it reads. In MongoDB you can usually answer a new question by adding an index or an aggregation stage, which is why it suits products whose questions change often.

Limits that shape the design

DynamoDB's documented constraints include a maximum item size of 400 KB (attribute names count towards it), partition keys up to 2,048 bytes and sort keys up to 1,024 bytes, nesting up to 32 levels, 5 local and (by default) 20 global secondary indexes per table, and a 10 GB limit per item collection on tables with local secondary indexes. Large objects are usually stored in Amazon S3 with a pointer in the item.

MongoDB documents can be up to 16 MiB with up to 100 levels of nesting, and GridFS stores larger files in chunks. That headroom matters for content, catalogue or configuration documents that grow over time.

Consistency and transactions

DynamoDB reads are eventually consistent by default and cost half as much as strongly consistent reads. Setting ConsistentRead returns the latest data on tables and local secondary indexes; reads from global secondary indexes and streams are always eventually consistent. TransactWriteItems and TransactGetItems group up to 100 actions on distinct items, up to 4 MB, across tables in one account and Region. AWS notes that each item in a transaction costs two underlying reads or writes, and that transactions are not supported across Regions in global tables.

MongoDB supports multi-document ACID transactions with commit and abort on replica sets and sharded clusters, and the default write concern is w: "majority" on most replica sets. MongoDB still recommends embedding related data so that most writes are single-document and atomic without a transaction.

Multi-region: global tables versus Atlas clusters

DynamoDB global tables replicate a table across Regions, and optionally across accounts, with every replica accepting reads and writes. You choose multi-Region eventual consistency (MREC, the default, with last-writer-wins conflict resolution) or multi-Region strong consistency (MRSC), and cannot change the mode after creation.

MongoDB replicates through replica sets, where one primary accepts writes per shard. The Atlas documentation states that clusters can place nodes in several regions and across AWS, Azure and Google Cloud in one cluster, with a chosen region priority for primary eligibility, and warns that long distances can lengthen elections and add replication lag. DynamoDB cannot span clouds because it is AWS only.

Pricing and licensing

DynamoDB. Listed on the AWS DynamoDB on-demand pricing page in October 2026 for US East (N. Virginia), Standard table class, in USD: 0.625 per million write request units, 0.125 per million read request units, and 0.25 per GB-month of storage. A write unit covers up to 1 KB and a read unit up to 4 KB (strongly consistent; an eventually consistent read costs half). Provisioned capacity is billed per capacity unit per hour. The AWS Free Tier includes 25 GB of storage and 25 provisioned WCUs and 25 RCUs per month, per Region. Backups, global table replication, streams and data transfer are charged separately, and other Regions have different rates.

MongoDB Atlas. Listed on the MongoDB pricing page in October 2026, in USD: Free tier with 512 MB of storage; Flex at 0.011 USD per hour, capped at 30 USD per month; Dedicated clusters from 0.08 USD per hour (M10). Atlas bills hourly with monthly invoices.

Comparing them. DynamoDB costs follow request volume and item size; Atlas costs follow cluster size. Spiky or low-traffic workloads often favour per-request billing, while steady heavy traffic needs a calculation for both. We have not modelled specific workloads; use the AWS Pricing Calculator and MongoDB's estimates with your own numbers.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

DynamoDB strengths

Serverless: no instances, versions, patching or capacity planning in on-demand mode
Pay-per-request pricing, plus a monthly AWS Free Tier allowance listed on the pricing page
Global tables with multi-active writes and a strong consistency option (MRSC)
Integrates with IAM, Lambda, Streams and other AWS services
DynamoDB local supports offline development and testing

MongoDB strengths

Rich query language with aggregation pipelines and joins via $lookup
Documents up to 16 MiB and many secondary index types
Runs anywhere: self-managed or Atlas on AWS, Azure and Google Cloud
Multi-document transactions without a 100-item cap
Adding a new query usually means adding an index, not redesigning keys

Limitations

DynamoDB limitations

AWS only, which ties your data layer to one provider
400 KB item size limit, including attribute names
Access patterns must be designed into keys and indexes; other queries fall back to costly scans
Reads from global secondary indexes are always eventually consistent
Transactions are capped at 100 items and 4 MB and do not span Regions

MongoDB limitations

You choose and pay for cluster sizes, even on Atlas
SSPL is not an OSI-approved licence for self-managed use
Writes for each shard go through one primary
Self-managed deployments need replica set and sharding operations skills

When to choose each

Choose DynamoDB if

Your application runs on AWS and you want no database servers to operate
Access patterns are known and mostly key-based, such as user profiles, carts or sessions
Traffic is spiky or unpredictable and you prefer pay-per-request billing
You need multi-Region active-active tables inside AWS

Choose MongoDB if

You need ad hoc queries, aggregation or reporting on operational data
Documents can exceed 400 KB or have deeply nested structures
You want the option to run on Azure, Google Cloud or on premises
Requirements change often and you would rather add indexes than redesign keys

When neither is right

Relational data with joins, foreign keys and SQL reporting: use a relational database; see MongoDB vs PostgreSQL or MongoDB vs SQL Server.
An in-memory cache or session store in front of either: see Redis vs MongoDB.
A self-managed, permissively licensed store for very high write volumes across several data centres: see Cassandra vs MongoDB.
If your team mainly wants MongoDB drivers on AWS, compare MongoDB Atlas on AWS with Amazon DocumentDB on their own documentation, since DocumentDB is a separate MongoDB-compatible service.

Final recommendation

Bottom line

If your system lives on AWS and you can describe its queries up front, DynamoDB removes database operations almost entirely and bills for what you use; the price is careful key design and the 400 KB item limit. If your queries are still evolving, you need aggregation or larger documents, or you want to avoid tying the data layer to one cloud, MongoDB, usually as Atlas, is the more flexible choice in our view. Start from your access patterns and your cloud strategy; the right answer usually follows from those two.

Frequently asked questions

Is DynamoDB the same as MongoDB?

No. DynamoDB is AWS's own serverless key-value and document service with its own API and PartiQL support. It does not use the MongoDB Query API or MongoDB drivers. MongoDB is a separate database from MongoDB, Inc., available self-managed or as Atlas.

Is Amazon DocumentDB MongoDB?

No. Amazon DocumentDB (with MongoDB compatibility) is a separate AWS service that AWS says lets you use the same application code, drivers and tools as MongoDB. It is neither MongoDB Atlas nor DynamoDB, so check its compatibility documentation for the features you rely on.

What is the maximum item size in DynamoDB?

400 KB, including attribute names and values, according to the DynamoDB constraints page. MongoDB's document limit is 16 MiB.

Does DynamoDB support SQL?

It supports a subset of PartiQL, a SQL-compatible language, for select, insert, update and delete. It does not provide joins, and queries that do not match a key or index still read the table like a scan.

Can I run MongoDB Atlas on AWS instead of using DynamoDB?

Yes. Atlas runs on AWS, Azure and Google Cloud, so you can keep MongoDB's query language and run in AWS Regions. You manage cluster tiers rather than per-request capacity.

Sources

Checked October 2026.

How we research comparisons: our editorial method.