Database sharding can solve a scaling problem. It can also create five new ones.

A growing Rails application doesn't need sharding just because its database has millions of records.

We've seen applications handle millions of records quite comfortably with a well-designed PostgreSQL database.

The real challenge starts when:
- Write traffic is consistently overwhelming the primary database.
- Database resources remain saturated despite optimisation.
- Tenant workloads are competing with each other.
- Vertical scaling is becoming too expensive.
- Read replicas are no longer enough to handle the workload.

That's when sharding becomes worth evaluating.

For a multi-tenant SaaS, one approach is to distribute tenants across multiple databases.

Tenant A → Shard 1
Tenant B → Shard 2
Tenant C → Shard 3

Each database handles a portion of the overall workload.

But the trade-offs are significant.

Cross-shard reporting becomes harder.

Transactions across databases need careful design.

Tenant migration becomes more complicated.

Monitoring, backups and recovery need to work across multiple databases.

And uneven tenant activity can still create hotspots on individual shards.

So before introducing sharding, I'd ask:
Have we exhausted simpler options?

Index optimisation, query improvements, read replicas, connection pooling and workload separation should be evaluated first.

Important learning:
Sharding isn't the next step after adding a read replica.

It's a major architectural decision that changes how your Rails application stores, retrieves and manages data.

Don't distribute your database complexity before you actually need to distribute your database workload.