The point is not another CDC runtime. It is the operational work around it — knowing whether a database is ready, turning capture on without guesswork, seeing what is captured, and handing the runtime a configuration that matches what you just enabled.
SQL Server and PostgreSQL connect as sources beside your broker connections — per environment, with credentials held and encrypted the same way.
Before anything is changed, a read-only pass over the things that decide whether capture will work at all — with what to fix, not just a red cross.
Pick tables, see the statements BROKA intends to run, then either run them under the environment policy or take them away to be reviewed.
What is being captured, since when, with which key and which columns — and whether changes are actually arriving or the table has been quiet for a day.
Generated from the tables you enabled and the destination you chose. The destination also decides where it runs, so there is no runtime to pick: a Kafka destination produces a Connect REST payload, and a Redis or RabbitMQ destination produces a pipeline BROKA runs itself.
Snapshot or streaming, position against the source, errors and retries — with pause, resume and restart as guarded operations.
Enabling capture is a schema-level change, so it is never silent. BROKA shows exactly what it intends to do, then offers two paths — and in an environment marked read-only, only the second one is available.
For development, test and staging, where the console is allowed to alter the source schema. Every statement is shown first and recorded afterwards.
For estates where a console may not touch a production schema. The generated SQL goes into a change request, a migration or a DBA ticket unchanged.
-- illustrative: BROKA reads the current state and writes what is missing
-- 1 · database level, once
EXEC sys.sp_cdc_enable_db;
-- 2 · per table selected in the console
EXEC sys.sp_cdc_enable_table
@source_schema = N'sales',
@source_name = N'orders',
@role_name = N'cdc_reader',
@capture_instance = N'sales_orders',
@supports_net_changes = 1;
-- 3 · what BROKA will verify afterwards
-- capture instance created, agent jobs present,
-- retention window, and the columns actually capturedWhen the destination is a Kafka topic, capture runs as a Debezium connector on your Connect cluster and is operated from BROKA beside your topics and consumer groups. This path is finished: SQL Server, PostgreSQL and MySQL sources are proven against live databases, including schema evolution, dead-letter triage and day-two repair from inside the console.
Kafka Connect always terminates in Kafka, so a destination that is not Kafka needs a different engine. BROKA embeds Debezium Engine in a worker of its own rather than attaching to a third-party runtime — which is what makes the sink ours, and therefore what makes retry and dead-lettering possible at all.
In Lane A the runtime is yours: your team stands up Kafka Connect and registers it with BROKA over its API, the same way a broker connection is added. Lane B is planned so that there is nothing for you to stand up — BROKA would run the worker itself, as a second process in your own deployment. Either way the change data never leaves your infrastructure, and connectors, offsets and failures appear beside the rest of your estate.
Kafka destinations are finished and proven against live databases. Redis and RabbitMQ are planned, on a worker BROKA would run itself rather than a runtime it attaches to; none of it is built yet. Artemis is in neither lane, and saying so is better than promising a bridge nobody has built.
In Lane A, BROKA manages and never carries: it reads connector state and offsets, and the delivery path is your Connect cluster. Lane B, as designed, carries as well — the worker would be what reads the source and writes the sink — so it would be in the delivery path by design, and says so rather than borrowing Lane A's boundary. Change data is never stored by BROKA and never leaves your infrastructure in either lane.
Lane B is designed for at-least-once delivery. Exactly-once is out of scope, so a consumer downstream of a pipeline would have to be idempotent — duplicates would be possible after a restart or a failover, and no change would be lost. Concurrency is to be guarded per pipeline: a second worker could never double-run one, and a crashed worker's pipelines would be picked up.
A database source is a connection. A captured table is a resource. Enabling capture is a guarded write. None of that is new machinery — it is the model already running under every broker BROKA supports, applied to one more technology.
Kafka, Redis, RabbitMQ and Apache Artemis are fully supported today. The operational model underneath them — environments, connections, resources, health, access control, audit, guardrails and search — is built as a foundation for messaging and data movement more broadly, so new technologies can join it without a new tool.
Whatever joins the platform inherits the same operational foundation — and keeps its own specialized concepts and operations.
Launch scope is the brokers supported today. Direction items carry no dates or delivery commitments.