Workflow: logical replication from Neon to a warehouse

# Workflow: Neon to warehouse via logical replication

## Goal
A standing, low-latency feed of selected Neon tables into a warehouse, without polling the primary.

## Steps
1. In a maintenance window, enable logical replication on the Neon project (irreversible wal_level change; restarts all computes, drops connections).
2. Create a publication for only the tables you need: `CREATE PUBLICATION [name] FOR TABLES [t1], [t2];`. Fewer tables, less WAL, less lag.
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).
5. If IP Allow is on, add the subscriber's IPs.
6. Monitor slot lag; an idle subscriber lets the slot grow WAL unboundedly, which grows storage.

## 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
Inserts/updates/deletes on a published table appear in the warehouse within the expected lag; slot lag stays near zero.