Diagnosing Amazon RDS Read Replica Lag: Causes and Fixes

RDS read replica lag has four common causes — big primary transactions, an undersized replica, competing reads, or network latency. Here's how to tell them apart and fix each.

Your read replica is serving stale data, and CloudWatch shows ReplicaLag climbing. The useful takeaway: replica lag on RDS is almost always one of four things — a long-running write transaction on the primary, an undersized replica, competing read traffic on the replica, or a network/cross-region path problem — and each has a distinct signature you can check in minutes.

This guide assumes RDS for PostgreSQL or MySQL with a same-region or cross-region read replica, monitored through CloudWatch. Commands run from any host with network access to the databases and the psql client installed; AWS CLI commands require an IAM identity with rds:DescribeDBInstances and cloudwatch:GetMetricStatistics.

Recognize the condition

Lag shows up as the ReplicaLag CloudWatch metric (seconds behind the primary) rising above your application's tolerance — often first noticed as users seeing stale reads right after a write. A brief spike after a bulk load is normal; sustained growth over tens of minutes is not.

Cause and diagnostic table

Symptom pattern	Likely cause	First check
Lag jumps during a batch job, then recovers	Large uncommitted transaction on the primary	Look for long-running transactions on the primary
Lag grows steadily; replica CPU or I/O saturated	Replica instance too small to apply changes	CloudWatch CPUUtilization, ReadIOPS/WriteIOPS on the replica
Lag correlates with heavy reporting queries	Read workload competing with replication apply	DatabaseConnections and active sessions on the replica
Baseline lag never reaches zero	Cross-region network latency	Confirm replica region; measure RTT
Replication stalled entirely after a change	Engine version or parameter group mismatch	Compare engine versions and parameter groups

Ordered checks

Confirm real lag, not metric noise. On the PostgreSQL replica, run:
```
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(),
       now() - pg_last_xact_replay_timestamp() AS replay_delay;
```
Compare the LSNs against the primary's pg_current_wal_lsn(). If receive is current but replay is behind, the bottleneck is applying changes on the replica. If receive itself is behind, suspect the network or the primary.
Check replica resources. In CloudWatch, look at CPUUtilization, FreeableMemory, and IOPS for the replica instance. Sustained CPU near 100% or IOPS pinned at the volume limit means the replica cannot keep up with apply work.
Look for competing reads. On the replica, list active sessions:
```
SELECT pid, state, wait_event_type, query_start, left(query,80)
FROM pg_stat_activity WHERE state = 'active';
```
Long analytical queries running while lag climbs are a strong signal the read workload is starving replication.
Check the primary for large transactions. On the primary, find transactions open for a long time:
```
SELECT pid, now() - xact_start AS age, left(query,80)
FROM pg_stat_activity
WHERE xact_start IS NOT NULL ORDER BY age DESC;
```
A multi-hour batch update produces a change backlog the replica must replay serially.
Verify configuration parity. Confirm the replica's engine version and parameter group match the primary's. Mismatches after an in-place upgrade of only one instance can stall replication. Also check the RDS event log for the replica (aws rds describe-events --source-identifier <replica-id>) for explicit replication errors.

Fixes tied to findings

Large primary transactions: break batch jobs into smaller committed chunks (e.g., update in batches of a few thousand rows with a commit between). This caps the replay backlog per transaction.
Undersized replica: scale the replica instance class up to at least match the primary. Note this requires a reboot during which replication pauses and lag temporarily grows — schedule it during low traffic.
Competing reads: move reporting queries to a second dedicated replica, or throttle them. For PostgreSQL, be aware that hot_standby_feedback and long replica queries can also cause vacuum delays on the primary.
Cross-region baseline lag: accept a nonzero floor and alert on rate of change rather than absolute lag, or move the replica into the primary's region if staleness is unacceptable.
Version/parameter mismatch: align engine versions and parameter groups, then monitor the event log to confirm replication resumes.

Escalation criteria

Escalate to AWS Support when: ReplicaLag grows for more than an hour with the replica's CPU and I/O well below limits; the RDS event log shows repeated replication errors you cannot map to a configuration cause; or LSN positions on the replica stop advancing entirely. Gather the replica's event log output, CloudWatch metric screenshots, and the LSN comparison before opening the case — support will ask for exactly these.

Verify the fix

After any change, watch ReplicaLag trend back toward its baseline and re-run the LSN comparison on the replica to confirm replay is advancing. Set a CloudWatch alarm on ReplicaLag at a threshold slightly above your normal baseline so the next incident is caught before users notice stale data.

Diagnosing Amazon RDS Read Replica Lag: Causes, Checks, and Fixes