How RDS works

A real database, minus the operations

RDS runs a standard engine (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2) on a server AWS babysits: patching, backups, monitoring, and hardware replacement are handled for you.

What it is not is automatically horizontally scalable. Out of the box you have one primary instance that handles every write, and you make it bigger the old-fashioned way, a larger instance class.

Multi-AZ: a hot standby, not a speed boost

Turn on Multi-AZ and RDS keeps a standby copy in a second Availability Zone, kept identical by synchronous replication. If the primary or its whole AZ dies, RDS promotes the standby and flips the endpoint automatically.

⚓ This is the baseline for any production database that can’t afford an AZ outage to mean downtime.

Wait, isn’t there a version where the standbys ARE readable?

Yes. The newer Multi-AZ DB cluster deployment (MySQL and PostgreSQL only) uses three instances (one writer, two readable standbys) kept in sync semisynchronously, and can serve reads from the standbys. The classic, far more common Multi-AZ instance deployment described here keeps a single, synchronous, non-readable standby. Know which one you’re running.

Read replicas: scaling reads, not writes

To actually serve more traffic, add read replicas: extra copies that RDS keeps updated asynchronously (up to 15 for MySQL, MariaDB, and PostgreSQL; five for Oracle, SQL Server, and Db2). Send your read-only queries (reports, dashboards, search) to them.

Writes still go only to the primary, so replicas scale the read half of your workload and do nothing for write-heavy load.

The connection ceiling

Each open connection costs memory, so RDS caps concurrent connections roughly in proportion to the instance’s RAM. A flood of short-lived connections (a typical serverless or per-request pattern) can hit that ceiling while CPU sits nearly idle.

The fix is a connection pool in front of the database, often RDS Proxy, which multiplexes many client connections onto a few real ones.

Roughly how is the connection limit decided?

For most engines max_connections scales with available memory (RDS for PostgreSQL’s default formula works out to roughly one connection per ~9 MB, capped at 5,000). Bigger instance, more connections, but you’ll usually run out of a sensible connection budget before you run out of CPU, which is exactly why pooling matters.

Storage and IOPS: the write-heavy bottleneck

RDS storage is network-attached SSD with a provisioned throughput budget measured in IOPS (I/O operations per second). On gp3 you get a baseline and can provision more; io2 goes higher for demanding workloads.

Write-heavy and commit-heavy workloads often hit the IOPS ceiling before CPU, the symptom is high disk-queue latency while the processor looks bored.

⚓ Classic for order-processing and logging systems that commit constantly.

Backups and point-in-time recovery

With automated backups on, RDS takes daily snapshots and continuously archives transaction logs. Together these enable point-in-time recovery: restore a brand-new instance to any second within your retention window (up to 35 days).

Note the word new: a restore creates a separate instance, it doesn’t rewind the existing one in place. Manual snapshots, by contrast, live until you delete them.