MySQL: Architecture, Scaling, and Production Deployment

Traditional MySQL, even with InnoDB Cluster, was designed for a world of physical servers and on-premises data centers. While it can run in the cloud, it doesn't fully leverage what cloud infrastructure offers: elastic storage, distributed computing, and pay-as-you-go economics.

Cloud-native MySQL offerings rearchitect the database from the ground up to exploit these capabilities. They maintain MySQL compatibility at the SQL layer while introducing fundamentally different storage and replication architectures underneath.

This page examines two transformative approaches:

Amazon Aurora MySQL — AWS's reimplementation of MySQL with distributed storage, delivering up to 5x traditional MySQL performance while maintaining full compatibility.

PlanetScale — A serverless MySQL platform built on Vitess (the technology that powers YouTube's database layer), offering horizontal scaling, non-blocking schema changes, and branching workflows.

Both represent the cutting edge of MySQL in the cloud—understanding their architectures and trade-offs is essential for modern system design.

Amazon Aurora MySQL, launched in 2014, rethinks how MySQL storage works. Rather than a single InnoDB tablespace on local disks, Aurora separates compute from storage—the MySQL engine runs on EC2 instances while data lives in a purpose-built, distributed storage layer.

Aurora's Key Innovation: Log-Based Storage

In traditional MySQL, writes follow this path:

1. Write to redo log
2. Write to buffer pool (memory)
3. Checkpoint dirty pages to tablespace files
4. For replication: write to binlog, send to replicas

Aurora eliminates steps 3 and 4 at the compute layer. Instead:

1. Write to redo log
2. Send redo log to distributed storage (6 copies across 3 AZs)
3. Storage layer applies logs to generate data pages

┌─────────────────────────────────────────────────────────────┐
│                  Aurora MySQL Architecture                   │
│                                                              │
│   ┌─────────────────────────────────────────────────────┐   │
│   │              Compute Layer (MySQL)                   │   │
│   │                                                      │   │
│   │   ┌──────────────┐    ┌──────────────┐              │   │
│   │   │   Primary    │    │   Replica    │  ...more     │   │
│   │   │   (R/W)      │    │   (R/O)      │  replicas    │   │
│   │   └──────┬───────┘    └──────┬───────┘              │   │
│   │          │                    │                      │   │
│   └──────────┼────────────────────┼──────────────────────┘   │
│              │ (redo logs only)   │ (read from cache/storage)│
│   ┌──────────▼────────────────────▼──────────────────────┐   │
│   │              Distributed Storage Layer               │   │
│   │                                                      │   │
│   │   ┌─────────┐ ┌─────────┐ ┌─────────┐               │   │
│   │   │  AZ-1   │ │  AZ-2   │ │  AZ-3   │               │   │
│   │   │ ○ ○     │ │ ○ ○     │ │ ○ ○     │               │   │
│   │   └─────────┘ └─────────┘ └─────────┘               │   │
│   │   6 copies of data across 3 Availability Zones      │   │
│   │   Quorum writes (4/6), Quorum reads (3/6)           │   │
│   └──────────────────────────────────────────────────────┘   │
│                                                              │
│   * Primary sends only redo logs (not full pages)           │
│   * Storage applies logs and serves read requests           │
│   * Replicas share the same storage (no replication lag!)   │
└─────────────────────────────────────────────────────────────┘

Beyond its distributed storage, Aurora offers several unique features that differentiate it from standard MySQL.

Aurora Read Replicas:

Aurora supports up to 15 read replicas, all sharing the same storage. Unlike traditional MySQL replicas, there's no replication lag at the storage level—replicas see writes as soon as they're committed to storage (sub-100ms cache coherence lag).

Aurora Serverless v2:

Aurora Serverless v2 automatically scales compute capacity based on demand. Unlike provisioned Aurora (fixed instance sizes), Serverless v2 scales in increments of 0.5 ACUs (Aurora Capacity Units) from 0.5 to 128 ACUs.

Aurora Global Database:

For multi-region deployments, Aurora Global Database replicates an Aurora cluster across regions with sub-second replication lag. A primary region handles writes; secondary regions provide local reads and can be promoted for disaster recovery.

Other Aurora Features:

AWS claims Aurora delivers up to 5x the performance of standard MySQL. This claim is nuanced—let's understand when it's true and when it isn't.

When Aurora Is Significantly Faster:

When Aurora and RDS MySQL Perform Similarly:

Aurora Pricing Model:

Aurora pricing is more complex than RDS MySQL. You pay for multiple components:

Cost Comparison Example:

For a production database:

• 1TB storage, 50 million I/Os/day
• db.r6g.xlarge primary + 2 read replicas

RDS MySQL (Multi-AZ):

• Primary: ~$500/month
• Replicas (2): ~$1,000/month
• Storage (1TB, provisioned IOPS): ~$250/month
• Total: ~$1,750/month

Aurora MySQL:

• Primary: ~$350/month
• Replicas (2): ~$700/month
• Storage (1TB): ~$100/month
• I/Os (1.5B/month): ~$300/month
• Total: ~$1,450/month

Note: These are rough estimates. Actual costs vary by region, instance type, and usage patterns.

PlanetScale takes a fundamentally different approach to cloud MySQL. Built on Vitess—the open-source database clustering system originally developed at YouTube—PlanetScale provides horizontal scaling through sharding while presenting a unified MySQL interface.

The Vitess Foundation:

Vitess was created at YouTube in 2010 to scale MySQL for video metadata. When you watch a YouTube video, Vitess is serving the data. It's been battle-tested at massive scale.

PlanetScale Architecture:

┌─────────────────────────────────────────────────────────────┐
│                   PlanetScale Architecture                   │
│                                                              │
│   ┌─────────────────────────────────────────────────────┐   │
│   │                    Application                       │   │
│   └─────────────────────────┬───────────────────────────┘   │
│                             │                                │
│   ┌─────────────────────────▼───────────────────────────┐   │
│   │                    VTGate                            │   │
│   │    (Query routing, connection pooling, query         │   │
│   │     parsing, shard selection)                        │   │
│   └─────────────────────────┬───────────────────────────┘   │
│                             │                                │
│   ┌─────────────┬───────────┴───────────┬───────────────┐   │
│   │    Shard 1  │      Shard 2         │    Shard N    │   │
│   │   ┌─────┐   │     ┌─────┐          │   ┌─────┐     │   │
│   │   │MySQL│   │     │MySQL│          │   │MySQL│     │   │
│   │   │+VTT │   │     │+VTT │          │   │+VTT │     │   │
│   │   └─────┘   │     └─────┘          │   └─────┘     │   │
│   │   Primary   │     Primary          │   Primary     │   │
│   │   +Replicas │     +Replicas        │   +Replicas   │   │
│   └─────────────┴──────────────────────┴───────────────┘   │
│                                                              │
│   VTGate: Stateless query router                            │
│   VTTablet (VTT): Per-shard agent managing MySQL            │
│   Each shard: Independent MySQL with its own replicas       │
└─────────────────────────────────────────────────────────────┘

How Sharding Works in PlanetScale:

PlanetScale can shard tables based on a sharding key (vindex). Queries that include the sharding key route to a single shard; queries without it scatter to all shards.

-- Table sharded by user_id
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT,
  product_id BIGINT,
  amount DECIMAL(10,2),
  created_at TIMESTAMP
);

-- This query goes to one shard (user_id is sharding key)
SELECT * FROM orders WHERE user_id = 12345;

-- This query scatters to ALL shards (no sharding key)
SELECT * FROM orders WHERE product_id = 999;

-- Scatter queries work but are less efficient

PlanetScale differentiates itself through developer experience features that modernize database workflows.

Database Branching:

PlanetScale introduces Git-like branching for databases. Create a branch, make schema changes, test, then merge back to production—all without taking the database offline.

Non-Blocking Schema Changes:

PlanetScale implements online, non-blocking schema changes using a tool called gh-ost (GitHub Online Schema Transformation) under the hood. Unlike ALTER TABLE which can lock tables for hours on large datasets, PlanetScale schema changes:

Safe Migrations (No Foreign Keys):

PlanetScale notably does not support foreign key constraints. This is a deliberate decision for scalability:

Other PlanetScale Features:

Aurora and PlanetScale represent different philosophies for scaling MySQL in the cloud. Let's compare them across key dimensions.

Architectural Philosophy:

Feature Comparison:

Operational Comparison:

Aurora and PlanetScale aren't the only options. Let's briefly cover other significant cloud MySQL offerings.

Google Cloud SQL for MySQL:

Azure Database for MySQL:

Vitess (Self-Managed):

If you want PlanetScale's sharding capabilities but prefer self-hosting:

We've explored how cloud-native MySQL offerings reimagine database architecture for modern infrastructure. Let's consolidate the key takeaways:

What's Next:

Now that we've explored MySQL's architecture, replication, comparisons, and cloud offerings, we'll synthesize this knowledge into practical guidance for when to choose MySQL. We'll examine use cases, anti-patterns, and decision frameworks for MySQL selection in real-world systems.