A well-tuned single MySQL instance on decent hardware handles more load than most teams expect — a lot of database scaling problems are actually query and index problems in disguise, and no amount of clustering fixes a missing index or an N+1 query pattern.
Signs it's an application problem, not a scaling problem
Slow queries that get slower as data grows, high CPU usage from a handful of specific query patterns, and lock contention from long-running transactions are all things a slow query log and an index review typically fix, without needing to touch your infrastructure at all.
When you actually need to scale out
Once you've genuinely optimized what's optimizable and you're still hitting the ceiling of a single instance — either on read capacity or on availability requirements — that's when replication and connection routing become worth the added operational complexity.
What ProxySQL adds
ProxySQL sits between your application and your MySQL servers, routing read traffic to replicas and write traffic to your primary, without your application needing to know which server is which. It also handles connection pooling, which matters a lot for applications that open a lot of short-lived database connections, and query caching for repeated read queries.
Replication topology matters
A simple primary-replica setup handles read scaling and gives you a failover target, but doesn't protect you from every failure mode. Depending on your availability requirements, a more resilient topology (multiple replicas, automated failover detection) may be worth the additional complexity — but it's not something to add by default before you actually need it.
Don't skip the backup story
Clustering for performance and availability is separate from having a tested backup and restore process. A cluster with no verified restore procedure is still one bad migration away from real data loss — scaling and disaster recovery are both necessary, and neither substitutes for the other.