Replication Lag Calculator

Work out replication lag instantly with clear inputs, formula shown and shareable results.

About Replication Lag Calculator

Lag accumulates whenever the primary writes faster than the replica applies, and the backlog grows linearly with the deficit and burst duration. Because catch-up is also limited by apply throughput, a 20-minute burst with a 7 MB/s deficit takes minutes to clear after the burst ends — which is why replica lag alerts fire long after the write spike is over.

Formula

Replication lag

deficit = write rate - apply rate; backlog = deficit x burst duration; lag = backlog / apply rate; steady lag = network latency + one apply interval

Worked example

With the default values below, Replication Lag Calculator returns Replication lag at the end of the burst of 221.1. Change any input above and every figure here is recalculated in your browser.

Inputs used

Write throughput on the primaryminimum 0.001 MB/s: 45 MB/s
Replica apply throughputminimum 0.001 MB/s: 38 MB/s
Network round-trip latencyminimum 0 ms: 25 ms
Duration of the write burstminimum 0.1 min: 20 min

Results

Replication lag at the end of the burst: 221.1 s
Unapplied backlog: 7.82 GiB
Time to catch up after the burst: 221.1 s
Steady-state lag: 51.3 ms

Step by step

1Values used
2Replication lag
3Replication lag at the end of the burst= 221.1 s
4Unapplied backlog= 8,400,000,000
5Time to catch up after the burst= 221.1 s
6Steady-state lag= 51.3 ms

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why is single-threaded apply a problem?

The primary writes with many concurrent sessions while a naive replica replays serially, so apply throughput is a fraction of write throughput. Parallel apply by schema or by transaction dependency fixes this.

Is reading from a lagging replica safe?

Only if the application tolerates stale reads. For read-after-write consistency, route those reads to the primary or use a session-level consistency token.