- Home
- Destinations
- Azure Service Bus
Postgres changes into Azure Service Bus.
Session id = row, message id = idempotency key, so session-enabled entities get per-row order and duplicate detection drops retries.
The Service Bus sink sends each change with SessionId set to the ordering key and MessageId set to the idempotency key. Enable sessions on the queue or subscription for per-row ordering, and duplicate detection for server-side dedupe. Batches split automatically at the service's size limit.
How delivery works
| Aspect | Behaviour for Azure Service Bus |
|---|---|
| Message | Body = the change JSON; MessageId = idempotency key; SessionId = ordering key. |
| Batching | Service Bus message batches, split automatically on the size limit; a single change too large to fit is reported by sequence. |
| Ordering | With sessions enabled, each row's changes are delivered in order to one receiver at a time. |
| Idempotency | With duplicate detection enabled, Service Bus drops redeliveries by MessageId. |
| 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 | Opens a sender link to the entity. |
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 Azure Service Bus as a destination
Pick the tables to stream, choose Azure Service Bus, and fill in Connection string, Queue or topic. Press Test — Waltail checks it can reach and write to Azure Service Bus 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 Azure Service Bus as
readevents.
Configuration
Fields as the console asks for them. Secrets are encrypted at rest and never shown again.
| Field | Console label | Required | Notes |
|---|---|---|---|
connection_string | Connection string | Yes | |
entity | Queue or topic | Yes |
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
Queue or topic?
Either. Name the entity; for topics each subscription gets every change and can filter.
Do I need sessions?
Only if per-row ordering matters to your consumer. Without sessions delivery is still at-least-once with the same ids.