Workflow: logical replication from Neon to a warehouse

Workflow: logical replication from Neon to a warehouse

TL;DR

Inserts/updates/deletes on a published table appear in the warehouse within the expected lag; slot lag stays near zero. A standing, low-latency feed of selected Neon tables into a warehouse, without polling the primary.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Steps

1. In a maintenance window, enable logical replication on the Neon project (irreversible wal_level change; restarts all computes, drops connections).

   Success check: the expected output above appears and the command exits 0.

2. Create a publication for only the tables you need: CREATE PUBLICATION [name] FOR TABLES [t1], [t2];. Fewer tables, less WAL, less lag.

   Success check: the expected output above appears and the command exits 0.

3. Create the replication slot manually: SELECT pg_create_logical_replication_slot('[slot]', 'pgoutput');.

4. On the warehouse/subscriber side, create the subscription with create_slot = false, the slot name, and the direct Neon connection string (no -pooler; replication needs a persistent connection).

   Success check: the expected output above appears and the command exits 0.

5. If IP Allow is on, add the subscriber's IPs.

   Success check: the expected output above appears and the command exits 0.

6. Monitor slot lag; an idle subscriber lets the slot grow WAL unboundedly, which grows storage.

Compatibility

Tool: Neon. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Workflow: Neon to warehouse via logical replication

Goal

Ordering constraints

• Enable logical replication before creating the publication; the restart drops connections, so do it in the window.
• Tables need replica identity (primary key) for updates/deletes.

Traps

• A dead subscriber with a live slot is a storage leak: alert on slot lag, not just subscriber health.
• DDL on published tables does not replicate; coordinate schema changes with the warehouse side.
• Never point the subscriber at the pooled hostname; the connection will not hold.

Verify

Neon's logical replication guide (verified live 2026-09-26): enabling is irreversible and restarts computes; manual slot creation pairs with create_slot=false; subscriber must use the direct connection string, not pooled; IP Allow needs the subscriber's IPs.