Crossing 1M rows wasn't our scaling problem. Choosing the wrong scaling strategy would have been.

When one of our Rails applications crossed 1 million records, the first suggestion was predictable:

"Let's shard the database."

It sounded like the right move.

But after analysing production traffic, we found something interesting.

Almost 85% of database requests were reads.

Writes weren't the bottleneck.

The primary database was struggling because reporting, dashboards, and APIs were all competing for the same resources.

So instead of jumping to sharding, we started with read replicas.
* Reporting queries moved to replicas
* Heavy background jobs stopped hitting the primary
* Read traffic was separated from transactional workloads

The result?
* Faster API response times
* Lower load on the primary database
* No application-level sharding complexity

Months later, as write traffic continued growing, we evaluated sharding for specific workloads, not the entire application.

That made the transition much simpler.

Important learning:
Scaling isn't about using the most advanced architecture.

It's about solving the bottleneck you actually have.

Sometimes read replicas are enough.

Sometimes sharding is necessary.

The hard part is knowing when to use each.