Speed of copying data from PostgreSQL primary node to read-only nodes

I have created a PostgreSQL database cluster, that consists of one primary+standby database and three read-only databases (each read-only database for a specific region).

During development I’ve faced with the next issue. When I write a row into database and then immediately (but after a promise is resolved of course) read the table, then I’ve got dataset without those new row (in most cases, but sometimes the dataset contains all expected rows).

But if I put some delay (600ms, for example), then the dataset contains contains all expected rows for all cases.

My question is: Does such behavior relate to some latency that is appeared because of copying data from primary node to all read-only nodes? If so, then how many time is needed for such copying? Or maybe, if the time is floating and depends on many factors, then how is it possible to measure this latency for my case?

Thanks for the help!

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Bobby Iliev
Site Moderator
Site Moderator badge
November 23, 2023

Hi there,

The replication lag you’re experiencing is likely caused by the time it takes for changes made on the primary PostgreSQL node to be replicated to the read-only replicas. This lag is influenced by various factors, including the primary node’s workload, network latency, and the volume of data being transferred.

PostgreSQL doesn’t offer a built-in method to measure replication lag in milliseconds. However, you can approximate it by comparing transaction IDs or timestamps between the primary node and the replicas. Tools like pg_stat_replication can provide insights into the replication status and assist in monitoring the lag.

To address this in your application, consider implementing a retry mechanism or delaying the read operation to allow the replicas sufficient time to catch up with the primary node. This ensures that your application reads consistent and up-to-date data from the replicas.

Hope that this helps!



Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel