2.4. Developer Interactions with Databases & Storage
š” First Principle: Choose your data store based on access patterns, not familiarity ā the wrong choice creates performance bottlenecks that no amount of optimization can fix.
Why does the DVA-C02 test database interactions from a developer perspective? Because developers make the daily decisions that determine whether an application is fast or slow: which queries to index, whether to use caching, how to handle connection pooling. For instance, a developer who puts a relational database behind a Lambda function with 1,000 concurrent executions will exhaust the database connection pool in seconds. Without understanding RDS connection limits or S3 consistency models, you build applications that work in testing but fail at scale.
Think of choosing a data store like choosing a vehicle ā unlike choosing a programming language, this decision is hard to reverse: a sports car (DynamoDB) is fast for straight-line speed but can't carry cargo, a pickup truck (RDS) handles heavy loads with flexibility, and a container ship (S3) stores massive volumes cheaply but isn't built for quick lookups.
| When You Need... | Use This | Why |
|---|---|---|
| Relational joins, ACID transactions | Amazon RDS/Aurora | SQL support, referential integrity |
| Key-value lookups, single-digit ms | DynamoDB | Covered in 2.1.4 |
| Object storage (files, images, backups) | Amazon S3 | Virtually unlimited, 11 9s durability |
| Caching for read-heavy workloads | ElastiCache | Microsecond reads, reduces DB load |
