Database Scalability

We can scale databases in two ways

1. Vertical Scaling
2. Horizontal Scaling

Vertical Scaling

In vertical scaling we can provision more disks, processors and memory, this is a very classic way to scale a database but it has a upper limit which is dependent on the technology

we can improve the read speeds by implementing read only databases for the read stuff and have a powerful server to process the write requests

Master Slave Replication

+−⟲

Link to original

There are also multi master systems just like above to improve write throughput

Horizontal Scaling

Horizontal scaling distributes data across multiple servers (nodes) rather than making a single server more powerful. This is the primary scaling strategy for Distributed Databases and NoSQL Databases.

Replication

Maintaining copies of data across multiple nodes:

• Primary-Replica (Master-Slave) — One node handles writes, replicas handle reads. Improves read throughput. See diagram above.
• Multi-Master — Multiple nodes accept writes. Requires conflict resolution. Higher write throughput but more complex.
• Synchronous — Replica confirms write before primary acknowledges client. Strong consistency, higher latency.
• Asynchronous — Primary acknowledges immediately, replica catches up later. Lower latency, risk of stale reads.

Partitioning and Sharding

Split data across nodes so each handles a subset:

• Partitioning — Split within a single DBMS instance (range, hash, list)
• Sharding — Split across independent database servers

Caching

Reduce database load by serving frequent reads from memory:

• Application-level — Redis, Memcached sitting between application and database
• Query cache — DBMS-level caching of query results
• Materialized views — Pre-computed query results stored on disk

Load Balancing

Distribute queries across multiple database replicas:

graph TD
    Client[Application] --> LB[Load Balancer]
    LB --> Primary[(Primary - Writes)]
    LB --> R1[(Replica 1 - Reads)]
    LB --> R2[(Replica 2 - Reads)]
    Primary --> R1
    Primary --> R2

Scaling Strategy Decision

Strategy	Improves	Trade-off
Vertical scaling	Everything	Hardware ceiling, single point of failure
Read replicas	Read throughput	Replication lag, write bottleneck remains
Sharding	Write + Read throughput	Cross-shard joins, complex operations
Caching	Read latency	Stale data, cache invalidation complexity
Distributed DB	Everything	CAP Theorem trade-offs, operational complexity