Scaling Databases: Vertical vs Horizontal

Growth is good news, until the database starts to buckle under it. Pages slow down at peak hours, CPU sits at 100 percent and the team starts debating whether to "go distributed". Database scaling covers the ways to handle more data and more traffic, and they fall into two broad families: make one server bigger (vertical), or spread the work across several servers (horizontal). Each has its place, and choosing the wrong one first can cost months. This article explains both and suggests a sensible order.

First, find out what is actually running out

"The database is slow" can mean very different things, and each points to a different fix:

• CPU-bound: queries doing heavy computation, sorting or scanning. Often a sign of missing indexes.
• Memory-bound: the frequently used data no longer fits in the cache, so reads hit disk.
• I/O-bound: storage cannot keep up with reads or writes.
• Connection-bound: too many clients trying to connect at once.
• Lock contention: many transactions waiting on the same rows.

Look at monitoring before deciding anything. An optimised query or a new index frequently delivers more than any hardware change, and it costs nothing every month afterwards.

Vertical scaling: a bigger server

Vertical scaling (scaling up) means giving the database server more CPU cores, more RAM or faster storage. On a cloud platform it can be a few clicks and a short restart.

Advantages:

• No application changes. Your queries, transactions and joins all keep working exactly as before.
• Strong consistency stays simple, because there is still one source of truth.
• Operationally simple: one server to back up, patch and monitor.

Limits:

• There is a ceiling. The largest available machine is very large, but finite.
• Cost often rises faster than capacity at the top end.
• It is still a single point of failure unless you add a standby replica.
• Resizing usually involves brief downtime or a failover.

For most small and mid-sized businesses, vertical scaling plus good indexing covers years of growth. Do not dismiss it as unsophisticated.

Horizontal scaling: more servers

Horizontal scaling (scaling out) adds machines and divides the work between them. There are several ways to do it, with very different levels of complexity.

Read replicas

Copies of the database that receive every change from the primary and serve read queries. If most of your traffic is reads, such as product pages, search and reports, replicas can absorb a large share. They do not help with write load, and they introduce replication lag: a replica may be slightly behind, so the application must send reads that need up-to-the-second data to the primary.

Caching in front of the database

Strictly, this is reducing load rather than scaling the database, but it is one of the most effective steps. An in-memory store such as Redis can hold results that are expensive to compute and change rarely: catalogue pages, configuration, session data, dashboard totals. The hard part is invalidation, making sure the cache is updated or cleared when the underlying data changes.

Partitioning

Partitioning splits one large table into smaller pieces inside the same database server, usually by date or by a key range. Queries that filter on the partition key only touch the relevant pieces, and old data can be removed by dropping a whole partition instead of deleting millions of rows.

-- PostgreSQL declarative partitioning by month
CREATE TABLE events (
    id          BIGINT GENERATED ALWAYS AS IDENTITY,
    occurred_at TIMESTAMPTZ NOT NULL,
    account_id  BIGINT NOT NULL,
    payload     JSONB
) PARTITION BY RANGE (occurred_at);

CREATE TABLE events_2024_09 PARTITION OF events
    FOR VALUES FROM ('2024-09-01') TO ('2024-10-01');
CREATE TABLE events_2024_10 PARTITION OF events
    FOR VALUES FROM ('2024-10-01') TO ('2024-11-01');

-- Dropping a month of old data is instant
DROP TABLE events_2025_09;

Partitioning keeps everything on one server, so it is not horizontal scaling in itself, but it makes large tables manageable and is often a stepping stone.

Sharding

Sharding splits the data across separate database servers, each holding a subset of rows. A SaaS product might put customers 1 to 10,000 on shard A and 10,001 to 20,000 on shard B. This is the only approach here that scales writes almost without limit, and it is also by far the most complex:

• Choosing the shard key is critical and hard to change later. A poor key creates "hot" shards that take most of the traffic.
• Queries that span shards, such as a report across all customers, must be run on every shard and combined.
• Transactions across shards are difficult and slow.
• Rebalancing when one shard fills up requires moving data while the system is live.
• Backups, schema migrations and monitoring all multiply.

Tools such as Vitess for MySQL and Citus for PostgreSQL handle much of this complexity, and distributed SQL databases build it in, but the design constraints remain.

A comparison

A sensible order for database scaling

1. Fix slow queries and indexes.
2. Scale vertically while it remains cost-effective.
3. Add caching for hot, rarely changing data.
4. Add read replicas for read-heavy and reporting workloads.
5. Partition very large tables, especially time-based ones.
6. Archive data you no longer need online.
7. Consider sharding only when write volume or data size truly exceeds what one primary can handle.

Planning for scale is easier before it becomes urgent. Our database management and cloud solutions teams can assess where your current setup will hit its limits.

Key takeaways

• Diagnose the bottleneck before choosing a database scaling approach.
• Vertical scaling is simple, needs no code changes and is often enough.
• Replicas and caching scale reads; only sharding truly scales writes across servers.
• Sharding brings lasting complexity, so treat it as the last step, not the first.