S3 vs RDS vs DynamoDB: Choosing AWS Storage

A team at a Bengaluru e-commerce startup stored their product catalogue in RDS. 2 million products, each with different attributes — t-shirts have size and colour, phones have RAM and storage, books have ISBN and author. Every attribute was a column. Their schema had 47 columns and half of them were NULL for any given product. Queries were slow. Adding a new product type required a schema migration. They migrated to DynamoDB and query times dropped from 180ms to 8ms.

The same team stored user profile images in DynamoDB. Images are binary objects. DynamoDB items have a 400 KB limit per item. They stored base64-encoded thumbnails in DynamoDB items. It worked until they added high-resolution images. They migrated to S3 and API response times dropped from 1.2 seconds to 90ms, because S3 returns direct presigned URLs rather than binary data through the API.

The right storage choice is never about which service is "better." It is always about which service matches your data model and access pattern. I should flag upfront that the specific numbers in this article (latency figures, storage costs, illustrative company examples) are meant to be directionally correct and educational rather than precise current benchmarks — you should verify exact current pricing directly on AWS's pricing pages before budgeting, since AWS revises rates periodically.

The Three Storage Models

Each service is built around a fundamentally different model:

The mistake is trying to use one service for all three purposes.

When S3 is the Right Choice

S3 is for files and objects — anything you store as a complete unit and retrieve as a complete unit.

At a large streaming platform like Hotstar, video content at petabyte scale lives in S3. Videos are retrieved as complete files for streaming, not queried by attribute. S3 stores them durably across multiple Availability Zones and delivers them through CloudFront to edge locations worldwide. No database could store or serve video content at this cost or scale.

S3 is correct for:

• Media files — images, videos, audio, documents
• Application logs — CloudTrail logs, access logs, application output
• Data lake raw storage — CSV, JSON, Parquet files for Athena to query
• Static website assets — HTML, CSS, JavaScript
• Backup snapshots — RDS snapshots exported to S3, EBS snapshots
• Large datasets for batch processing — EMR and Glue read from S3

S3 is wrong when:

• You need to query the contents of files with WHERE clauses — use RDS or DynamoDB
• You need to update part of an object — S3 objects are replaced, not updated
• You need sub-millisecond latency on frequent small reads — use ElastiCache or DynamoDB
• You need relational integrity — S3 has no concept of foreign keys or transactions

S3 cost reality (verify current rates on AWS's pricing page before budgeting):

When RDS is the Right Choice

RDS is for structured relational data where your queries cannot be predicted at schema design time.

A trading platform's ledger has debits, credits, balances, accounts, instruments, and orders. Each trade creates entries across multiple tables atomically. A credit to one account is simultaneously a debit to another. This is a multi-table transaction that must either fully succeed or fully fail. DynamoDB's transaction support exists but is more limited and comes at extra cost per transaction. PostgreSQL on RDS handles this with native ACID transactions, familiar SQL, and the ability to run arbitrary queries against the data that the engineering team has not thought of yet.

RDS is correct for:

• Financial records requiring ACID transactions across multiple tables
• Reporting systems that run ad-hoc GROUP BY and JOIN queries
• User management systems with complex relational structures
• Any domain where the access patterns are not fully known at design time
• Applications migrating from on-premises MySQL or PostgreSQL

RDS is wrong when:

• You need very large storage scale or automatic horizontal scaling — Aurora or DynamoDB scale further
• You need automatic scaling to millions of requests per second — DynamoDB handles this
• Schema changes happen frequently — RDS schema migrations require careful planning and downtime management
• Your access pattern is always "get item by ID" — DynamoDB is typically cheaper and faster for this narrow pattern

RDS vs Aurora: Aurora is generally the better default for new production workloads on AWS — it's built for higher throughput and better multi-AZ durability than standard RDS MySQL/PostgreSQL, at a modest cost premium. Verify current instance pricing for your specific class before committing, since Aurora pricing has its own tiering separate from standard RDS.

RDS connection management: RDS has a maximum connection limit based on instance size. At scale, Lambda functions and containerised services can exhaust this limit. Use RDS Proxy — it pools connections and multiplexes many concurrent Lambda invocations through a smaller pool of real database connections.

When DynamoDB is the Right Choice

DynamoDB is for simple, fast, key-based access at any scale — from one request per day to millions per second.

At a UPI-scale payments platform, every transaction creates a state record — a temporary object with status (initiated, processing, completed, failed) that must be checked in single-digit milliseconds. Millions of transactions per day. Each state record is accessed by transaction ID only — no joins, no aggregations. DynamoDB returns any item by primary key in low single-digit milliseconds consistently, regardless of whether the table has 1,000 items or 10 billion items. No relational database matches this at scale without significant added architecture complexity.

DynamoDB is correct for:

• Session management — user sessions accessed by session token, auto-expire via TTL
• Leaderboards — sorted sets by score using Sort Key
• Shopping carts — access by user ID, frequent reads and writes
• IoT device state — access by device ID, frequent small updates
• High-volume event logging — write millions of events per second
• Real-time inventory — global multi-region active-active writes with Global Tables

DynamoDB is wrong when:

• You need SQL GROUP BY across all items — Scan operations are slow and expensive
• You need complex JOIN queries across different entity types — RDS is the right model
• Individual item size exceeds 400 KB — use S3 for the data, DynamoDB for the metadata
• Access patterns change frequently — DynamoDB schema design is access-pattern-driven, and redesigning it later is painful

DynamoDB cost: AWS cut on-demand throughput pricing roughly in half in November 2024, and current on-demand rates (verify against AWS's live pricing page, since these are the kind of numbers that go stale fast) are approximately $0.125 per million read request units and $0.625 per million write request units for Standard tables, plus roughly $0.25/GB-month for storage. A useful mental model from current cost-analysis writeups: at 100 million reads and 20 million writes per day, on-demand mode runs meaningfully higher than provisioned capacity with auto-scaling once your traffic is predictable enough to forecast — the commonly cited savings from switching is in the 60-80% range, though you should model your own traffic rather than assume that ratio applies to you. Each Global Secondary Index you add roughly doubles the write cost for that index, since every write also updates the index.

Comparing the Three Services Directly

Data Shape and Access:

Data Shape and Access, continued:

Combining All Three in One Architecture

The most effective architectures use all three together, each handling what it does best. A food-delivery platform at Swiggy's scale is a representative pattern:

None of these are interchangeable. Storing restaurant photos in RDS or DynamoDB would be architecturally wrong. Storing driver location in RDS would be too slow at that update frequency. Storing order history in DynamoDB would make reporting queries painful.

Trade-offs and the Decision You Make

Requirement Fit — S3 and RDS:

Requirement Fit — DynamoDB:

Production Implementation Guidelines

Follow these rules before finalising your storage choice:

• Identify every access pattern before choosing a database. If you cannot enumerate your access patterns, RDS is the safer default — it allows ad-hoc queries. DynamoDB requires knowing access patterns upfront.
• Store binary objects — images, videos, documents — in S3 and reference them by URL. Never store binary data in a relational database or DynamoDB if the objects exceed a few KB.
• Start with DynamoDB On-Demand for new, unpredictable workloads. Switch to Provisioned with auto-scaling once traffic is predictable — the savings are usually substantial, but model your own traffic before assuming a specific percentage.
• Use ElastiCache in front of RDS for read-heavy workloads. An RDS query returning the same product record thousands of times per minute is wasteful. Cache it in Redis for sub-millisecond retrieval.
• Never run analytics directly on production RDS. Use Read Replicas for reporting, or export data to Redshift for complex BI queries.
• Audit your Global Secondary Indexes on DynamoDB tables periodically — each one adds ongoing write cost, and it's easy to accumulate indexes that are no longer used by any live access pattern.

Note

References and Further Reading

• AWS database selection guide — AWS's own comparison of all database services
• DynamoDB best practices — single-table design and access pattern design
• Amazon DynamoDB Pricing — current on-demand and provisioned rates, since pricing changes over time