DynamoDB vs Amazon S3

DynamoDB and Amazon S3 solve different problems, so the honest answer to "which one" is usually both. DynamoDB is a key-value and document database for structured records you look up, query and update by key. Amazon S3 is object storage for files and blobs — images, backups, logs, videos — that you store and retrieve whole. They are complementary, not either/or.

Should I use DynamoDB or S3?

Use DynamoDB when you have many small structured records you query, filter and update by key with single-digit-millisecond latency. Use Amazon S3 when you store and serve whole files or blobs — images, backups, exports — and retrieve them by name. They are complementary: a very common pattern stores the object in S3 and its metadata in DynamoDB.

DynamoDB vs Amazon S3 at a glance

Every cell above is drawn from official AWS documentation (see the provenance note at the top of this file).

When to use DynamoDB

Reach for DynamoDB when your data is structured records you access by key:

• Many small items (each under the 400 KB limit) that you read, write and update individually.
• Predictable, low-latency lookups — DynamoDB targets single-digit-millisecond reads and writes for single items at any scale.
• Access patterns you can express with a primary key and secondary indexes: get-by-id, query-a-partition, filter-within-a-partition.
• High write throughput with fine-grained updates (change one attribute without rewriting the whole record).

If you find yourself trying to store a 5 MB file inside an item, that is the signal you have reached DynamoDB's boundary — see DynamoDB item size limit.

When to use S3

Reach for Amazon S3 when your data is a whole file or blob you retrieve by name:

• Images, PDFs, videos, audio, and other binary assets.
• Backups, database exports, and data-lake files (Parquet, CSV, JSON) queried later with a tool like Amazon Athena.
• Large objects — S3 stores objects up to 5 TB each, far beyond any single database record.
• Static website assets and content served directly to users.

S3 is not a database: you cannot query the contents of arbitrary objects with rich indexes the way you query DynamoDB items. In-place SQL-style filtering over an object is available through Amazon Athena (S3 Select remains available to existing customers but was closed to new customers in 2024).

Using them together

The two services are most powerful combined. AWS's own guidance for data too large for a DynamoDB item is to store the object in S3 and keep a pointer in DynamoDB:

• Store the large file (image, document, video) as an object in S3.
• Store its metadata — the S3 object key, content type, owner, tags, timestamps — as an item in DynamoDB, where it is cheaply queryable.
• Look the record up in DynamoDB by key, then fetch the object from S3 using the stored identifier.

One caveat AWS calls out: there are no transactions spanning DynamoDB and S3, so your application handles partial failures (for example, cleaning up an orphaned S3 object if the DynamoDB write fails).

Working with DynamoDB

Once you have chosen DynamoDB for the structured half of your data, DynoTable is a desktop DynamoDB client for browsing, editing and querying tables across macOS, Windows and Linux. It reads your standard AWS credential chain, so there is nothing DynamoDB-specific to migrate — point it at your region and tables and your data stays in DynamoDB.

When you need to hand-build the GetItem, Query, Update or condition expressions that back the metadata-in-DynamoDB pattern above, the free DynamoDB Expression Builder generates the request in the AWS SDK, CLI and boto3 forms. To size an item against the 400 KB limit before you decide what belongs in S3, the item size calculator measures a record's byte size.

FAQ

Can DynamoDB store files or images?

Small ones, within limits. A DynamoDB item can hold binary data, but the entire item — every attribute name and value — must stay under 400 KB. For anything larger, AWS's documented best practice is to store the file as an object in Amazon S3 and keep the S3 object key (plus metadata) in a DynamoDB item.

Is S3 cheaper than DynamoDB?

They price differently, so it depends on the workload rather than a flat answer. S3 charges for storage per GB-month plus per-request and retrieval fees, and is generally the cheaper home for large volumes of infrequently accessed bytes. DynamoDB charges for read/write capacity plus storage and is built for high-throughput, low-latency access to many small records. Storing large blobs in DynamoDB is both size-limited and comparatively expensive — which is why the S3-object-plus-DynamoDB-metadata split is the standard pattern.

DynamoDB or S3 for JSON?

If the JSON is a structured record you query and update by key — a user, an order, a session — DynamoDB fits, and it maps JSON to typed attributes and supports PartiQL. If the JSON is a whole document or data-lake file you store and later scan in bulk (for example querying it with Amazon Athena), S3 fits. A frequent hybrid keeps the queryable fields in DynamoDB and the full JSON payload as an object in S3.

Related

• Learn: DynamoDB item size limit · When to use DynamoDB
• Build requests visually with the DynamoDB Expression Builder.
• Size records with the DynamoDB item size calculator.
• Download DynoTable to work with your DynamoDB tables.

Last verified 2026-07-12 against official AWS DynamoDB and Amazon S3 documentation. Amazon S3, DynamoDB and Athena are services of Amazon Web Services, referenced here for identification only.