Supabase.

Waltail needs three things from Supabase: wal_level = logical, a user that is allowed to replicate, and a way to reach the database over the network. Set them up in the steps below. When you paste the connection string in Waltail, the console runs six checks and tells you if anything is still missing.

1. Copy the direct connection string

In the Supabase dashboard, open Connect and copy the direct connection string — port 5432 on the database host. Do not use the transaction-mode pooler on port 6543; it cannot carry a replication connection. If the direct host is IPv6-only and your network needs IPv4, turn on the IPv4 add-on.

2. User

The postgres user already has the replication attribute and owns the tables you create through the dashboard, so it passes every check as-is. If your policy wants a separate user, give it REPLICATION and membership in the owning role.

3. Slots

Supabase's own services use some replication slots. If the slot_headroom check warns or fails, drop slots you no longer use, or raise max_replication_slots in the project's database settings.

Then, in Waltail

1. Paste the connection string

   Use the direct database host. A transaction-mode pooler (PgBouncer and similar) cannot carry a replication connection, so the reachable check would fail there.

2. Pick tables

   Choose the tables to stream. A table needs a primary key — or REPLICA IDENTITY FULL or an index identity — for updates and deletes to replicate. The console marks any table that does not qualify and says why.

3. Add a destination

   Waltail creates a publication and a replication slot on your database (both named pgcdc_<pipeline>) and starts streaming. The quickstart walks through the rest.