Sharding means splitting rows across multiple database servers so no single machine holds everything. It works, and it is close to irreversible. Every subsequent feature has to respect the shard boundary, and any query spanning shards becomes an application-level join.
Before that, exhaust the cheaper options in order. Fix the queries — most databases in trouble are running a handful of pathological queries rather than genuinely exceeding capacity. Add the indexes. Move reads to replicas. Archive cold data out of the hot tables. Increase the instance size, which in cloud terms now reaches into territory that was exotic a few years ago.
If those genuinely run out, the shard key decides everything. It must be present in almost every query, distribute evenly, and never need to change. Customer or tenant ID usually satisfies all three; something like creation date satisfies none, because all new writes land on one shard.
Multi-tenant applications get a natural advantage here, since tenants rarely need to be joined and a tenant is a clean boundary. This is one of the few cases where sharding feels less like surgery. Consumer applications where users interact with each other are the hard case, because the social graph crosses every boundary you draw.
Plan for rebalancing before you need it. Shards fill unevenly, and moving a tenant from one shard to another without downtime is a project in itself. Building it while the system is small is far easier than building it under pressure.
Consider whether a distributed SQL database — CockroachDB, YugabyteDB, or a managed equivalent — solves the problem without hand-rolled sharding. They carry their own trade-offs in latency and cost, but they keep the sharding logic out of your application code, and that is the part that never goes away.
