Vertical vs horizontal scaling for databases

Two Ways to Scale

As a database grows, it needs more resources. You have two approaches, and your schema design affects which one works for you.

Vertical Scaling

Add more CPU, RAM, or faster disks to a single server. Simple — no schema changes required. Hard limit: you eventually hit the biggest machine available. Expensive at high end. Works well up to a few hundred million rows with good indexing.

Horizontal Scaling

Add more machines. For reads, this means read replicas: copies of the primary database that handle SELECT queries. The primary handles all writes; replicas handle reads.

-- Application-level read/write split (pseudo-code)
const writeDB = connect(PRIMARY_DB_URL);
const readDB  = connect(REPLICA_DB_URL);

// writes go to primary
await writeDB.query('INSERT INTO orders ...');

// reads go to replica
const orders = await readDB.query('SELECT * FROM orders WHERE ...');

Schema Design Impact

• Schemas with wide, unnormalized tables are harder to shard because rows carry duplicated data that becomes inconsistent across shards.
• Schemas with clear ownership (each entity belongs to one logical shard key like user_id) distribute cleanly.
• Avoid cross-shard JOINs — they are slow or impossible depending on the sharding system.