Database Scaling: Sharding, Partitioning, and Replication

(Image generated by AI)

The Day the Database Died

You launched your app. It went viral. Thousands of users are signing up, posting comments, and uploading data. You check your server metrics and your single PostgreSQL database is running at 100% CPU. Queries that used to take 10 milliseconds are now taking 5 seconds.

You need to scale. But how do you scale a database? You can’t just spin up a second database and expect them to magically know about each other.

Let’s look at the three primary strategies for scaling databases.

1. Vertical Scaling (Scaling Up)

Before doing anything complex, the easiest solution is Vertical Scaling. You simply go into your AWS or cloud provider dashboard and buy a much bigger server.

You upgrade from a machine with 4GB of RAM to a massive machine with 256GB of RAM and 64 CPU cores.

The Problem: Hardware has limits. Eventually, you will buy the biggest, most expensive server on the planet, and it still won’t be enough. You hit a ceiling. This is when you must move to Horizontal Scaling (Scaling Out—adding more servers).

2. Replication (Leader-Follower)

In a typical web application, the ratio of “Reads” (viewing a profile, loading a feed) to “Writes” (creating a post, updating a password) is often 100 to 1.

If your database is overwhelmed by “Reads,” you can use Replication.

How it works:

1. You designate your original database as the Leader (or Master).
2. You spin up two new databases called Followers (or Slaves).
3. Every time your application Writes data (INSERT, UPDATE, DELETE), it only writes to the Leader.
4. The Leader instantly copies (replicates) that new data to the Followers.
5. Every time your application Reads data (SELECT), it queries the Followers.

Because you have multiple Followers, you have distributed the reading workload across multiple servers!

From-Scratch Example: Application Logic Routing

Here is how your application code has to change to support this:

public class DatabaseRouter {
    
    private DBConnection leaderDb = new DBConnection("postgres://leader-ip:5432");
    private DBConnection[] followerDbs = {
        new DBConnection("postgres://follower-1-ip:5432"),
        new DBConnection("postgres://follower-2-ip:5432")
    };

    // All Writes go to the Leader!
    public void createNewUser(String name, String email) {
        leaderDb.execute("INSERT INTO users (name, email) VALUES ('" + name + "', '" + email + "')");
    }

    // Reads go to a random Follower to balance the load!
    public User getUser(String userId) {
        int randomIndex = Math.abs(new Random().nextInt()) % followerDbs.length;
        return followerDbs[randomIndex].query("SELECT * FROM users WHERE id = " + userId);
    }
}

3. Sharding & Partitioning

What happens if your database isn’t overwhelmed by Reads, but is overwhelmed by Writes? Replication won’t help you, because all Writes still have to go to the single Leader database. Furthermore, what if your database grows to 10 Terabytes and physically cannot fit on one hard drive?

You need Sharding (Horizontal Partitioning).

Sharding means taking one massive table and breaking it into smaller chunks, spreading those chunks across entirely different servers.

How it works: Imagine you have a Users table with 100 million rows.

• Server A (Shard 1) holds all users with IDs from 1 to 50,000,000.
• Server B (Shard 2) holds all users with IDs from 50,000,001 to 100,000,000.

When your application needs to look up User 75,000,000, your code calculates the routing logic and explicitly queries Server B.

The Pain of Sharding

Sharding is notoriously difficult to maintain.

• The Celebrity Problem (Hotspots): What if you partition by User location, and suddenly your “North America” shard gets 100x more traffic than your “Antarctica” shard? One server crashes while the other does nothing.
• Joins are broken: You cannot easily run a SQL JOIN command if the Users table is on Server A, but the Orders table is on Server B.

Summary

When your DB struggles:

1. Scale Up: Buy a bigger server.
2. Replication: Add read-only servers to handle heavy Read traffic.
3. Sharding: Break the data across multiple servers to handle massive Write traffic and storage limits (but prepare for headaches).