Databases
AWS sells a different database for each shape of data rather than one database for everything. The practical consequence is that the first decision on a project is not “how do I tune this database” but “which database is this workload actually for” — and that decision is hard to reverse once an application has been written against it.
This section covers the services in that catalogue, the concepts that cut across them, and the trade-offs that decide between them.
Where to start
Section titled “Where to start”- Relational databases (RDS and Aurora) — managed MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2, plus Aurora, AWS’s own MySQL- and PostgreSQL-compatible engine with decoupled storage.
- DynamoDB — the managed key-value and document store: capacity modes, partition key design, indexes and the quotas that shape a table design.
- ElastiCache — managed in-memory caching on Valkey, Memcached or Redis OSS.
- Redshift — the columnar data warehouse for analytical queries over large historical datasets.
- Specialised databases — graph (Neptune), document (DocumentDB), wide-column (Keyspaces) and time-series (Timestream), plus the services in this family that AWS has since retired.
Two concept pages sit underneath all of these: OLTP vs OLAP, which is the distinction that separates RDS from Redshift, and data store types and concepts, which covers persistence classes, IOPS versus throughput, and the ACID and BASE consistency models. Capturing data modification events covers how to react to individual record changes, which RDS and DynamoDB handle very differently.
Choosing a service
Section titled “Choosing a service”| Service | Choose it when |
|---|---|
| Database on EC2 | You need total control of the database, or the engine you want is not offered by RDS |
| Amazon RDS | You need a conventional relational database for transactional work and your data is well structured |
| Amazon Aurora | You need a relational database with faster failover, storage that scales itself, and up to 15 low-lag read replicas |
| Amazon DynamoDB | Your access patterns are known, your data is key-value or document shaped, and you need single-digit millisecond latency at any scale |
| Amazon Redshift | You are running analytical queries over large volumes of historical data |
| Amazon Neptune | Relationships between records are themselves the thing you query |
| Amazon ElastiCache | You need very fast, volatile storage for a small working set — caching, sessions, leaderboards |
The table is a starting point, not a decision procedure. In practice the deciding factors are usually the query patterns the application needs, whether the schema is known in advance, and whether the workload is transactional or analytical — which is what the OLTP vs OLAP page is about.