S3 vs RDS vs DynamoDB — Choosing the Right AWS Storage for Your Data

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.

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 Hotstar, 50 petabytes of video content lives in S3. Videos are retrieved as complete files for streaming, not queried by attribute. S3 stores them durably across multiple AZs, delivers them through CloudFront to edge locations worldwide, and costs $0.023/GB/month in Standard tier. 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:

When RDS is the Right Choice

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

Zerodha's trading 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 two-table transaction that must either fully succeed or fully fail. DynamoDB's transaction support exists but is limited — you pay per transaction and the programming model is more complex. 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 more than 64 TB of storage — DynamoDB or Aurora scales 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 10x cheaper and faster for this

RDS vs Aurora:

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 thousands of Lambda connections 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 PhonePe, every UPI transaction creates a state record — a temporary object with status (initiated, processing, completed, failed) that must be checked in under 10 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 under 5ms consistently, regardless of whether the table has 1,000 items or 10 billion items. No relational database can match this at scale without significant 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

DynamoDB cost:

Comparing the Three Services Directly

Combining All Three in One Architecture

The most effective architectures use all three together, each handling what it does best:

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. Storing order history in DynamoDB would make reporting queries painful.

Trade-offs and the Decision You Make

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 workloads. Switch to Provisioned once traffic is predictable — you will save 30-40%.
• Use ElastiCache in front of RDS for read-heavy workloads. An RDS query returning the same product record 10,000 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.

REMEMBER THIS

**References and Further Reading** * [AWS database selection guide](https://aws.amazon.com/products/databases/) — AWS's own comparison of all database services * [DynamoDB best practices](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html) — single-table design and access pattern design * [Amazon Aurora vs RDS](https://aws.amazon.com/rds/aurora/faqs/) — when Aurora is worth the extra cost