- Home
- Destinations
- Redis cache
A Redis cache that mirrors Postgres.
Inserts and updates write the row; deletes remove it. Per-row ordering means the last write always wins correctly.
The Redis cache sink turns change data capture into cache invalidation: the key is your prefix plus the row's ordering key (schema.table:pk), the value is the change JSON, and a delete removes the key. No TTL guessing, no stale reads after a write, no trigger code in the database.
How delivery works
| Aspect | Behaviour for Redis cache |
|---|---|
| Command | SET prefix+ordering_key <change JSON> for inserts and updates; DEL for deletes. No TTL. |
| Batching | One pipeline per batch. |
| Ordering | Changes to one key are applied in commit order, so the cache converges on the row's latest state. |
| Idempotency | Writes are idempotent by nature: a redelivered SET writes the same value. |
| 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. |
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 cache as a destination
Pick the tables to stream, choose Redis cache, and fill in Address. Press Test — Waltail checks it can reach and write to Redis cache 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 cache 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. |
password | Password | Optional | |
key_prefix | Key prefix | Optional | e.g. cache:; the ordering key is appended. |
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
What Redis cache receives:
SET cache:public.orders:42 '{"op":"update","table":"public.orders","data":{"id":42,"status":"shipped",...}}'
DEL cache:public.orders:43Questions
Is the value the row or the whole change?
The whole change JSON — the current row is under data, the previous values under old when replica identity provides them.
Can I invalidate instead of write?
Point your application at the key: read through on a miss, and treat the presence of a freshly written value as the new truth. If you only want invalidation, a webhook or queue sink plus a tiny consumer that DELs is the usual shape.