High-performing databases

Choose the database type that fits the data and the access pattern, scale reads with replicas and caches, size capacity for the workload, and manage connections so bursts don't overwhelm the engine.

Database types

• Relational (Amazon RDS, Amazon Aurora): SQL, joins, and transactions. RDS runs MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2; Aurora is AWS's MySQL- and PostgreSQL-compatible engine with distributed storage.
• Key-value and document (Amazon DynamoDB): Serverless NoSQL with single-digit millisecond performance at any scale. Design around the access patterns and the partition key.
• In-memory (Amazon ElastiCache): Valkey, Redis OSS, or Memcached for microsecond reads: caches, sessions, leaderboards.
• Other purpose-built databases: Amazon DocumentDB (MongoDB-compatible), Amazon Neptune (graph), Amazon Keyspaces (Cassandra-compatible), and Amazon Redshift (columnar data warehouse for analytics).
• Serverless options: Aurora Serverless v2 and DynamoDB on-demand adjust capacity automatically for variable workloads.

Replication and read scaling

• RDS read replicas: Asynchronous copies in the same or another Region that serve read traffic and can be promoted to standalone databases.
• Aurora Replicas: Up to 15 replicas share the cluster's storage, so replica lag is usually low. The reader endpoint balances connections across them.
• Aurora Global Database: Replicates to other Regions for low-latency local reads and disaster recovery.
• DynamoDB global tables: Multi-Region, multi-active tables: every Region can read and write.
• Read-heavy workload: add replicas or a cache. Write-heavy workload: scale the writer up, shard, or move the hot data to DynamoDB.

Capacity planning

• RDS and Aurora: Pick the instance class for CPU and memory; for RDS storage, choose gp3 or Provisioned IOPS (io2) for steady high I/O, and turn on storage autoscaling.
• DynamoDB capacity modes: On-demand charges per request and handles unpredictable traffic. Provisioned sets read and write capacity units, with auto scaling, for steady traffic.
• Capacity units: One read capacity unit = one strongly consistent read per second of up to 4 KB (two if eventually consistent). One write capacity unit = one write per second of up to 1 KB.
• Partition keys: Choose a high-cardinality key so traffic spreads across partitions. A key everyone reads at once makes a hot partition.

Caching

• Lazy loading (cache-aside): Read from the cache; on a miss, read the database and fill the cache. Only requested data is cached, but the first read is slow and data can be stale.
• Write-through: Write to the cache whenever the database is written. Cached data stays current, but you cache data that may never be read.
• Set a TTL so stale entries expire.
• DynamoDB Accelerator (DAX): An in-memory cache for DynamoDB with microsecond reads and the same API, so application changes are minimal.
• ElastiCache for Valkey or Redis OSS supports replication, Multi-AZ failover, and rich data types; Memcached is a simple, multithreaded cache without replication.

Connections, engines, and migrations

• Amazon RDS Proxy: Pools connections in front of RDS and Aurora so thousands of short-lived Lambda invocations don't exhaust the database's connection limit.
• Choosing an engine: Keep the engine the application already uses unless there's a reason to change. PostgreSQL brings rich extensions (for example PostGIS for geospatial data); MySQL is widely supported by existing applications.
• Homogeneous migration: Same engine (MySQL to RDS for MySQL): native tools or AWS DMS.
• Heterogeneous migration: Different engine (Oracle to Aurora PostgreSQL): convert the schema with DMS Schema Conversion or the AWS Schema Conversion Tool, then move the data with AWS DMS, using change data capture to keep it in sync until cutover.