Skip to content

PLANETSCALE 2024-01-24

Read original ↗

PlanetScale — PlanetScale vs Amazon Aurora replication

Summary

Brian Morrison II (PlanetScale, 2024-01-24, re-fetched 2026-04-21) publishes a point-by-point vendor comparison of Amazon Aurora's and PlanetScale's replication architectures. The two products look superficially similar (primary + read-replica MySQL-compatible clusters with auto-failover and auto-grow storage) but diverge sharply at the substrate: Aurora implements a proprietary redo-log forwarding scheme onto a distributed storage fabric with 6 storage segments across 3 AZs and a 4-of-6 write-ack quorum, whereas PlanetScale runs traditional MySQL binlog replication between a source and replicas, each holding its own full copy of the data. The divergent substrates drive different behaviour on rolling upgrades, sharding, backup validation, and downstream tooling — even though both platforms converge on the same user-facing primitives (query-proxy transparent failover, cross-region read replicas via Aurora Global Database and PlanetScale Portals, auto-expanding storage).

The post is a Tier-3 marketing-adjacent comparison — its architectural yield is modest relative to deeper PlanetScale posts — but it is the canonical wiki disclosure of Aurora's internal replication architecture (10 GiB segments, 6-copy 4-ack quorum, 3-AZ spread, read-only compute nodes notified of page updates by the writer) and one of the earlier PlanetScale vendor-comparison voices. Preserved as a structural architectural reference alongside the 2024-02-02 Morrison blue/green post (sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments).

Key takeaways

  • Traditional MySQL replication is PlanetScale's substrate. "PlanetScale database clusters follow this traditional style of replication, meaning each MySQL node contains a copy of the data it needs to operate properly." (Source: Morrison, verbatim.) The cluster has a source (read/write) + one or more replicas (read-only), with the primary appending every committed transaction to the binlog, and each replica tailing and replaying it. Configurable in async / semi-sync modes; the replication delta between source commit and replica visibility is replication lag.

  • Aurora replaces the binlog internally with redo-log forwarding to dedicated storage appliances. "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." "Instead of storing the redo log entries directly on the attached volumes, they are forwarded to dedicated Aurora storage appliances in the same availability zone as the source compute node." (Source: Morrison, verbatim.) The binlog is still available for external (cross-system) replication but is bypassed for the internal cluster replication path — see the new patterns/storage-forwarded-redo-log-replication pattern page.

  • Aurora storage: 10 GiB segments × 6 copies × 3 AZs × 4-of-6 write-ack quorum. "Data on this appliance is stored within 10 GiB segments spread across three availability zones in a given region. Before the compute node responds to the application, Aurora will ensure that at least four of the six default segments have a replicated copy of the data to ensure durability should a data center be taken offline." (Source: Morrison, verbatim.) This is the canonical wiki datum for Aurora's 4-of-6 storage quorum: a write survives losing either an entire AZ (2 of 3 AZs × 2 copies each = 4 remaining) or a whole AZ plus one additional failure.

  • Read-only compute nodes get direct storage access + in-memory page-update notifications from the writer. "Since data is replicated on the storage level, read-only compute nodes can be started at any time in an availability zone containing a copy of the data for that node to read." "For any pages that have been read to memory, the source node will directly notify any read-only nodes of updates. This causes the read-only nodes to accommodate the changed data. As a result, the risk of reading stale data is reduced, however, replication lag still needs to be considered." (Source: Morrison, verbatim.) Canonical illustration of compute–storage separation at the OLTP tier: readers don't replay a log; they share the underlying storage and receive out-of-band page invalidations to keep their buffer cache coherent.

  • Both platforms auto-replace failed nodes via their orchestration tier. "Whenever a new database is created in PlanetScale, we automatically spin up a MySQL cluster containing a source and at least one replica for our production database branches, regardless of the plan you've selected. These nodes are part of a Kubernetes cluster that our backend systems use to ensure that the database cluster is online and healthy. If a replica goes offline for whatever reason, a new one will be automatically created to replace it. If a source goes offline, one of the replicas will be elected to become a source, and a new replica will be created to replace it." "Aurora handles this process in a very similar approach, where it will automatically replace nodes that crash or go offline for whatever reason." (Source: Morrison, verbatim.)

  • Both platforms front the cluster with a query proxy that transparently reroutes traffic on failover. "In the same light, PlanetScale and Aurora have dedicated query proxy services that automatically reroute traffic trying to access a node. This minimizes any downtime clients may experience based on the failure, making them more transparent." (Source: Morrison, verbatim.) This is the canonical illustration of proxy-transparent failover: clients connect to a stable proxy endpoint; node churn (replacement, promotion, scaling) is hidden behind it.

  • Both platforms auto-expand storage. "Aurora's storage appliance will automatically allocate new storage segments as needed. PlanetScale does this as well by monitoring the underlying volumes that contain data for your database and expanding or adding volumes when required. Both platforms provide a solution that essentially prevents your database from ever running out of space." (Source: Morrison, verbatim.)

  • Cross-region read-only replicas: Aurora Global Database ≈ PlanetScale Portals — both use async cross-region replication. "Deploying replicas across different regions can help speed up data access for users in that locale. Both platforms allow you to create read-only regions (named Global Database in Aurora) to do exactly this. When a read-only region is created, replicas will be created in the region of your choice and asynchronous replication will be configured between the home region (where the production database currently resides) and the selected region." (Source: Morrison, verbatim.) Canonical cross-reference between Aurora Global Database and PlanetScale Portals; both instantiate async replication for cross-region for the same physics reason (60ms+ RTT makes sync infeasible).

  • PlanetScale is built on Vitess (2010, YouTube, pre-dates Aurora 2014 by four years). "PlanetScale's Vitess offering is built on top of Vitess, a MySQL-compatible and horizontally scalable project that is completely open source. Vitess was built in 2010 by the engineering team at YouTube to address scaling issues based on their incredible growth at the time. This predates AWS Aurora by four years and is used by some of the largest companies in the world, like Slack, GitHub, and Pinterest, just to name a few." (Source: Morrison, verbatim.) Historical origin datum for Vitess pre-dating Aurora.

  • Rolling MySQL upgrades — PlanetScale yes, Aurora no. "Because we use a traditional replication setup for MySQL, we can perform rolling MySQL upgrades without taking your database offline. This contrasts Aurora's approach, which requires upgrades to be performed within a maintenance window, which can lead to downtime for your database." (Source: Morrison, verbatim.) The consequence of substrate choice: traditional binlog-replicated clusters can be upgraded replica-by-replica then promote; Aurora's in-place storage substrate forces a maintenance window. Extends concepts/rolling-upgrade and concepts/mysql-version-upgrade.

  • Horizontal sharding — PlanetScale via Vitess + [[systems/ vitess-evalengine|VTGate]]; Aurora MySQL not at all. "Sharding is the practice of splitting up large datasets across multiple MySQL servers or clusters to balance the load, which leads to higher data throughput at a lower price point. Currently, Amazon Aurora does not support this capability for MySQL workloads, so you'd be required to increase the cost of your compute nodes should you start hitting performance bottlenecks. On top of that, our query proxy service known as VTGate is built with sharding in mind so it can intelligently route queries to the correct MySQL servers (or shards) even if a query needs to access the data stored on multiple shards." (Source: Morrison, verbatim.) Note: this is the 2024-01 Aurora-MySQL state; Aurora has separately offered Aurora Limitless on the Postgres side since later.

  • Automated backup validation — PlanetScale restores + replays every backup; Aurora only snapshots. "While both PlanetScale and Aurora support automated backups, we also validate the backups of our databases automatically every single time a new backup is created. This is only possible because we use the traditional approach for MySQL replication. Instead of creating a fresh snapshot of your database every time a backup is performed, we restore the most recent backup of your database to a special MySQL node in the cluster that's dedicated to this process. Once the backup is restored, we use the built-in MySQL replication to copy the latest changes into this node before creating a new backup. If a backup is unhealthy, this process will fail and a fresh backup will be triggered to take its place. By following this process, you can always be confident that backups on our platform are validated and healthy to restore from." (Source: Morrison, verbatim.) Canonical instance of automated backup validation via restore-and-replay: every backup is proven restorable because it is restored as part of the creation pipeline.

  • Both platforms can run in the customer's AWS account. "While not strictly about replication, both platforms can be run within your own AWS account. PlanetScale's enterprise plan allows you to run the PlanetScale stack directly in your account, all while allowing you to use our beloved UI." (Source: Morrison, verbatim.) Not replication-relevant but preserved as a scope-parity datum.

The two replication diagrams (verbatim step captions)

PlanetScale / traditional MySQL replication (Morrison's Table 1):

Step Description
1 Clients that need to write data connect to the source MySQL server.
2 Clients with read-only workloads can connect to one of the replicas.
3 On writes to source, transactions are relayed to replicas which will apply them locally. In semi-synchronous mode, the source can be configured to wait for one or more acknowledgments from replicas before responding to the client to ensure durability.

Aurora replication (Morrison's Table 2):

Step Description
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.
4 Read-only nodes are notified of data changes so in-memory pages can be updated.
5 Read-only nodes have read-only connections to storage segments.
6 Storage segments replicate to each other.

Canonical wiki-level disclosure of both architectures' step-by-step traffic flow.

Systems / concepts / patterns surfaced

Source

Last updated · 470 distilled / 1,213 read