| title | Postgres Maintenance |
|---|
Postgres logical replication slots are used to keep track of replication progress (recorded as a LSN).
Every time a new version of Sync Streams or Sync Rules are deployed, PowerSync creates a new replication slot, then switches over and deletes the old replication slot when the reprocessing of the new Sync Streams/Rules version is done.
The replication slots can be viewed using this query:
select slot_name, confirmed_flush_lsn, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) as lag from pg_replication_slots;Example output:
| slot_name | confirmed_flush_lsn | active | lag |
|---|---|---|---|
| powersync_1_c3c8cf21 | 0/70D8240 | 1 | 56 bytes |
| powersync_2_e62d7e0f | 0/70D8240 | 1 | 56 bytes |
In some cases, a replication slot may remain without being used. In this case, the slot prevents Postgres from deleting older WAL entries. One such example is when a PowerSync instance has been deprovisioned.
While this is desired behavior for slot replication downtime, it could result in excessive disk usage if the slot is not used anymore.
Inactive slots can be dropped using:
select slot_name, pg_drop_replication_slot(slot_name) from pg_replication_slots where active = false;Postgres prevents active slots from being dropped. If it does happen (e.g. while a PowerSync instance is disconnected), PowerSync would automatically re-create the slot, and restart replication.
Postgres can invalidate a replication slot when the amount of retained WAL data exceeds the max_slot_wal_keep_size limit. This is most likely to happen during a long-running initial snapshot — PowerSync must hold the slot open while copying your entire dataset, and WAL accumulates throughout that time.
If the slot is invalidated mid-snapshot, PowerSync detects this early and aborts with error PSYNC_S1146 rather than continuing a doomed snapshot. The fix is to increase max_slot_wal_keep_size on the source database and then redeploy your sync config to trigger a fresh snapshot.
To check the current max_slot_wal_keep_size value:
SELECT setting AS max_slot_wal_keep_size
FROM pg_settings
WHERE name = 'max_slot_wal_keep_size';A value of -1 means unlimited (no cap on WAL retention). If your database has a cap set, make sure it is large enough to cover the full WAL growth expected during an initial snapshot. See Managing & Monitoring Replication Lag for guidance on choosing an appropriate value.
You can monitor slot health in real time using the Diagnostics API. The wal_status, safe_wal_size, and max_slot_wal_keep_size fields on each connection object show how much WAL budget remains. The PowerSync Service also logs a warning when less than 50% of the WAL budget remains during a snapshot.
Postgres is configured with a maximum number of replication slots per server. Since each PowerSync instance uses one replication slot for replication and an additional one while deploying a new Sync Streams/Rules version, the maximum number of PowerSync instances connected to one Postgres server is equal to the maximum number of replication slots, minus 1.
If other clients are also using replication slots, this number is reduced further.
The maximum number of slots can be configured by setting max_replication_slots (not all hosting providers expose this), and checked using:
select current_setting('max_replication_slots')If this number is exceeded, you'll see an error such as "all replication slots are in use".