Scaling Databases

Introduction

When one DB box isn't enough, scale via vertical (bigger box), read replicas (copies for reads), sharding (split by key), and caching.

Understanding the topic

Core concepts to understand:

• Vertical: CPU, RAM, NVMe — easy, expensive, finite.
• Read replicas: route SELECTs to copies.
• Sharding: split by user_id, region, or tenant.
• Caching: cuts read load before it hits the DB.
• Distributed SQL: CockroachDB, Spanner, Yugabyte.

Syntax reference

Visual workflow / architecture:

   App
    │
    ├── primary  (writes)
    ├── replica1 (reads)
    ├── replica2 (reads)
    └── shard 0..N (huge tables)

Real-world use

GitHub: MySQL primary + many replicas + Vitess sharding. Stripe: Postgres + custom sharding. Both scale to massive workloads on commodity hardware.

Best practices

• Vertical scale first — simplest.
• Read replicas next.
• Shard last — operationally heavy.

Hands-on exercise

Interview preparation — practice these questions:

• Q1. Vertical vs horizontal scale.
• Q2. Read replica trade-offs (lag).
• Q3. Sharding strategies.
• Q4. Distributed SQL — what is it?
• Q5. When to use a separate analytics warehouse.