- Home
- Destinations
- Redis Streams
Postgres changes into Redis Streams.
Consumer groups, acknowledgements and replay on infrastructure you already run — no Kafka needed.
The Redis Streams sink XADDs each change to one stream key with the change JSON, idempotency key and ordering key as fields. Streams are totally ordered and Waltail delivers batches in sequence order, so consumers read changes in commit order.
How delivery works
| Aspect | Behaviour for Redis Streams |
|---|---|
| Entry | Fields payload (the change JSON), idempotency_key, ordering_key; auto-generated stream id. |
| Batching | One pipelined XADD per change, executed per batch. |
| Ordering | The stream is totally ordered; batches are appended in sequence order. |
| Idempotency | Dedupe on the idempotency_key field. |
| On failure | A failed request is retried up to 5 times with exponential backoff (30 s, 1, 2, 4 min, with jitter). After the fifth failure the message is parked as undelivered, the console shows it with the last error, and one click replays it — later changes to the same row wait behind it so order is preserved. |
| Connection check | PING, then TYPE on the key to make sure an existing key is a stream. |
Set up in three steps
-
Connect your database
Paste a connection string and press Test. Waltail checks the version (12+), that
wal_levelislogical, that the user may replicate, and that a slot is free — and shows the fix for anything that fails. Then it creates its own publication and replication slot. Connection guide → -
Add Redis Streams as a destination
Pick the tables to stream, choose Redis Streams, and fill in Address, Stream key. Press Test — Waltail checks it can reach and write to Redis Streams before anything is saved.
-
Change a row
Insert or update a row. The console shows the first event as it is captured and delivered; from then on, every committed change follows within about a second. Have rows that already exist? Run a backfill — confirm the estimate and they arrive through Redis Streams as
readevents.
Configuration
Fields as the console asks for them. Secrets are encrypted at rest and never shown again.
| Field | Console label | Required | Notes |
|---|---|---|---|
addr | Address | Yes | host:port. |
stream | Stream key | Yes | |
password | Password | Optional |
Every sink also has two tuning settings: batch size (messages per request, default 100) and rate limit (messages per second, default unlimited). Changes to one row are never in flight twice at once.
Example
Every change is this JSON envelope — data is the row after the change, old the row before it when replica identity provides it, null otherwise:
{
"op": "update",
"table": "public.orders",
"data": { "id": 42, "status": "shipped", "total": 19.99 },
"old": { "id": 42, "status": "paid", "total": 19.99 },
"seq": 137,
"idempotency_key": "9f1c3d2e-6b4a-4c7e-9d0f-2a1b3c4d5e6f",
"commit_lsn": "0/1A2B3C8"
}Questions
Does it work with Upstash or ElastiCache?
Yes — any Redis that supports streams, reachable from the internet or a peered network.
Should I cap the stream?
Waltail appends only; trim with XTRIM or MAXLEN on your side once consumers have acknowledged.