How to enable logical replication on Supabase, Neon, RDS, Cloud SQL and Azure

The short answer

Logical replication on managed Postgres means setting wal_level = logical, which can only take effect at server start, then connecting with a role that has the REPLICATION attribute and reading from a replication slot.⁶ Each provider wraps the setting differently:

• Supabase: logical replication is on by default; connect directly, not through the pooler.²
• Neon: turn it on per project in Settings › Postgres. It restarts computes and can’t be reverted.¹
• Amazon RDS: set the static parameter rds.logical_replication = 1 and reboot.³
• Google Cloud SQL: set the flag cloudsql.logical_decoding = on; the instance restarts.⁴
• Azure flexible server: set wal_level = logical, max_worker_processes to at least 16, and restart.⁵

On every one of them, a slot that nobody reads holds WAL until the disk fills. Plan for that before you flip the switch.

What every provider needs

Underneath the provider settings, Postgres needs four things:

1. wal_level = logical. It adds the information logical decoding needs and is set at server start, so a restart is unavoidable on most platforms.⁶
2. A role with REPLICATION. Streaming changes needs it.
3. A replication slot. It remembers how far the consumer has read. max_replication_slots defaults to 10.⁶
4. A direct connection. Connection poolers in transaction mode don’t carry the replication protocol.

For tables where you want the full old row on updates and deletes, you also set REPLICA IDENTITY FULL on each table; the replica identity entry explains when that matters.

Provider by provider

A few details per provider are worth reading twice.

Supabase. Replication needs a direct connection, and the destination must support IPv6 unless you enable the IPv4 add-on. The guide suggests a dedicated role created as postgres with CREATE ROLE <user> WITH REPLICATION, and creates the slot with pg_create_logical_replication_slot('example_slot', 'pgoutput').²

Neon. The switch is one-way and restarts the project’s computes. Neon removes inactive slots after about 40 hours, and a connected subscriber keeps the compute from scaling to zero.¹ That second point has a cost: a consumer that stays connected keeps a compute running.

Amazon RDS. Setting rds.logical_replication to 1 also sets wal_level, max_wal_senders, max_replication_slots and max_connections, and AWS notes it can increase WAL generation, so turn it on only when you use logical slots.³

Cloud SQL and Azure. Both are a flag plus a restart, as above.⁴ Azure adds a hard stop: the server switches to read-only when storage use reaches 95 percent or free space drops under 5 GiB, and past a threshold it drops an unused logical slot automatically.⁵ Your database stays up; your consumer loses its place.

Check that it worked

After the restart, connect with the role you will use and run:

Code A database command in SQL. The text around it says what it does.

SHOW wal_level;                       -- expect: logical

SELECT rolname, rolreplication
FROM pg_roles
WHERE rolname = current_user;         -- expect: rolreplication = t

SELECT slot_name, plugin, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS wal_held
FROM pg_replication_slots;            -- every slot, and how much WAL it holds

The last query is the one to keep. wal_held is how much WAL Postgres can’t recycle because of that slot. Put it on a dashboard.

The disk trap, and how to avoid it

A replication slot holds WAL until its consumer confirms it has read it. If the consumer stops, the WAL piles up. Every provider warns about this in its own words. AWS: a slot you don’t read from can quickly fill the instance’s storage.³ Google: an unused slot makes Postgres hold WAL segments indefinitely, so disk use can grow without limit.⁴ Microsoft adds that unconsumed WAL raises the risk of transaction ID wraparound.⁵

Three settings and habits limit the damage:

1. Cap retained WAL. max_slot_wal_keep_size limits how much WAL slots may keep; the default, -1, is unlimited, and a slot that falls further behind may no longer be able to continue.⁶ Losing a slot is better than losing the database.
2. Time out idle slots. PostgreSQL 18’s idle_replication_slot_timeout invalidates slots inactive longer than the setting; 0, the default, disables it.⁶ Neon’s 40-hour cleanup does the same job for you.¹
3. Alert on wal_held and on active = false. A slot that has been inactive for an hour is a warning; for a day, an incident.

Drop slots you no longer use: SELECT pg_drop_replication_slot('name');. The replication slot entry has more on how they work.

A checklist before you turn it on

1. Schedule the restart. Neon, RDS, Cloud SQL and Azure all restart.¹³
2. Create a dedicated replication role, not your admin user. Microsoft calls separating them good practice.⁵
3. Use the direct host, not the pooler.²
4. Set max_slot_wal_keep_size to a size your disk can afford.⁶
5. Add the wal_held query to monitoring with an alert.
6. Decide REPLICA IDENTITY per table.
7. Write down who owns each slot, so the next person knows which ones are safe to drop.

Why an audit tool wants this

The reason this post exists: logical decoding is how a tool can see what actually changed in a database, rather than what a client said it changed. Triggers and statement logs have their own trade-offs, compared in pgaudit, triggers or logical decoding.

Deedglass uses it for its strongest check. That check needs wal_level = logical, one replication slot per watched connector and REPLICA IDENTITY FULL on each watched table; Amazon RDS, Cloud SQL, Supabase, Neon and Azure have their own settings for it, and our docs give them as guidance.⁷ The checklist above applies to our slot as much as anyone’s: if the consumer stops, the slot still holds WAL. For the broader idea, see logical decoding for agent audit. To try the checks without installing anything, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.