Amazon Aurora

1. Disaggregated storage + 6-copy quorum layer ("log is the database") What it is: the compute layer has no local persistence; only redo logs cross the network; the storage layer holds 6 copies across 3 AZs (write 4/6, read 3/6), so a whole-AZ loss doesn't affect write availability; a crashed compute instance restarts with no redo replay. This is the fundamental reason Aurora failover is measured in seconds and backups have zero performance impact (SIGMOD 2017 paper). Edge truth: see Deep water 1 — "infinitely elastic storage" is an illusion; the single writer instance class is still the write-throughput ceiling; hot writes can make a few 10GB protection groups jitter, and the storage layer exposes no user-visible partition-level throttling numbers, so diagnosis relies on inferring from metrics.
2. Serverless v2 (renamed Aurora Serverless in 2026-04): 0–256 ACU, per-second billing, can scale to 0 What it is: scaling in seconds with connections intact; since 2024-11 it can scale to 0 ACU and auto-pause, with zero compute cost while paused and ~15 seconds to resume 厂商口径. Fluctuating/intermittent workloads and dev/test environments finally get true "pay nothing when idle". Edge truth: see Deep water 6 — "zero cost" has three gates: the default 0.5 ACU minimum is a floor price, storage is still billed while paused, and attaching RDS Proxy / enabling logical replication / being the primary of a Global Database blocks auto-pause. The first wave of morning traffic eats a cold start.
3. Global Database: cross-Region single-writer multi-reader + Region-level DR in one What it is: storage-layer physical replication bypasses the engine, so primary performance is unaffected; vendor-claimed typical lag <1 second; planned switchover can achieve RPO=0 (<30 seconds). Local reads in each Region with low latency — the natural solution for globalized read workloads. Edge truth: see Deep water 4 — for unplanned failover, RPO = the actual replication lag at that moment; you must watch the AuroraGlobalDBRPOLag metric in real time; cross-Region transfer + replicated I/O are billed separately; writes only ever happen in the primary Region — cross-Region write forwarding is "convenience", each DML paying one cross-Region RTT.
4. Clone: copy-on-write, clone the whole cluster in minutes What it is: shares storage blocks with the source, consuming almost no extra storage initially; "copy a production database" for testing, load tests, or incident reproduction goes from hours to minutes. Edge truth: cheap to create ≠ cheap to keep — continued writes on the clone accumulate differential storage and I/O costs; a clone is a one-shot snapshot copy that never follows the source, so test conclusions on a stale clone can be misleading.
5. I/O-Optimized billing: cost predictability for I/O-heavy workloads What it is: removes per-operation I/O charges; workloads where I/O exceeds ~25% of total spend (vendor-claimed breakeven) come out cheaper, with real-world cases showing substantial total savings. Edge truth: the tradeoff is higher compute and storage unit prices 厂商口径; databases with low I/O share but large, rarely-accessed storage do worse on it; Standard → I/O-Optimized switches are limited to once per 30 days — switch wrong and you wait a month.

Deep water 1: the quorum storage layer — beautiful math, painful hotspots (domain: storage engine)

• Mechanism: data is cut into 10 GiB protection groups, 6 copies across 3 AZs, write 4/6, read 3/6; the compute layer only emits redo logs and never writes data pages (official paper).
• At the edge: losing a whole AZ (2 copies) doesn't affect writes; lose 1 more node (3 copies gone total) and the write quorum can't be formed → writes unavailable, reads still available — that's the design goal, not a bug. Highly skewed writes concentrate pressure on a few protection groups; community benchmarks observe regular performance jitter, and AWS's own tuning guide recommends lightweight primary keys and moving foreign-key checks to the application. The storage layer exposes no partition-level throttling numbers; hotspot symptoms show up as write-latency jitter rather than explicit errors 待验证.
• Selection implication: choosing Aurora means choosing "stateless compute, failover without moving data"; but don't read "auto-scaling" as "unlimited" — the single-writer instance class and the write-hotspot model must be load-tested first.
• Sources: Verbitski et al. SIGMOD 2017 paper; AWS official docs; DZone hotspot-jitter benchmark

Deep water 2: write forwarding & read scale-out — "15 replicas" is 15 copies of compute, not 15 copies of data (domain: replication & read scale-out)

• Mechanism: readers can accept write SQL and forward it to the writer (Aurora MySQL 3.04+, PG 16.4+/15.8+/14.13+, official docs); the reader endpoint distributes via DNS round-robin.
• At the edge: write forwarding has many hard limits — MySQL only REPEATABLE READ, neither engine supports DDL / SAVEPOINT / XA / LOCK / TRUNCATE / COPY / cursors, and PG additionally doesn't support stored procedures or LISTEN/NOTIFY; forwarded sessions consume writer connection-pool quota (MySQL default 10%, PG default 25%), so a write burst hits that quota first. Cross-Region write forwarding pays one cross-Region RTT per DML (official blog measured +12–15ms per statement between us-east-1 and us-east-2). The reader endpoint is DNS round-robin (TTL 5 seconds), not load balancing — JVMs caching DNS indefinitely by default and connection pools holding long-lived connections both cause "uneven reads" (official blog).
• Selection implication: write forwarding is a convenience feature for "occasional writes", not a second write entrance — the single-writer nature doesn't change; latency-sensitive read paths should go through the writer endpoint; long-lived connection pools must be configured with connection recycling (ConnMaxLifetime).
• Sources: AWS official docs; official blog

Deep water 3: failover — database recovers in 30 seconds, the application can be down for minutes (domain: high availability)

• Mechanism: promote a reader to writer by failover priority tier; shared storage means no data copy; writer endpoint DNS (TTL 5 seconds) switches; vendor-claimed typically under 30 seconds, community-measured 30–60 seconds end to end. Committed transactions survive via the 4/6 quorum; all uncommitted in-flight transactions are lost.
• At the edge: DNS caching is the #1 killer — JVMs cache DNS 30 seconds to indefinitely by default; without setting networkaddress.cache.ttl the app keeps hitting the old IP; one community benchmark showed a single JVM parameter dropping app recovery from ~5 seconds to ~100ms 社区实测. Clusters with no reader take minutes to fail over (at least 1 reader in production is a hard requirement). RDS Proxy can compress app-side recovery to seconds (AWS internal benchmark: ~3s average vs ~14–24s direct, vendor claim). There are no publicly distinguishable failover-time numbers between MySQL and PG — they must not be used to pick an engine 待验证.
• Selection implication: Aurora's RTO is essentially a "control-plane switchover"; real RTO depends on client-side reconnection engineering; chaos drills must test client behavior together with the database.
• Sources: AWS official docs; community tests (re:Post)

Deep water 4: Global Database — RPO must be understood bound to the real-time lag metric (domain: disaster recovery)

• Mechanism: 1 primary Region + up to 10 secondary Regions (official docs; 5 at launch), storage-layer physical replication, vendor-claimed typical lag <1 second.
• At the edge: planned switchover can achieve RPO=0 (<30 seconds); unplanned failover loses exactly the actual replication lag at that moment, which must be measured with AuroraGlobalDBRPOLag, not assumed to be 0 (community recommendation: alert when lag >2s sustained for 5 minutes). After a disaster failover, the old primary Region's volume is replaced and must be rebuilt from snapshot (hours) — DR drills must use switchover; using failover for drills introduces unnecessary rebuild and data-loss risk 社区实测. Each attached secondary Region consumes one reader slot on the primary cluster (one secondary = one fewer reader available). The rds.global_db_rpo parameter can back-pressure secondary lag into the primary Region's write path — once on, primary write latency is coupled to secondary health.
• Selection implication: Global Database is "single-writer multi-reader + Region-level DR", not multi-active; before writing "~1s RPO" into an SLA, look at the P99 lag; cross-Region transfer + replicated I/O are billed separately — budget at least 2× a single Region.
• Sources: AWS official docs; community runbooks

Deep water 5: I/O billing — Aurora's #1 cost deep water (domain: cost)

• Mechanism: on the Standard edition, besides compute + storage, read/write I/O is billed separately per million operations (get a quote / check the bill).
• At the edge: full table scans / missing indexes, or a working set that doesn't fit in memory (a classic trigger: Serverless v2 upper bound set too small) cause read amplification; a real community bill (2026-06): a small database capped at 1.0 ACU had I/O charges at 68%–88% of its total monthly Aurora bill 社区实测. A degraded previously-optimized query can detonate I/O costs too. Investigate via the Aurora:StorageIOUsage line item in Cost Explorer and the CloudWatch VolumeReadIOPs/VolumeWriteIOPs metrics.
• Selection implication: the first thing after adopting Aurora is a billing alarm on I/O; size memory generously — ACU spend is cheaper than an I/O horror bill; once I/O exceeds ~25% of spend, evaluate switching to I/O-Optimized (but only one switch per 30 days — don't get it wrong).
• Sources: community bill cases (2026-06, community-tested); AWS official docs

Deep water 6: Serverless v2 — the three gates of "serverless" (domain: cost/operations)

• Mechanism: 0–256 ACU, 0.5-ACU steps, per-second billing; ~15 seconds to resume from a 0-ACU auto-pause (vendor claim; community-tested ~12–30 seconds after being paused more than 24 hours).
• At the edge: "pay nothing when idle" has three gates — ① the default 0.5 ACU minimum is a 24×7 floor price; ② storage is still billed while paused; ③ attaching RDS Proxy, enabling logical replication/binlog replication, or being a Global Database primary blocks auto-pause, leaving the instance pinned at 0.5 ACU 社区实测. Scale-up is seconds, scale-down is minutes (jitter protection); new connections queue/time out during resume, and some teams ping on a schedule to keep instances warm and dodge cold starts 社区实测.
• Selection implication: dev/test/intermittent workloads are cheapest at 0 ACU; online services should set a 2–4 ACU floor to dodge the morning-rush cold start; the "provisioned writer + Serverless v2 reader" mix is a community-validated cost-saving combination.
• Sources: AWS official docs; AWS Database Blog; community tests

Deep water 7: version lag & upgrade pain — the price of managed is "waiting for AWS releases" (domain: compatibility/versions)

• Mechanism: Aurora MySQL 3.x minor versions lag community 8.0 by months; Aurora PG major versions lag community by months to over a year (official release calendar + community consensus).
• At the edge: 2026-05-21 was a turning point — Aurora MySQL 8.4 went GA, aligned with community 8.4.7 with matching version numbers, and AWS committed to major versions within 12 months and minor versions within 3 months 厂商口径; before that, "RDS MySQL has 8.4 but Aurora doesn't" was a recurring re:Post complaint. Major upgrades are the biggest ops pain: MySQL 2→3 prechecks commonly fail on data-dictionary inconsistencies and plans regress after upgrade (optimizer changes, query cache removal, default charset change to utf8mb4); PG upgrades rely on blue/green deployment but hide prerequisites (the source cluster must have no active logical replication slot — undocumented, community-tested, hours of debugging; no DDL during cutover; ANALYZE/REINDEX needed after cutover); in-place upgrades have no rollback.
• Selection implication: teams chasing the newest features must accept the "wait for the release" rhythm on Aurora — plain RDS usually tracks faster; do major upgrades via blue/green + pre-upgrade precheck item by item, and treat the rollback path (blue/green cutback) as mandatory.
• Sources: AWS What's New; AWS official docs; re:Post community tests

1. Fast failover
   • Why it's real: shared storage means no data copy — promote a reader + flip DNS and you're done; vendor-claimed typically under 30 seconds, community-measured 30–60 seconds end to end, significantly faster than traditional primary-standby rebuilds.
   • Edges & limits: the fast part is "database recovery" — application recovery depends on DNS caching and reconnection engineering; reader-less clusters take minutes; RDS Proxy or the Advanced JDBC Wrapper is needed to compress the app side to seconds too.
2. Worry-free operations
   • Why it's real: OS/engine patching, backups, storage expansion are all managed; minor versions can auto-upgrade; the stateless compute layer means a dead instance just gets rebuilt.
   • Edges & limits: what's managed is "machine operations", not "database operations" — slow SQL, indexes, parameter tuning, and upgrade planning all remain yours; no SUPER privilege means some firefighting tools (direct system-table edits, arbitrary extensions) are unavailable, so the self-hosted firefighting ceiling is higher.
3. Easy read scale-out
   • Why it's real: adding a reader copies no data, comes up in minutes, up to 15 of them; the reader endpoint distributes automatically.
   • Edges & limits: the endpoint is DNS round-robin, not true load balancing — pools that never recycle connections read unevenly; PG's ReplicaLag is page-cache semantics, so lag readings outside steady state need care; there is no write scale-out — single writer is a hard ceiling, and once writes top out you either go Limitless (PG only) or shard manually.
4. Serverless elasticity
   • Why it's real: 0–256 ACU billed per second, scaling without dropping connections; genuinely cheap for bursty workloads and dev environments.
   • Edges & limits: see Deep water 6 — floor price, storage charges, the four pause-blocking configurations, cold starts; ACU unit prices are higher under I/O-Optimized, so storage-config decisions must account for ACU unit pricing together.
5. MySQL / PG compatibility, smooth migration
   • Why it's real: protocol compatibility, JDBC/ORM/DMS/Debezium all work; migrating from self-hosted MySQL/PG barely touches the application layer.
   • Edges & limits: what's compatible is "protocol and most syntax", not "ops habits" — MyISAM tables must become InnoDB, compressed tables must be uncompressed, keyring/TDE becomes KMS volume encryption, SUPER privileges must be downgraded, C extensions/PAM authentication must be redone (official migration limitation list); version lag means waiting for community features.

• Good fit for: teams already on AWS; teams that don't want to operate databases and will pay a premium for managed; read-heavy workloads needing fast reader additions; bursty/intermittent workloads (Serverless v2); globalized businesses needing near-Region reads + Region-level DR (Global Database); MySQL/PG protocol migrations to the cloud.
• Poor fit for: budget-sensitive small databases (RDS or self-hosted is cheaper at the same spec — Aurora's storage-layer overhead doesn't pay off on small steady workloads); write-heavy businesses hitting the single-writer ceiling that won't accept Limitless's sharding rework cost; teams needing community MySQL/PG features "day one"; teams heavily dependent on obscure PG extensions, SUPER privileges, or self-built plugins; multi-cloud / xìnchuàng (IT localization) / must-run-outside-AWS requirements.
• Migration cost: MySQL → low (protocol-compatible, mature DMS/snapshot/XtraBackup tooling; watch the MyISAM/compressed-table/TDE/keyring/SUPER rework items); PostgreSQL → low (protocol-compatible; watch the extension whitelist and rds_superuser downgrade); Oracle → high (no Oracle compatibility mode, Babelfish is PG-only and unsupported on Limitless — go the application-rework route or pick EDB etc.).

• Version info: AWS What's New (Aurora MySQL 3.13 GA 2026-08-28; Aurora MySQL 8.4 GA 2026-05-21), AWS Aurora PostgreSQL release calendar (18.4 / 17.10 / 16.14 / 15.18 all released 2026-08-21; LTS: 17.7 / 16.8 / 15.10)
• Architecture: Verbitski et al. SIGMOD 2017 paper (quorum math, log-is-the-database); AWS official docs (256 TiB storage cap announced 2025-07, Global Database, write forwarding, Backtrack, blue/green deployment); AWS Database Blog (Serverless v2 scale-to-0 ACU, cross-Region write-forwarding latency measurement, RDS Proxy blue/green integration 2026-04)
• Deep-water field tests: DZone hotspot-jitter benchmark, re:Post (PG lag semantics, DNS issues), community runbooks (Global Database lag thresholds, switchover vs failover), Debezium community notes (Backtrack vs Enhanced Binlog mutually exclusive), aws-samples db-advisor skill library (cost model, upgrade checklist)
• Complaint mining: re:Post, Hacker News billing threads, GitHub community notes, aws-samples migration limitation lists
• To-be-verified: actual availability and pricing differences of Serverless v2 auto-pause / I/O-Optimized in China regions; default at-rest encryption policy for new clusters; distinguishable MySQL vs PG failover-time numbers; partition-level throttling numbers for storage-layer hotspots
• Next review: track whether Aurora MySQL 8.4's version-catchup SLA holds (officially committed: majors within 12 months / minors within 3 months), Aurora PG 19 release cadence, Limitless extension-whitelist and production-case maturity