- Home
- Destinations
- Azure Event Hubs
Postgres changes into Azure Event Hubs.
Paste the namespace connection string; Waltail speaks to the hub's Kafka endpoint with the row key as the record key.
The Event Hubs sink is the Kafka sink with the connection details filled in: the connection string is translated into the namespace's Kafka endpoint, TLS and SASL PLAIN, and each change is produced with the ordering key as the record key. Standard tier or above, which is where the Kafka endpoint lives.
How delivery works
| Aspect | Behaviour for Azure Event Hubs |
|---|---|
| Record | Value = the change JSON; key = ordering key; header idempotency_key. |
| Batching | One produce per batch, acknowledged by the hub. |
| Ordering | Same key → same partition, in commit order. |
| Idempotency | Dedupe on the idempotency_key header. |
| 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 | A metadata round-trip over the Kafka endpoint. |
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 Event Hubs as a destination
Pick the tables to stream, choose Azure Event Hubs, and fill in Connection string. Press Test — Waltail checks it can reach and write to Azure Event Hubs 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 Event Hubs 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 | Namespace or hub connection string. |
event_hub | Event hub | Optional | Required when the connection string has no EntityPath. |
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
Which tier do I need?
Standard, Premium or Dedicated — the Kafka endpoint is not available on Basic.
Can consumers use the native AMQP SDKs?
Yes. Events produced through the Kafka endpoint are ordinary events; the record key becomes the partition key.