Skip to content

SYSTEM Cited by 2 sources

Amazon Aurora

Amazon Aurora is AWS's cloud-native relational database engine — wire-compatible with MySQL or PostgreSQL with a distributed storage layer that decouples compute from storage and replicates across three Availability Zones. Parent line to Aurora DSQL (distributed SQL) and Aurora Limitless (horizontally-scaled Postgres).

Blue/green deployments

Aurora's canonical mechanism for low-downtime schema changes + version upgrades + instance-class changes is blue/green deployments. AWS clones the existing cluster via a copy-on-write storage clone into a parallel "green" environment, configures binlog replication between blue (production) and green, and exposes a scripted switchover primitive that cuts traffic over with a short all-connections-dropped window ("less than a minute" happy path).

The scripted switchover lifecycle canonicalised verbatim by Morrison II (2024): guardrails check compatibility + long-running-operations absence; then (a) stop new writes on blue + drop all connections; (b) wait for final writes + replication catch-up; (c) switch blue to read-only; (d) rename resources so green adopts blue's original endpoint names (blue gets an old- prefix).

See patterns/blue-green-database-deployment for the architectural pattern.

Storage-layer architecture

Canonicalised via the 2023-10-05 PlanetScale PlanetScale vs. Amazon Aurora post: Aurora decouples compute from storage and uses a unified distributed storage layer that "automatically scales and replicates storage in 10GB increments, distributing it 6-times across 3 availability zones on a single unified storage layer. It does this without affecting compute resources."

  • 6-way replication across 3 AZs — each 10GB chunk is replicated six times, distributed across three availability zones (2 copies per AZ). Quorum-based writes (4/6) + quorum-based reads (3/6) tolerate full-AZ loss + one additional copy failure before write availability is impacted.
  • 10GB increments — the unit of storage allocation and replication. Storage auto-scales in 10GB chunks as the database grows; operators do not pre-provision storage.
  • Compute-storage separation — ([[concepts/compute-storage- separation]]) the storage layer is a service shared across compute instances; compute nodes are effectively stateless cache-tiers over the distributed storage. This is the architectural lever that makes Aurora blue/green (via copy-on-write clone), Aurora Global Database (cross-region replication), and Aurora Serverless V2 (rapid compute right-sizing) all tractable on the same substrate.

Internal replication architecture

Canonicalised via the 2024-01-24 Morrison II PlanetScale vs Amazon Aurora replication post: Aurora's internal cluster replication uses a proprietary redo-log-forwarding scheme onto the distributed storage substrate — deliberately different from the MySQL binlog replication that the cluster still exposes externally for cross-system integration.

"While Aurora does use the binary log for external replication, AWS has built a closed and proprietary replication system that deviates from the traditional MySQL replication configuration for replicating within an Aurora cluster." (Source: )

The 6-step replication flow (verbatim from Morrison's Table 2):

  1. Clients that need to write data connect to the read/write compute node.
  2. Clients with read-only workloads can connect to one of the read-only nodes.
  3. Read/write nodes can read from and write to storage segments. The R/W node will ensure four segments have acknowledged writes before responding — see concepts/aurora-storage-quorum for the 4-of-6 write quorum, 10 GiB segment size, and 3-AZ distribution.
  4. Read-only nodes are notified of data changes so in-memory pages can be updated — the writer pushes page invalidations out-of-band so reader buffer caches stay current without replaying a log.
  5. Read-only nodes have read-only connections to storage segments — they share the same storage the writer writes, not a separate replica copy.
  6. Storage segments replicate to each other to maintain the 6-copy quorum.

See patterns/storage-forwarded-redo-log-replication for the full pattern page.

Consequences of the substrate choice (per Morrison II):

  • Replication lag is reduced but not eliminated — "the source node will directly notify any read-only nodes of updates… replication lag still needs to be considered."
  • No horizontal sharding for Aurora MySQL (2024-01 datum) — the shared-storage substrate scales reads and durability but not writes. "Currently, Amazon Aurora does not support this capability for MySQL workloads." Aurora Limitless addresses this separately for Postgres later.
  • Rolling MySQL upgrades not supported — without independent replica substrates, version upgrades require a maintenance window. "Aurora's approach… requires upgrades to be performed within a maintenance window, which can lead to downtime for your database."
  • Proxy-transparent failover — Aurora's cluster endpoint + RDS Proxy hide node churn from clients via the concepts/proxy-transparent-failover abstraction, the same user-facing contract PlanetScale exposes via VTGate.
  • Cross-region read replicas — via Aurora Global Database, which uses async cross-region replication (patterns/async-replication-for-cross-region).

Read replicas

Aurora supports up to 15 read replicas per primary instance distributed across availability zones. Load-balanced via an Aurora reader endpoint that automatically distributes queries across available replicas. Canonical instance of read-replica read scaling on a compute-storage-separated substrate: replicas attach to the same unified storage layer (no per-replica storage copy), so read scale-out does not multiply storage cost the way traditional primary-replica replication does.

Schema change + revert

Aurora "does not provide native tooling for schema changes, and does not support online schema changes". For DDL-breaking changes, Aurora offers two escape hatches:

  • Aurora Backtrack — a point-in-time recovery primitive that rewinds the entire database to a timestamp. Per the 2023-10 PlanetScale post: "Aurora Backtrack can be used to restore the database to a point-in-time (PIT) to recover from DDL operations that introduce a breaking change." Scope constraints: Aurora-MySQL-only (not supported on Aurora PostgreSQL); 72-hour maximum retention window; whole-database blast radius (not per-table); write-unavailable during rewind.
  • Blue/green deployments (see above) — the primary mechanism for additive + binlog-replicatable schema changes with no revert path post-switchover.

Reconciliation with Morrison II's "no revert" framing: The 2024-02 [[sources/2026-04-21-planetscale-planetscale- branching-vs-amazon-aurora-bluegreen-deployments|Morrison II branching-vs-blue-green post]] states "Amazon does not permit you to fail back in any way" — correct for the "schema revert preserving post-switchover writes" axis (Backtrack rewinds writes along with the schema). Schema Revert on PlanetScale via [[concepts/ghost-table- migration|retained ghost table inverse replication]] is the architectural dual — revert the schema while preserving post-merge writes — which Backtrack structurally cannot provide.

Pricing surface primitives

Canonicalised via the 2023-10 PlanetScale post:

  • On-demand — pay-as-you-go compute + storage.
  • Reserved Instances — discounted compute via capacity commitment.
  • Aurora Serverless V2 — auto-scaling compute for "users that experience high workload variability". Scales compute in fine-grained increments (ACU = Aurora Capacity Units) without the blue/green-instance-class-change all-connections- drop that fixed-instance Aurora requires.
  • I/O Optimized — pricing tier "available for customers with high Input/Output operations" that trades higher compute/storage per-hour rates for unmetered I/O. Break-even depends on workload IOPS intensity.

Seen in

  • — Brian Morrison II (PlanetScale, 2024-01-24). Canonical wiki disclosure of Aurora's internal replication architecture — redo-log forwarding to dedicated storage appliances + 10 GiB segments × 6 copies × 3 AZs × 4-of-6 write-ack quorum + writer-driven page-update notifications to read-only compute nodes. Also canonicalises: Aurora MySQL does not support horizontal sharding (2024-01 datum); Aurora requires a maintenance window for version upgrades (no rolling upgrades due to shared-storage substrate); Aurora still uses binlog for external replication despite the proprietary internal scheme; both Aurora and PlanetScale share the same user-facing abstractions (concepts/proxy-transparent-failover, auto-storage-grow, auto-node-replacement, cross-region read replicas via Aurora Global Database vs PlanetScale Portals).

  • — PlanetScale (2023-10-05). Canonical wiki disclosure of Aurora's storage-layer geometry: "automatically scales and replicates storage in 10GB increments, distributing it 6-times across 3 availability zones on a single unified storage layer" + 15-read-replicas-per- primary-instance ceiling + Aurora Backtrack as PITR-based DDL-breakage escape hatch + Serverless V2 + I/O Optimized pricing primitives. Vendor-comparison voice positions PlanetScale (commodity EC2 + commodity storage) against Aurora (proprietary storage

  • AWS-only). Complements Morrison II's blue/green mechanism post with the storage-substrate altitude + the Backtrack-as-PITR-escape-hatch datum.

  • — Brian Morrison II (PlanetScale, 2024-02-02). Canonical wiki disclosure of Aurora blue/green deployments. Vendor-comparison positions Aurora's mechanism against PlanetScale's [[concepts/ database-branching|database branching]] + rolling upgrades. Key constraints Morrison names: schema-change envelope bounded by MySQL binlog-replication compatibility (adds-at-end + indexes OK; mid-table adds + renames

  • type narrowing out of scope); switchover drops all active connections even on happy path; effective compute cost is ~2× fleet cost during green lifetime (Aurora clones read replicas 1:1, worked example 4 blue + 4 green = 8 total); blue environment stays running post-switchover and accrues cost until operator-initiated teardown; no revert path — "Amazon does not permit you to fail back in any way"; two-side-writeable data-consistency risk — copy-on-write clone permits writes on both sides with no automatic reconciliation.

  • sources/2026-04-01-aws-automate-safety-monitoring-with-computer-vision-and-generative-ai — Aurora PostgreSQL hosts application state that cannot absorb the raw inference-image volume; the ML-inference layer functions as the gatekeeper filtering events that reach Aurora: "This filtering is essential because it prevents components interacting with Amazon Aurora PostgreSQL from being overwhelmed by the raw volume of image data from hundreds of sites." The BI team exports risk data from the Aurora reader endpoint hourly (flexible schedule) for downstream analytics.

  • sources/2026-04-21-aws-oldcastle-infor-aurora-quicksight-real-time-analytics — canonical wiki instance of Aurora PostgreSQL as a streaming-CDC relational buffer at production scale. Oldcastle's Aurora PostgreSQL-Compatible Multi-AZ cluster (1 writer + multiple readers across AZs) absorbs Infor Data Fabric Stream Pipelines events into JSONB columns for flexible ingest, with expression indexes on hot fields for query performance (concepts/jsonb-streaming-buffer). Fronted by RDS Proxy with IAM auth + automatic failover; 50+ dashboards, 100+ concurrent users, millions of transactions/day processed in real time via QuickSight with SPICE caching. Canonical production case study for patterns/streaming-cdc-to-relational-buffer.

Last updated · 542 distilled / 1,571 read