PostgreSQL Replication Config Generator

Fill in your primary and standby details and get a complete PostgreSQL replication setup: the postgresql.conf changes, the pg_hba.conf line, the replication role and slot SQL, the pg_basebackup command, and the queries you need to confirm replication is actually working. Covers both streaming (physical) replication and logical replication for PostgreSQL 13 through 18. Everything is generated in your browser — no credentials are sent anywhere.

Replication modePostgreSQL versionAuth method

Primary hostStandby hostPort

Replication userPasswordSlot name

application_nameStandby countCommit mode

WAL archivingArchive directory

Primary postgresql.conf

# postgresql.conf on the primary (10.0.0.10)
listen_addresses = '*'
port = 5432
wal_level = replica
max_wal_senders = 4
max_replication_slots = 4
wal_keep_size = 512MB
hot_standby = on
synchronous_commit = on
# synchronous_standby_names left empty = asynchronous replication
archive_mode = on
archive_command = 'test ! -f /var/lib/postgresql/wal_archive/%f && cp %p /var/lib/postgresql/wal_archive/%f'
# Reload with: SELECT pg_reload_conf();
# wal_level, max_wal_senders and archive_mode need a full restart.

pg_hba.conf

# pg_hba.conf on the primary — put this ABOVE any broader "host all all" rule
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replicator      10.0.0.11/32            scram-sha-256
# Physical replication uses the special "replication" pseudo-database.
# Then run: SELECT pg_reload_conf();

Role & slot SQL

-- Run on the primary as a superuser
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'change_me';

-- Create the physical slot so the primary keeps WAL while the standby is offline
SELECT pg_create_physical_replication_slot('standby1_slot');

Clone the standby with pg_basebackup

# Run on the standby (10.0.0.11) as the postgres user, with an EMPTY data directory
sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/17/main/*
sudo -u postgres PGPASSWORD='change_me' \
  pg_basebackup \
    --host=10.0.0.10 \
    --port=5432 \
    --username=replicator \
    --pgdata=/var/lib/postgresql/17/main \
    --wal-method=stream \
    --checkpoint=fast \
    --slot=standby1_slot \
    --write-recovery-conf \
    --progress
# --write-recovery-conf writes primary_conninfo into postgresql.auto.conf
# and creates the standby.signal file that puts the server into recovery.
sudo systemctl start postgresql

Standby postgresql.conf

# postgresql.conf (or postgresql.auto.conf) on the standby (10.0.0.11)
hot_standby = on
primary_conninfo = 'host=10.0.0.10 port=5432 user=replicator password=change_me application_name=standby1'
primary_slot_name = 'standby1_slot'
restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
hot_standby_feedback = on   # avoids query cancellations from vacuum on the primary
# The standby.signal file must exist in /var/lib/postgresql/17/main
# (pg_basebackup --write-recovery-conf creates it for you).

Verification queries

-- On the primary: one row per connected standby
SELECT application_name, state, sync_state,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;

-- On the standby: should return true
SELECT pg_is_in_recovery();

-- How stale is the standby, in seconds?
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;

-- Watch for slots that are retaining WAL with no consumer
SELECT slot_name, active, wal_status,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots;

Parameter names follow PostgreSQL 12 and later, where the old recovery.conf settings live in postgresql.conf and recovery is triggered by a standby.signal file. Always test a failover in staging before you rely on it in production.

Do more than postgresql replication config generator — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

Choose streaming or logical replication and your PostgreSQL major version.
Enter the primary and standby addresses, replication user and slot name.
Copy each generated block to the matching server, restart PostgreSQL, and run the verification queries.

Frequently asked questions

What is the difference between streaming and logical replication in PostgreSQL?

Streaming (physical) replication ships raw WAL and produces a byte-identical, read-only copy of the whole cluster — ideal for high availability and read replicas. Logical replication decodes WAL into row changes and sends them per table, so the subscriber is a normal writable database that can hold a subset of tables and even run a different major version. Use streaming for failover, logical for selective replication and major-version upgrades.

Do I need a replication slot?

Not strictly for physical replication — wal_keep_size can cover short outages — but a slot is far safer because the primary refuses to recycle WAL the standby has not received yet. The trade-off is that an inactive slot retains WAL forever and can fill the disk, so monitor pg_replication_slots and drop slots you no longer use. Logical replication always uses a slot, created automatically by CREATE SUBSCRIPTION.

Which settings require a PostgreSQL restart?

wal_level, max_wal_senders, max_replication_slots, max_worker_processes and archive_mode are all postmaster-level settings that need a full restart. primary_conninfo, primary_slot_name, synchronous_standby_names, hot_standby_feedback and archive_command only need SELECT pg_reload_conf(). You can inspect a running database's settings — and edit them safely — with an SQL client such as Chat2DB.