Queue Targets
Stream every change to a queue.
Wirekite Replicate writes every insert, update, and delete from your OLTP database to your message broker — in commit order, exactly once.
Most CDC-to-queue tools wrap each row change in verbose JSON, push to a registry-backed schema, and bottleneck on the broker. Result: your OLTP changes are stale by the time they reach the consumer.
Wirekite publishes changes in its native binary
.ckt
format — tab-delimited, self-describing, no JSON parsing on the consumer
side. Idempotent producers on Kafka, exactly-once subscriptions on
Pub/Sub. The bottleneck moves back to your broker, where it should be.
OLTP → broker, at the wire speed of the source.
Three brokers. Same guarantees.
Pick the broker your team already runs. We don't host any of them — you keep ownership of the queue infrastructure.
Apache Kafka
Idempotent producer enabled by default. Snappy / LZ4 / Zstd compression. Throughput limited only by your brokers.
Redpanda
Kafka API-compatible — same client path, same guarantees. Drop-in alternative when you want a Kafka without the JVM.
Google Pub/Sub
Broker-enforced exactly-once delivery (subscription flag). Ordering keys per <schema>.<table>. Fully managed.
Ordering, delivery, format — handled.
Ordering
Per-table commit order, preserved end-to-end.
Kafka / Redpanda partition by
<schema>.<table>;
Pub/Sub uses the same value as an ordering key. Within a table you
see inserts, updates, and deletes in exactly the order the source
committed them.
Delivery
Exactly-once where the broker supports it.
Idempotent producer is on by default for Kafka and Redpanda. Pub/Sub gets broker-enforced exactly-once when the subscription is created with the corresponding flag. Records are only published after the source transaction COMMITs — uncommitted or rolled-back changes never reach the queue.
Format
Native binary .ckt — no schema registry.
Records are tab-delimited with a
HEADER<tab>schema<tab>table
wrapper and a FOOTER
line. Operation marker (I /
U /
D) on every row.
No JSON parsing, no Avro schema lookup — consumers read tab-delimited text.
Batching
One record per message — or batch up to N.
Default is one record per Kafka message (lowest latency). Set
queueBatchSize = N
to batch up to N records per message, flushed on every COMMIT boundary.
Compression (snappy / lz4 / zstd) is configurable for Kafka and Redpanda.
Worth knowing
Queues are targets, not sources. Wirekite reads changes from OLTP databases (Postgres, MySQL, Oracle, SQL Server, etc.) and writes them to your queue. Reading from a Kafka topic as a source isn't supported today.
Queues belong to Wirekite Replicate, not Wirekite Data. A bulk initial load to a queue isn't a meaningful operation — you can't read a 1 billion-row snapshot of a Kafka topic. If you need both backfill + ongoing changes to a database, plus changes mirrored to a queue, run a Data migration to the database target and a Replicate migration with a queue target side-by-side.
Need OLTP changes in your event bus?
We'll connect a sample workload to your broker during the demo.