AWS Database Services

Managed relational, NoSQL and in-memory databases on AWS, and how to choose between them.

  • Amazon RDS Managed relational databases — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
  • Amazon Aurora Cloud-native MySQL/Postgres-compatible engine with distributed storage.
  • Amazon DynamoDB Serverless NoSQL key-value & document database at any scale.
  • Amazon ElastiCache In-memory caching (Valkey, Redis OSS, Memcached) with sub-millisecond latency.

Overview

AWS offers purpose-built databases rather than a single engine, and the right choice follows from the access pattern. This section covers the four operational services most applications start with, plus a pointer to Redshift for analytics. Amazon RDS runs familiar engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) with AWS handling patching, backups and failover. Amazon Aurora keeps MySQL and PostgreSQL compatibility but replaces the storage layer with a distributed, replicated volume shared by the writer and up to 15 read replicas. DynamoDB is a serverless key-value and document store that scales throughput by partitioning on the key you choose. ElastiCache is an in-memory cache and data store for microsecond-to-millisecond reads.

How the Services Relate

Choosing an AWS Database by Access Pattern Relational, SQLjoins, transactions Key-value at scaleknown access keys Sub-ms readshot data Analyticsscans, aggregates RDS / AuroraMySQL, PostgreSQL DynamoDBserverless NoSQL ElastiCacheValkey, Redis, Memcached Redshiftcolumnar warehouse Many systems combine them: Aurora as the system of record, ElastiCache in front for hot reads, Redshift for reporting.

Start from the questions the application asks. If queries need joins, ad-hoc filters and multi-row transactions, choose a relational service: RDS for standard engines and the lowest cost at small scale, Aurora when you need faster failover, more read replicas or storage that grows automatically. If every access is by a known key and the workload must scale to very high request rates with no servers to manage, DynamoDB fits, at the cost of designing tables around access patterns up front. Put ElastiCache in front of either when the same data is read far more often than it changes, or use it for sessions, leaderboards and rate limiting. Move heavy reporting off the operational database into Redshift.

Comparison

ServiceModelScalingTypical use
Amazon RDSrelational, several enginesvertical, read replicasline-of-business apps, lift-and-shift
Amazon AuroraMySQL/PostgreSQL compatibleshared storage, up to 15 replicas, Serverless v2high-availability OLTP
Amazon DynamoDBkey-value / documenthorizontal, on-demand or provisionedhigh-scale, predictable key access
Amazon ElastiCachein-memory key-valuecluster mode shardingcaching, sessions, counters
Amazon Redshiftcolumnar SQL warehouseRA3 nodes or ServerlessBI and analytics

Each page in this section covers architecture, configuration and example code for one service. Related AWS areas include storage and analytics.