Aurora

In practice, you pick the engine your team already runs. Tools, ORMs, backups, and the people themselves are already tied to MySQL or PostgreSQL. Fighting that rarely pays.

But "compatible" is not "identical," and one difference shows up before you've written a single query: Aurora PostgreSQL does not run vacuum the way stock PostgreSQL runs it.

Quick background, if you haven't lived in this corner of Postgres: every delete or update leaves dead rows behind, and vacuum is the background process that cleans them up. Vacuum also has a deadline to meet. PostgreSQL numbers its transactions with a counter that eventually wraps around, and every table must be fully vacuumed before its counter gets close to the limit (autovacuum_freeze_max_age) — or old data becomes unreadable.

Aurora adds adaptive autovacuum (rds.adaptive_autovacuum, on by default). As a table's transaction counter approaches that limit, Aurora automatically turns vacuum up. Stock PostgreSQL will not do that on its own; you'd have to notice the climb and tune by hand.

Aurora bills differently from RDS, and the difference follows from the architecture. On Aurora Standard storage you pay per I/O operation, and instance rates run higher than the RDS equivalent. What you buy is AZ-level durability and reader scaling where every replica shares the writer's storage layer directly, instead of replaying a binary log onto its own copy.

So you are not paying for "faster." You are paying for a different storage architecture, and that architecture has a different cost shape from RDS's flat, EBS-backed billing.

Every Aurora cluster picks a storage configuration, and this one is a billing decision more than a technical one. On Standard storage you pay for the instance, for the storage, and then again for every I/O operation. I/O-Optimized removes that last charge entirely — zero per-operation billing — and pays for it by raising the other two: storage runs roughly 2.25x the Standard rate, about +125%, and instance pricing runs roughly 30% higher.

So I/O-Optimized is not a general upgrade. It is a tax on compute and storage, collected in exchange for removing I/O charges entirely. Whether that trade pays depends on the shape of your bill — and the shape of your bill changes over time.

An Aurora cluster scales reads by adding Aurora Replicas — up to 15 of them — and you pay for each one as an instance. What you get is read scaling where every replica shares the writer's storage layer instead of replaying a binary log to catch up.

The default reader endpoint is the simple way in: one DNS name, and every read connection is load-balanced across every replica in the cluster. That is the trade — simplicity for isolation. The endpoint treats all replicas as interchangeable, so all read traffic lands undifferentiated.

Serverless v2 is Aurora's capacity mode where you do not pick an instance class. You set two numbers instead, a minimum and a maximum, and the cluster scales between them in 0.5 ACU increments — ACU being the capacity unit Serverless bills by, per ACU-hour.

The rate is set so that flexibility costs more than provisioned capacity at comparable steady utilization. What the premium buys is real elasticity: workloads that are spiky, or idle most of the day, get to scale with demand instead of paying for a fixed instance class.

Both numbers are load-bearing. The minimum decides how far the cluster can fall; the maximum decides how far it can climb. Each has its own failure mode.

Aurora's fast failover comes from its shared storage architecture: one distributed volume, replicated across three Availability Zones, read by every instance in the cluster — promoting a replica means no data has to move. It trades that speed for an application-layer requirement. "Fast" at the database layer does not automatically mean invisible at the application layer. When the writer fails over, your application's connections drop, and its connection and retry logic still has to reconnect through the cluster's DNS endpoint. Aurora handles the database side of the failure; the reconnection is yours to get right.

Backtrack is Aurora MySQL's rewind: it moves the whole cluster back to a moment in the past, in place. The alternative is a full restore to a new instance — provision, restore, repoint, wait — and skipping all of that is the point. It exists on MySQL-compatible clusters only, and it is billed per million change records per hour: the cluster keeps a running record of changes, and you pay for how much it keeps.

Know what you are buying. Backtrack is not a backup. It is a precision undo tool, with its own cost and its own limits, and both deserve planning.