Built for one job, and priced like it.

Postgres changes, delivered to the systems your application already uses — hosted, ordered, retried, and metered on one number. Here is how that differs from the other ways teams get there.

Four ways teams do this today

Approach	What it is good at	What it costs you	Waltail
Self-managed CDC stack	Full control; any source database; a broad connector ecosystem	A broker, a connector runtime, a JVM, offsets, schema topics — each sized, monitored and upgraded by you	A connection string. Nothing to run. Delivery goes straight to the destination, not through a platform you operate.
Warehouse ELT platform	Hundreds of sources and warehouse destinations; batch loads at scale	Minutes-to-hours latency, warehouse-only destinations, and pricing built for data teams — per connector, per row, or entry plans in the hundreds of dollars	Sub-second to queues, webhooks, caches and search; operational destinations only; $29 entry with 100 GB included
ORM-bound change subscriptions	Events inside the same application with a library call	One language, one client library, one consumer shape	Any language: the change lands in the queue, index, cache or endpoint you choose, and anything can read it
Triggers, polling, outbox tables	No vendor; works on day one	Code on the write path, missed deletes, dual-write bugs, or a table and worker per service to own	Logical replication off the write path; nothing added to your schema; every committed change, once, in order per row — and a backfill for what existed before

Nothing to operate

Waltail reads your database's write-ahead log over logical replication, stores every change durably before acknowledging it, and delivers from its own queue with retries, per-row ordering and replay. There is no broker, no connector cluster and no JVM in the path — on our side or yours. Changes go directly to the queue, stream, cache, search index or HTTP endpoint you already run.

Any language, any stack

The message is a plain JSON envelope — op, table, data, old, sequence, idempotency key, commit LSN. Consumers can be Go, Python, Rust, Java, TypeScript, a Lambda, a Worker: anything that reads from the destination. No client library, no ORM, nothing in your application.

Honest guarantees

At-least-once delivery with a unique idempotency key in every message, and strict ordering per row. A change is acknowledged to your database only after it is safely stored, and it is retried with backoff until the destination accepts it; what still fails is parked, shown with its last error, and replayed in one click. "Exactly-once delivery" over a network is an asymptote — we say so, and give you the key that makes exactly-once processing straightforward.

Pay for egress. Nothing else.

One meter: the gigabytes delivered to your destinations. The pricing models common elsewhere each tax something you want more of:

Model	What it penalises	Waltail
Per connector or per sink	Fanning one database out to several destinations	Sinks are free; connect as many as you like
Per row or per active row	Busy tables; bills that are hard to predict and have been known to jump on repricing	Bytes delivered, which you can verify in your own systems
Per seat	Letting the whole team see the console	Seats are free
Platform minimums	Small and early workloads	Free plan with 1 GB, then $29 with 100 GB

See pricing for the full plan table.

History on demand

Streaming starts at the moment a pipeline is created; a backfill delivers what already existed. Pick the tables, see the estimated rows and gigabytes, confirm, and Waltail reads the current rows in resumable pages and delivers them through every sink as read events — keyed like live changes, so a row's snapshot and its later updates arrive in order. Seed a new search index, give a new sink the past, or catch up a table you added later.

Leaving is easy

Deleting a pipeline drops the replication slot and publication Waltail created on your database, so nothing is left behind. Downgrade or cancel from the console at any time. Visible exits are what make a hosted service safe to enter.

What Waltail is not for

Loading a warehouse. No warehouse or lakehouse sinks, on purpose. Archive to S3 and load from there, or use a tool built for that lane.
Other source databases. Postgres only.
Filters and transforms. Not yet — every change to a selected table is delivered as it is.

Questions

Is Waltail open source?

No. Waltail is a hosted service run by a company whose only business is running it well. Enterprise customers can deploy the same software in their own cloud or on-premise, which is the answer to lock-in for larger teams; for everyone else, the free plan and a clean exit are.

Why not just use triggers or an outbox table?

Triggers run inside your transaction and slow or fail your writes; polling misses deletes and adds load; dual writes disagree; an outbox works but is a table and a worker you own per service. Logical replication reads committed changes off the write path, completely, with nothing added to your schema.

Why not run an open-source CDC stack myself?

You can, and for some teams it is right. The cost is the platform around it — a broker, a connector runtime, a JVM, offsets and schema topics, and the monitoring and upgrades for each. If the goal is 'tell my service when a row changes', that platform is the expensive part, and it is the part Waltail removes.

Can Waltail load my data warehouse?

Not directly, and by design. Waltail delivers to operational systems — queues, streams, caches, search indexes, HTTP. For analytics loading, use a tool built for warehouses; the closest thing here is archiving changes to S3 as NDJSON and loading from there.

What does Waltail not do yet?

Filters and payload transforms: a pipeline delivers every change to its tables, as it is. Those are on the roadmap and the docs say so plainly. Backfills, replay and per-sink tuning are in the product today.