--- title: "10 — RDS: Managed Relational Databases, Without the DBA Chores" uid: rds-relational tags: ["database", "sql", "aws", "backup", "rds", "roadmap:aws", "aurora", "storage"] excerpt: "'Managed MySQL' undersells RDS. AWS runs the engine — patches, backups, multi-AZ, storage scaling — and you run the database: schema, queries, instance size." date: 2026-08-13T03:28:29+0000 source: https://www.aveshina.my.id/en/blog/rds-relational --- RDS was "managed MySQL" to me, and that label hid the actual deal. The value proposition that settled it: **RDS takes a relational database I would otherwise run myself — MySQL, Postgres, MariaDB, Oracle, SQL Server, or the AWS-built Aurora — and removes the operational chores: OS patching, engine patching, automated backups, multi-AZ replication, storage scaling, point-in-time recovery** [1]. What's left for me to own is the schema, the data model, the queries, and the instance size. That split — AWS runs the engine, I run the database — is the whole service. ## What "managed" actually buys The chores RDS removes are the ones that eat a DBA's week: - **Patching.** The OS and the database engine are patched on a schedule I control (a maintenance window). I no longer SSH in to run apt upgrade. - **Backups.** Automated daily snapshots plus continuous transaction logs give point-in-time recovery — typically down to within five minutes [5]. - **High availability.** A **Multi-AZ deployment** keeps a synchronous standby in a second AZ; if the primary fails, RDS fails over to the standby automatically. - **Scaling.** Storage can grow on demand without downtime; compute is a resize operation (brief interruption, scheduled in a window). The thing RDS does *not* remove: schema design, query tuning, indexing. A slow query is still my slow query, no matter who runs the engine. ## DB instances and engines The unit of RDS is a **DB instance** — an isolated database environment in the cloud [3]. One instance can host multiple databases; I pick the engine (MySQL, Postgres, etc.), the instance size, and the storage at creation. Aurora deserves a callout: it's AWS's purpose-built cloud-native engine, MySQL- and Postgres-compatible at the wire level, but with a separated storage layer that replicates six ways across three AZs by default [1]. Faster failover, more durable, and often cheaper at scale than the equivalent stock-engine Multi-AZ setup. When the workload fits, Aurora is usually the better answer than plain MySQL/Postgres on RDS. ## Storage: three flavors tuned to the workload RDS storage is EBS under the hood, and the choice is the same price/performance dial EC2 faces [2][4][6]: - **General Purpose SSD (gp2/gp3)** — the default, balanced. Good for most workloads; gp3 lets me provision IOPS (I/O operations per second — how fast the disk reads and writes) independently of size. - **Provisioned IOPS (io1/io2)** — for I/O-intensive workloads where predictable, high IOPS matter. I pay for the IOPS I reserve, whether I use them or not. The right pick for a busy OLTP database (one handling a stream of live transactions) whose latency budget is tight. - **Magnetic** — the legacy, spinning-disk tier. Cheapest per GB, worst performance. Almost never the right answer today; it exists for old workloads pinned to it. The mental rule I use: start on General Purpose, watch the queue depth and IOPS consumption in CloudWatch, and move to Provisioned IOPS only when General Purpose is the binding constraint. Provisioned IOPS is a scalpel, not a default. ## Backup and restore The backup story has two layers worth separating [5]: - **Automated backups** — daily snapshot plus continuous transaction logs. Enable point-in-time recovery to any second within the retention window (1–35 days). This is the "I dropped a table at 2:03pm, put it back" tool. - **Manual snapshots** — I take them, they persist until I delete them, and they're how I keep long-term retention beyond the 35-day automated window. Restoring always creates a **new** DB instance — I do not overwrite the original. Point-in-time restore spins up a fresh instance at the requested moment; the source keeps running untouched, which matters when the "incident" is a bad migration I want to compare against. ## How I use this RDS is my default the moment a workload needs a real relational schema and I'd rather not run my own Postgres. The standing setup: Multi-AZ on for anything production (the synchronous standby is the single biggest availability lever), automated backups with a 7–35 day retention depending on the data, storage on gp3 with IOPS provisioned to match, and Aurora where the workload is large enough that its storage architecture pays off. The part I never outsource is the schema and the queries — RDS will happily run a missing-index query at full speed into a timeout, and no managed feature rescues a bad data model. The service removes the chores; it does not remove the engineering. ## References [1] Amazon Web Services, "What is Amazon RDS?," 2024. [Online]. Available: [https://aws.amazon.com/rds/](https://aws.amazon.com/rds/) [2] Amazon Web Services, "Amazon EBS volume types," EBS User Guide, 2024. [Online]. Available: [https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) [3] Amazon Web Services, "DB instances," RDS User Guide, 2024. [Online]. Available: [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html) [4] Amazon Web Services, "Provisioned IOPS SSD volumes," EBS User Guide, 2024. [Online]. Available: [https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html](https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html) [5] Amazon Web Services, "Backing up and restoring an Amazon RDS DB instance," RDS User Guide, 2024. [Online]. Available: [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html) [6] Amazon Web Services, "Amazon RDS storage types," 2024. [Online]. Available: [https://aws.amazon.com/rds/instance-types/](https://aws.amazon.com/rds/instance-types/) ```quiz Q: In a Multi-AZ RDS deployment, the standby instance… - synchronously replicates from the primary and takes over automatically on primary failure - asynchronously replicates and is only used for read scaling correct: 0 explain: Multi-AZ keeps a synchronous standby in a second AZ for high availability. Read replicas (separate feature) are the async, read-scaling option. Q: When would you choose Provisioned IOPS over General Purpose SSD for an RDS instance? - When the workload is I/O-intensive and needs predictable high IOPS with a tight latency budget - When you want the cheapest possible storage correct: 0 explain: Provisioned IOPS reserves I/O capacity you pay for whether used or not. It's for I/O-bound OLTP databases; General Purpose is the default for everyone else. Q: A point-in-time restore in RDS… - overwrites the existing DB instance in place - creates a new DB instance at the requested moment; the original is untouched correct: 1 explain: Restores always spin up a fresh instance. The source keeps running, which matters when comparing against an incident. Q: What does RDS NOT take off your plate? - OS and engine patching, backups, multi-AZ replication - Schema design, indexing, and query tuning correct: 1 explain: RDS manages the operational chores. Schema, indexes, and query performance are still yours — a missing index will time out on RDS just as fast as anywhere else. Q: Aurora differs from stock MySQL/Postgres on RDS mainly in… - its separated, six-way replicated storage layer that improves failover and durability - its lack of compatibility with SQL correct: 0 explain: Aurora is MySQL/Postgres-compatible at the wire level but uses a cloud-native separated storage layer replicating across three AZs. Often faster failover and cheaper at scale. ```