Before Sharding: When One Database Is Not Enough

In this chapter

Before sharding: when one database server stops being enough

More on Scaling out

• Sharded URL Shortener: How a Request Finds Its Shard
• Database Sharding Explained: Keys, Hash Rings, MySQL & Postgres
• Shard Keys, Consistent Hashing, Rebalancing & Routing
• Sharding MySQL & PostgreSQL, Names Across Databases, Interview

Keep learning

• Previous: AI-assisted SQL analysis: from EXPLAIN to root cause
• Next: Sharded URL Shortener: How a Request Finds Its Shard
• All SQL tutorial chapters

Overview

chapters · scaling out Before sharding: when one database server stops being enough What goes wrong as one table grows, and the cheaper fixes to try first. Sharding is the last step, not the first.

1. One database, one machine

Every app starts the same way: one database server holds every table, and every read and every write goes to that one machine. That works for a long time. The trouble starts when one table (orders, messages, events) keeps growing. As the table grows, each stage forces a fix. The last fix is sharding. Table size What happens What you do 1 M rows The whole index fits in memory. Lookups take about a millisecond. 100 M rows The index outgrows memory, so some lookups read from disk and slow down. Buy a bigger server with more RAM 10 B rows Buy the biggest server there is. It is still strained The wall No bigger server exists, and one primary cannot take the writes. Split the table across several servers: sharding Until the wall, keep one server: one place to read, one transaction, one backup.

2. What breaks as it grows

Data no longer fits Tens of terabytes on one node: backups, restores and index rebuilds take hours. Too many writes Every INSERT and UPDATE goes to the one primary. Its disk and CPU are the ceiling. Index bigger than memory The hot part of the index stops fitting in RAM, so lookups hit disk and get 10–100× slower. Maintenance gets slow Schema changes, VACUUM and rebuilds touch the whole huge table at once.

3. Try these first

Sharding is the heaviest fix. Most growth problems have a cheaper one. Find which problem you actually have: slow query? fix the plan Bigger machine more CPU, RAM, faster disk Replicas + cache spread the reads smaller tables, same server data or writes outgrow one primary Does sharding fix it? Cheaper fix first Data no longer fits one machine archive old rows, compress Writes exceed one primary batch writes, fix hot rows Too many reads read replicas and a cache Too many connections One slow query an index, a better plan Sharding is for data size and write throughput. Read load has cheaper fixes.

4. Next

When the cheaper fixes run out, the table is split across servers. See it working first in the sharded URL shortener, then read how it all works in sharding, starting with how to tell, from the numbers, that you have reached the wall.

More courses

• Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
• Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
• React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
• System Design — Core concepts first (SQL vs NoSQL, CAP, indexing, replication, sharding), then designs grouped by what carries them: the database, Redis, Kafka, or many services.
• Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
• Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
• Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
• AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
• Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
• TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
• CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
• Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
• Docker — What an image is, why layers cache, and how containers find each other on a network.
• Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
• Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.