What's changed: In-scope coverage: added purpose-built stores/storage (DocumentDB/Keyspaces/MemoryDB/S3 Tables/EFS/CloudFront/Backup)
2.3Choosing Purpose-Built Data Stores
Understand choosing purpose-built stores by access pattern (DynamoDB = NoSQL, RDS/Aurora = relational OLTP, Redshift = OLAP), plus catalogs and schema evolution.
AWS favors choosing a purpose-built store best for the access pattern rather than one database for everything. Learn the key examples.
2.3.1Picking purpose-built stores
- DynamoDB: key-value NoSQL for high-throughput, low-latency apps.
- RDS/Aurora: relational (SQL) for transactions and joins (OLTP).
- Redshift: columnar DWH for large aggregations/analytics (OLAP).
- Schema evolution: handle changes like added columns using Parquet + a catalog.
AWS favors picking a purpose-built store best for the access pattern, not "one DB for everything." DynamoDB is key-value/document NoSQL for single-digit-ms, high-throughput, virtually unlimited-scale apps; design starts from keys (partition + sort) and access patterns, with GSIs to broaden queries, DynamoDB Streams for real-time integration, and DAX for ultra-low-latency caching. RDS/Aurora is relational (SQL) for OLTP needing transactions, joins, and consistency. Redshift is a columnar DWH for large aggregation/analytics (OLAP). Others by use case: time-series = Timestream, graph = Neptune, in-memory = ElastiCache/MemoryDB, full-text/log analytics = OpenSearch. Data shape (structured/semi-structured) and schema evolution (added columns) are absorbed on the lake side with Parquet + a catalog and table formats (Iceberg). The axes: "fast app keyed lookups = DynamoDB," "joins/consistency = RDS/Aurora," "aggregation analytics = Redshift."
| Access pattern | Best store |
|---|---|
| High-throughput keyed lookups | DynamoDB |
| Transactions/joins (OLTP) | RDS / Aurora |
| Large aggregation/analytics (OLAP) | Redshift |
| Full-text/log analytics | OpenSearch |
Scenario: design an order app backend plus an analytics platform. Order reads/writes go to DynamoDB (fast keyed access, scalable; changes flow downstream via Streams). Billing/inventory needing consistency uses RDS/Aurora (OLTP). Daily revenue aggregation/BI consolidates in Redshift (OLAP). Log full-text search uses OpenSearch. Split by use case rather than forcing one store.
Q. Fast keyed app? DynamoDB. Q. Transactions/joins? RDS/Aurora. Q. Large analytics? Redshift. Q. Full-text/log analytics? OpenSearch. Q. Query by another key in DynamoDB? GSI. Q. Stream changes downstream? DynamoDB Streams.
Watch the mix-ups: (1) DynamoDB is poor at joins/analytics—route analytics to Redshift/Athena. (2) Redshift is poor at OLTP (many small writes). (3) DynamoDB requires up-front access-pattern design (ad-hoc queries are limited even with GSIs). (4) "Everything relational" is an anti-pattern—choose purpose-built.
2.3.2In-scope purpose-built stores and storage services
Purpose-built stores include options beyond relational/key-value. Amazon DocumentDB is a MongoDB-compatible document DB for nested JSON apps. Amazon Keyspaces is an Apache Cassandra-compatible wide-column store for large-scale, high-throughput writes. Amazon MemoryDB for Redis is a Redis-compatible in-memory DB, but whereas ElastiCache is a cache tier, MemoryDB persists every write to a Multi-AZ transaction log, giving it the durability to serve as a primary DB. For analytics table storage, Amazon S3 Tables stores Apache Iceberg tables in a managed way, optimized via auto-compaction and efficiently queryable from Athena/EMR/Spark. For shared files, Amazon EFS is POSIX-compliant, auto-scaling storage mountable concurrently from many instances; for delivery, Amazon CloudFront (CDN) edge-caches data/content. For data protection, AWS Backup centralizes backups of S3/EBS/EFS/RDS/DynamoDB and more, with cross-region/cross-account copy and Vault Lock (WORM) against accidental deletion and ransomware.
| Use | Service | Key point |
|---|---|---|
| Document DB | Amazon DocumentDB | MongoDB-compatible |
| Wide-column | Amazon Keyspaces | Cassandra-compatible, high throughput |
| Durable in-memory | Amazon MemoryDB for Redis | Redis-compatible, can be primary |
| Analytics tables | Amazon S3 Tables | Managed Iceberg |
| Shared files / delivery / protection | EFS / CloudFront / AWS Backup | Concurrent mount / CDN / centralized backup |
2.3.3Section summary
- Choose DynamoDB (NoSQL) / RDS·Aurora (OLTP) / Redshift (OLAP)
- Pick the optimal store by access pattern
- Purpose-built = DocumentDB/Keyspaces/MemoryDB; analytics tables = S3 Tables; shared/delivery/protection = EFS/CloudFront/Backup
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which best fits a key-value workload needing high throughput and single-digit-ms latency?
Q2. Which best fits relational transactional (OLTP) workloads with joins?
Q3. Which data store best fits fast large-scale aggregation/analytics (OLAP)?