Database Scaling: Vertical and Horizontal

As your application grows, the volume of data and the number of concurrent users will inevitably increase. If your database cannot handle this load, your application will suffer from latency, timeouts, and potential downtime. Database scaling is the process of adjusting your database infrastructure to meet these changing demands.

This lesson explores the two primary strategies for scaling relational databases: Vertical Scaling and Horizontal Scaling.

1. Vertical Scaling (Scaling Up)

Vertical scaling, often called "scaling up," involves increasing the capacity of a single existing server. You achieve this by adding more power to the machine—typically by upgrading the CPU, increasing RAM, or adding faster SSD storage.

How it Works

Think of vertical scaling as upgrading a computer. If your database is running on a server with 8GB of RAM and you start hitting memory limits, you swap that server for one with 64GB of RAM.

Practical Example

Imagine an e-commerce platform running on a single PostgreSQL instance. During a flash sale, the CPU usage hits 100% because of complex JOIN queries.

• The Action: You migrate the database from a db.m5.large instance (2 vCPUs, 8GB RAM) to a db.m5.4xlarge instance (16 vCPUs, 64GB RAM).
• The Result: The queries execute faster, and the system handles the spike without needing to change your application code.

💡 Key Insight

Vertical scaling is generally the "path of least resistance." It requires no changes to your application logic, database schema, or connection strings.

2. Horizontal Scaling (Scaling Out)

Horizontal scaling, or "scaling out," involves adding more servers to your database architecture. Instead of making one server bigger, you distribute the data and the workload across a cluster of multiple smaller servers.

How it Works

In relational databases (RDBMS), horizontal scaling is typically achieved through Read Replicas or Sharding.

A. Read Replicas

You maintain one "Primary" node for write operations (INSERT, UPDATE, DELETE) and multiple "Replica" nodes for read operations (SELECT).

Code Example (Application Logic): Many modern ORMs allow you to configure separate connection strings for read and write operations:

# Pseudo-code for a database connection manager
DATABASE_CONFIG = {
    "write_node": "primary-db-cluster.aws.com",
    "read_nodes": [
        "replica-1.aws.com",
        "replica-2.aws.com"
    ]
}

def get_db_connection(query_type):
    if query_type == "READ":
        # Load balance between replicas
        return connect(random.choice(DATABASE_CONFIG["read_nodes"]))
    else:
        return connect(DATABASE_CONFIG["write_node"])

B. Sharding

Sharding involves partitioning your data across multiple database instances. For example, users with IDs 1–1,000,000 might live on DB_Shard_A, while users 1,000,001–2,000,000 live on DB_Shard_B.

Comparison Table

Best Practices

1. Start Vertical, Scale Horizontal: Always start by scaling vertically. It is cheaper in terms of engineering time. Only move to horizontal scaling when you hit the physical limits of a single machine or when your budget for high-end hardware becomes unsustainable.
2. Optimize Queries First: Before spending money on hardware, ensure your database is optimized. Check for missing indexes, N+1 query problems, and inefficient table scans. Hardware cannot fix bad code.
3. Implement Read/Write Splitting: If your application is read-heavy (like a news site or a blog), implementing read replicas provides the best return on investment for scaling.
4. Monitor Everything: Use tools like Prometheus, Grafana, or cloud-native monitoring (e.g., AWS CloudWatch) to track CPU, RAM, IOPS, and connection counts. Scaling should be a proactive decision, not a reactive one.

Common Pitfalls

• Ignoring the "Write Bottleneck": Adding 10 read replicas will help with read-heavy traffic, but it will do nothing to help if your primary database is struggling with too many writes. You must address write performance through sharding or database partitioning.
• Data Consistency Issues: In a distributed setup, read replicas are often "eventually consistent." If you update a record and immediately try to read it from a replica, you might get stale data. Ensure your application logic can handle this delay.
• Over-engineering: Don't implement sharding unless you absolutely have to. It introduces significant complexity to your application, complicates backups, and makes cross-shard joins nearly impossible.

Key Takeaways

• Vertical Scaling is upgrading the hardware of a single node. It is simple but limited by the maximum capacity of the hardware.
• Horizontal Scaling is adding more nodes to the cluster. It is complex to implement but allows for massive, near-infinite scale.
• Read Replicas are the most common first step for horizontal scaling in relational databases.
• Database optimization (indexing, query tuning) should always precede hardware scaling.
• Sharding is a powerful tool for scaling writes but should be considered a last resort due to the architectural complexity it introduces.