RDS Read Replicas for Offloading Read Queries — MySQL Performance

Quick Answer

An RDS read replica solves this because it addresses the actual bottleneck directly: the primary database is being asked to do double duty, serving the telemetry writes it exists for while also absorbing the load of read-only reporting queries, and those two workloads are competing for the same compute and I/O resources. A read replica is a separate, continuously updated copy of the database that can accept read traffic on its own, so routing the reporting queries there removes that load from the primary entirely, letting it focus on the write path it was already handling well. This is a more targeted fix than something like resizing the primary instance, because scaling up the primary would add capacity for both workloads at a higher cost rather than isolating the one that's actually causing contention. It also doesn't require rewriting the reporting queries or restructuring the schema, only pointing that traffic at a different connection endpoint. Whenever a scenario describes a single relational database instance under strain specifically because of read-heavy secondary workloads like reporting competing with primary traffic, that split between write and read demand is the signal to reach for a read replica rather than scaling the primary instance itself.