Databases

Key points

• Engines: Db2, MariaDB, MySQL, Oracle, PostgreSQL and SQL Server. Pick PostgreSQL for advanced SQL, extensions and complex queries, MySQL or MariaDB for simple, widely supported web workloads, and Oracle or SQL Server when licenses or features require them.
• Instance classes: general purpose (db.m*), memory optimized (db.r*, db.x*, db.z1d), burstable (db.t*) and Optimized Reads classes with local NVMe. Scale up by changing the class.
• Read replicas: asynchronous copies that serve reads, up to 15 per source (Db2 up to 3). They can live in another AZ or another Region and can be promoted to a standalone instance for DR. RDS does not add or remove replicas automatically.
• Storage autoscaling: grows storage when free space is at or below 10% for at least 5 minutes, up to the maximum storage threshold you set. It never shrinks storage.
• Magnetic storage is deprecated. New instances use gp3 or Provisioned IOPS SSD.

Key points

• Storage: 6 copies of the data across 3 AZs in a cluster volume that grows automatically, up to 256 TiB on recent engine versions.
• Aurora Replicas: up to 15 per cluster, lag usually much less than 100 ms. The reader endpoint spreads connections across them and failover promotes one by priority (tier 0 is highest).
• Aurora Serverless v2: capacity in ACUs (about 2 GiB of memory each) from 0 to 256, scaling in steps as small as 0.5 ACU. At 0 ACU the instance pauses on supported versions.
• Global Database: up to 10 secondary Regions with replication typically under 1 second, RPO of 1 second and RTO under 1 minute. Up to 16 read-only instances per secondary. Write forwarding sends writes to the primary.
• I/O-Optimized: no charge for read and write I/O. Worth it when I/O is 25% or more of the Aurora bill (savings up to 40%). Standard to I/O-Optimized once every 30 days.

Key points

• On-demand: pay per request, no capacity planning, for unknown or spiky traffic. Provisioned: set RCUs and WCUs, with auto scaling, for predictable traffic at lower cost. Provisioned to on-demand up to 4 times per 24 hours, back at any time.
• RCU: 1 strongly consistent read or 2 eventually consistent reads per second of an item up to 4 KB. WCU: 1 write per second of an item up to 1 KB. Transactions cost 2x.
• Partition key: choose a high-cardinality attribute (user ID, device ID) so requests spread across partitions. A low-cardinality key creates hot partitions and throttling.
• Item size: up to 400 KB. Store large objects in S3 and keep the key in the item.
• PITR: restore to any second in a recovery period you set from 1 to 35 days.

Key points

• GSI: different partition and sort key, created at any time, eventually consistent reads only, its own capacity. Default quota of 20 per table.
• LSI: same partition key, different sort key, created only with the table, supports strongly consistent reads. Up to 5 per table and 10 GB per partition key value.
• DAX: in-memory cache in front of DynamoDB, API compatible, microsecond reads, up to 10x faster.
• Streams: ordered item changes kept for 24 hours, consumed by Lambda for event-driven processing. TTL deletes expired items within a few days, without consuming write throughput.
• Global tables: multi-active, multi-Region replicas. Default MREC replicates typically within a second. MRSC gives strong consistency across Regions, chosen at creation.

Key points

• Valkey or Redis OSS: replication, automatic failover across AZs, backup and restore, pub/sub and sorted sets (leaderboards). Global Datastore replicates across Regions.
• Memcached: multithreaded and simple, no replication and no failover. Fits a plain object cache that can be lost.
• Lazy loading (cache-aside): read the cache, on a miss read the database and fill the cache. Only requested data is cached, but data can be stale and misses cost 3 trips.
• Write-through: update the cache on every database write. Data is never stale, but every write takes 2 trips and unread data fills the cache.
• TTL: add an expiry to either strategy to bound staleness and free memory.

Key points

• Amazon DocumentDB: JSON documents with MongoDB compatibility.
• Amazon Keyspaces: serverless, Apache Cassandra compatible wide-column store.
• Amazon Neptune: graph database for highly connected data, queried with Gremlin, openCypher or SPARQL.
• Amazon Redshift: columnar data warehouse for analytics (OLAP) over large data sets, not for transactions.

Key points

• Connection pooling: many short-lived clients (Lambda functions) share a small set of database connections.
• Failover: reduces failover time by up to 66% for Aurora and RDS.
• Security: credentials stay in AWS Secrets Manager and IAM authentication can be enforced. The proxy is never publicly accessible and runs in the database VPC.
• Engines: Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, PostgreSQL, MariaDB and SQL Server.

Key points

• Homogeneous: same engine (MySQL to RDS for MySQL). DMS or the native engine tools move the data.
• Heterogeneous: different engine (Oracle to Aurora PostgreSQL). Convert schema and code with DMS Schema Conversion or the AWS Schema Conversion Tool, then move the data with DMS.
• CDC: change data capture keeps replicating ongoing changes for a near-zero downtime cutover.
• Source stays online: applications keep using the source during the migration.