Database Scaling

← Previous Chapter: Part 3: Caching Strategies & Redis/Valkey | Series Hub: System Design Masterclass | Next Chapter: Part 5: Asynchronous Messaging, Kafka KRaft & Event-Driven Systems → Prerequisite: Read Part 3: Caching Strategies, Redis/Valkey & Stampede Prevention to understand how memory caching shields databases before scaling storage horizontally. Answer-first: Scaling relational databases beyond vertical hardware limits requires horizontal sharding by consistent tenant keys, managing read-replica replication lag with GTID session tracking, and migrating toward Multi-Raft distributed SQL engines. Deploying Vitess VTGate or CockroachDB eliminates the single-node storage bottleneck while preserving ACID guarantees and sub-20ms P99 commit latencies across distributed clusters. ...

MySQL Scalability & Sharding: Vitess vs TiDB (10k+ TPS) Answer-first: Scaling MySQL requires a phased architectural progression: optimizing InnoDB buffer pools (100–500 TPS), implementing ProxySQL read/write splitting (500–3,000 TPS), and migrating to horizontal sharding or TiDB Distributed SQL (3,000–10,000+ TPS). TiDB serves as the premier MySQL sharding alternative, eliminating manual application-level partitioning through stateless SQL compute nodes and Raft-replicated distributed TiKV storage. MySQL scalability is the ability to increase database throughput — reads per second, writes per second, or data volume — without rewriting your application. The critical distinction: read scaling (adding replicas) and write scaling (sharding or distributed SQL) require completely different architectural approaches. Choosing the wrong path creates technical debt that takes months to unwind. ...

Answer-first: Scaling MySQL writes beyond the 12,000 TPS single-primary InnoDB fsync ceiling mandates choosing between middleware clustering (Vitess) or application-layer routing (GORM Sharding). Vitess provides transparent SQL scatter-gather and zero-downtime VReplication resharding at the cost of operational proxy overhead, whereas GORM Sharding achieves zero-proxy microsecond execution bounds at the expense of rigid schema partitioning. When an engineering organization scales beyond millions of active transactions, a monolithic relational database instance inevitably becomes the single biggest systemic bottleneck in the entire software architecture. While read traffic can be scaled horizontally almost indefinitely by attaching read replicas behind a load-balancing proxy like ProxySQL, write traffic hits an unyielding physical ceiling on a single MySQL Primary instance. ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Scaling a relational database is one of the most demanding challenges in system design. As applications grow from thousands to millions of active users, the database ceases to be a simple storage engine and becomes the primary bottleneck of the entire system architecture. In this technical guide, we explore the architectural progression of scaling MySQL—beginning with replication topologies, stepping through the complexities and operational hazards of manual database sharding (including proxy middleware like Vitess), and evaluating NewSQL alternatives, specifically the distributed architecture of TiDB. ...