# Managing 768 Servers as a Single Database A guide to database sharding for large-scale applications. - **Source:** [Hacker News: Front Page](https://brifing.si/source/b07aa772-b1a0-4a76-aa18-719c6f9e2dde) - **Published:** 2026-07-16 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/4a8e79bf-cce7-49f3-a835-285fbd47ed55 ## The Core Challenge of Large-Scale Systems Applications serving millions of users must process millions of queries per second. Traditional single-server database architectures cannot handle this load. Performance bottlenecks become inevitable, especially when data exceeds several terabytes. ## Limits of a Single Server Even powerful database servers with dozens of CPU cores and hundreds of GB RAM collapse under high query volume. As Universal Scalability Law shows, resource contention prevents linear performance scaling. CPU and I/O constraints quickly emerge. ## Read Replicas: A Partial Solution Read replicas distribute read queries while keeping writes on a single server. Companies like OpenAI use up to 50 replicas. However, this approach fails for write-heavy systems and doesn't increase data capacity. ## 3 Major Problems of Monolithic Databases 1) All writes bottleneck at one server. 2) Replicas don't increase data capacity. 3) Backing up large databases can take days. These issues can't be solved with traditional approaches. ## Sharding: Splitting Data into Pieces Sharding divides data into logical partitions (shards) distributed across servers. Each shard has its own primary and replicas. 2TB data might need 4 shards, while 1PB could require 256 shards. ## 768-Server Example Architecture For 1PB data: 256 shards (each 4TB) with 2 replicas per shard totals 768 servers. Each shard handles ~1/256 of queries. This distribution parallelizes write operations too. ## Transparency for Application Layer Key question: How can app servers see this complex infrastructure as one database? Proxy layers and smart routers automatically determine which shard should process each query. ## Cross-Shard Queries Queries needing data from multiple shards are merged at middleware. For example, if users are on one shard and orders on another, JOIN operations are coordinated. ## Backup and Monitoring Each shard can be backed up independently, making full system backups take minutes instead of hours. Central monitoring tools track all shards' health in real-time. ## Fault Tolerance If a shard server fails, replicas take over instantly. WAL (Write-Ahead Log) mechanisms prevent data loss. Automated failover systems operate without human intervention. ## Costs of Sharding Ensuring ACID guarantees for distributed transactions is harder. Application logic must be shard-aware. But at scale, this complexity is offset by performance gains. ## Future Database Architectures Postgres and MySQL sharding became foundational for modern cloud apps. AI-powered automatic sharding management and serverless database technologies are shaping this field's future. ## Sources covering this story - https://planetscale.com/blog/making-768-servers-look-like-1 — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._