The write ceiling
Copies scale your reads and caching absorbs them, but every write still lands on one leader, and one machine has a ceiling.
A well-tuned relational database on serious hardware tops out somewhere around 5,000 to 10,000 sustained writes a second, depending on what you are writing. Size hits a softer wall sooner. Once your data outgrows memory, reads start touching disk, and chores like backups and schema changes stretch from minutes into hours.
Sharding goes after both by splitting your rows across separate databases. Each shard runs the same schema and owns a slice of the data, decided by a shard key.
Ten shards gives you roughly ten times the writes and a tenth of the data per machine, with no machine coordinating with another on the hot path. That independence is the entire trick, and it is the entire cost. Anything spanning two shards, a join, a transaction, a uniqueness rule, no longer has a database enforcing it.
Wait as long as you can
Take the strong opinion here, which is barely an opinion. Shard as late as you possibly can.
The boring ladder comes first, and you finish it. A bigger machine, since your cloud sells ones with terabytes of memory. Caching in front of your hottest reads. Copies for read traffic. Archiving data nobody queries. Batching writes. Every rung is a config change or a small project. Sharding is a migration measured in quarters that complicates every feature you build afterwards, forever.
Start early once the arithmetic says the ceiling is genuinely coming. Teams that shard well do it with a year of headroom, on a schedule they chose.
Teams that shard during the outage that proved they needed it do not get to choose their shard key carefully. The next lesson is about why that ruins the following five years.
Worked example
Felix runs the ingest database for a fleet-tracking startup: every vehicle reports position every 5 seconds, currently 2,200 writes per second on a db.r5.2xlarge, growing 15 percent month over month. He does the arithmetic on a whiteboard: at that rate they cross 8,000 writes per second in about 9 months, right where their load tests show the instance falling over. First they climb the cheap rungs: upgrading to an r5.4xlarge and batching inserts into 100-row chunks pushes the wall out to roughly 20 months. Then, with no fire burning, they spend a quarter sharding by vehicle_id across 8 instances, migrating one customer fleet at a time. The launch is boring, which was the entire point of doing the math a year early.