Database Sharding: When It's Actually Necessary (And When It Isn't)
Sharding gets proposed far more often than it's needed. A fintech client came to us convinced their Postgres database needed sharding because query latency had crept up — their transactions table had grown to 2 million rows and dashboard queries were taking 4-6 seconds. We profiled first instead of sharding first, which is almost always the right order.
The actual problem was a missing composite index on (account_id, created_at) and a handful of N+1 queries in their reporting service. Adding the index and batching the queries brought dashboard load times down to under 200ms. Sharding would have solved nothing here and added enormous operational complexity: cross-shard joins, rebalancing, and application-layer routing logic none of their two backend engineers had built before.
We do reach for sharding, but only once we've exhausted vertical scaling, read replicas, and caching, and the bottleneck is specifically write throughput on a single primary. For a logistics client doing around 3,000 writes per second on a tracking-events table, we sharded by warehouse_id, since queries almost always filtered by warehouse and cross-shard queries were rare enough to handle at the application layer.
The real cost of sharding isn't the initial split — it's every feature built afterward. Reporting that needs to aggregate across all warehouses now requires a fan-out query or a separate analytics pipeline; a warehouse that outgrows its shard needs a resharding plan. We underestimated this the first time we sharded a client's database and ended up building a lightweight query router earlier than planned because ad hoc cross-shard queries kept appearing in feature requests.
Our rule: reach for read replicas and caching first, reach for partitioning within a single database second (Postgres native partitioning handled a time-series table for another client without ever needing true sharding), and only shard across separate database instances when write volume alone is the constraint. Most products never hit that ceiling.
