Waltail docs.
Everything you need to get changes flowing from your Postgres database to a destination, and to understand what happens in between.
Quickstart
From a connection string to your first delivered change, in about five minutes.
Connect a database
What Waltail needs, the six checks, and guides for RDS, Supabase, Neon, Cloud SQL, Azure, Railway and your own server.
Message format
The JSON every destination receives, with insert, update, delete and backfill examples.
Backfills
Deliver the rows that already exist through the same destinations — estimate, confirm, done.
Delivery
At-least-once, per-row ordering, batch size and rate limit, retries and the undelivered queue.
Replay and retention
Replay undelivered or already-delivered messages, and how long changes are kept on each plan.
Management API
API keys and endpoints for everything the console does.
How Waltail works
Waltail connects to your Postgres over logical replication and receives every committed change as it happens. It stores each change durably in its own database first, and only then acknowledges it to yours — so a slow destination never makes your write-ahead log grow.
From there, delivery workers send the changes to each destination on the pipeline: in batches, rate-limited if you want, retried with backoff, and always in order for any given row. The console shows what was delivered, what is waiting, and what needs a replay.
You pay for the bytes delivered to your destinations and nothing else.