Debezium Support
Last reviewed by Scott Sternloff
Debezium is the open-source change data capture (CDC) platform that streams every insert, update and delete from your databases into Kafka or another message broker. AceMQ designs, implements and supports Debezium CDC pipelines in production: Oracle, SQL Server, PostgreSQL, MySQL, Db2 and MongoDB sources, Kafka Connect or Debezium Server, with a 15-minute emergency response when change events stop flowing.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Debezium consulting and services.
Customers
Partners
Incident Triage
These are real symptoms from real Debezium production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| PostgreSQL disk filling up while the Debezium connector is stopped or lagging | The replication slot. A logical replication slot keeps every WAL segment the connector has not confirmed, so a stopped connector, an idle table filter or a slow consumer makes WAL grow until the disk is full. Check pg_replication_slots for the retained size, then fix the connector or heartbeat configuration before dropping anything. | Under 1 hour |
| MySQL connector fails on restart because the binlog position no longer exists | Binlog retention against connector downtime. If the server purged the binlog files the connector last read, it cannot resume and needs a new snapshot. Confirm binlog_format is ROW and binlog_row_image is FULL, then set retention longer than the longest outage you plan to survive. | 1 to 3 hours |
| SQL Server changes stop appearing after a weekend or a maintenance window | The SQL Server CDC capture and cleanup jobs. CDC has to be enabled per table, the capture job has to be running under SQL Server Agent, and the cleanup job deletes change data after its retention period, three days by default. A connector that was down longer than that has lost changes and needs a snapshot. | 1 to 2 hours |
| Oracle connector lagging hours behind with LogMiner sessions running constantly | Supplemental logging, archive log availability and the LogMiner mining window. The database must be in ARCHIVELOG mode with supplemental logging on the captured tables. Long-running transactions and large batch jobs inflate the mining window, and newer Debezium releases add an unbuffered LogMiner adapter that changes the tuning. | 2 to 4 hours |
| Connector will not start after a restart, reporting a missing or corrupt schema history | The schema history topic. Connectors for MySQL, SQL Server, Oracle and Db2 keep table definitions in a Kafka topic that must have one partition and unlimited retention. If retention deleted part of it, or someone recreated it, the connector cannot rebuild the schema and needs a recovery snapshot. | 2 to 4 hours |
| Downstream consumers see duplicate change events after a failure | Delivery semantics. Debezium delivers at least once, so a connector restart replays events from the last committed offset. Consumers and sink connectors need idempotent writes keyed on the primary key, and that is cheaper to design in than to retrofit. | Under 2 hours |
Resolution times reflect typical Debezium engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Change events stopped, a connector stuck in a failed state, or database disk filling from retained logs. A senior engineer joins a live bridge within 15 minutes, 24/7, and works the database side and the Kafka side together.
Source database preparation, connector configuration, initial and incremental snapshots, topic and key design, schema registry and serialisation, and sink connectors into warehouses, search and microservices.
CDC from the systems of record that banks, insurers and manufacturers actually run: Oracle LogMiner, SQL Server CDC, Db2 and Db2 for IBM i, alongside PostgreSQL, MySQL, MariaDB and MongoDB.
The Kafka Connect cluster Debezium runs on: worker sizing, task rebalancing, offset and config topics, message size limits, and the Kafka cluster underneath, covered by the same team.
Where Kafka is more than the use case needs, Debezium Server streams changes straight to RabbitMQ, Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs, Apache Pulsar or Redis streams.
Planned upgrades across Debezium release series with offsets and schema history preserved, and a written RCA for every P1 covering what failed and the configuration that stops it recurring.
Why AceMQ
Most CDC incidents sit between the two: a replication slot, a purged binlog, a capture job, an offset topic. Our engineers work both sides, so nobody hands the incident back and forth between a DBA and a Kafka team.
The same engineers stay on your account and know your connectors, table filters and snapshot history. A P1 starts with diagnosis, not with explaining the pipeline.
We have replaced Kafka-based CDC with Debezium and RabbitMQ where Kafka was more than the workload needed, and built Kafka CDC where it was the right fit. You get the architecture that suits the volume.
Engineers across 26+ countries and every time zone, so a capture job that stops at 3am reaches someone already at work.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Escalation Path
Every tier reaches a senior Debezium engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
AceMQ Debezium support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
Debezium and change data capture support work from AceMQ. Each card links to the full write-up: the pipeline, what AceMQ diagnosed or changed, and the result.
Digital Banking Platform
Ongoing support for a cluster where an abandoned logical replication slot repeatedly filled the WAL volume and threatened to halt the primary.
PostgreSQLDebezium
Kafka
Prometheus
Subscription Software Provider
Stopping an Airbyte connection that kept dropping out of incremental mode and re-running full refreshes against a large table every night.
AirbytePostgreSQL
SnowflakeDebeziumRegional Retail Bank
Bringing an Oracle change data capture pipeline back inside its batch window after nightly jobs left the Debezium connector hours behind the source.
Kafka
Kubernetes
Online Travel Platform
Ongoing support for a MySQL change data capture pipeline that needed a full re-snapshot after a planned outage outlasted binlog retention and a trimmed schema history topic.
MySQLKafka
Amazon RDSAmerican National Insurance
American National Insurance replaced a Kafka-based CDC pipeline with a standalone Debezium + RabbitMQ architecture, simplifying operations while maintaining SQL Server change capture with improved message routing flexibility.
Kafka
RabbitMQDebeziumKubernetesSupport options
AceMQ offers Debezium support in four stages, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for pipelines your team runs, proactive monitoring that catches log retention, replication slot and CVE problems first, managed Debezium on your own infrastructure, and fully managed Debezium on AceMQ infrastructure. Kafka Connect and Debezium Server are covered in all four.
You run it, we back you up
Best for: Teams that run Debezium themselves and need an engineer who knows both the database and the broker.
You run it, we watch it with you
Best for: Pipelines where a purged log or a lost schema history topic means a full re-snapshot.
We run it in your cloud or data centre
Best for: Regulated estates that must keep database change streams inside their own boundary.
We host it and run it, as a service
Best for: Teams that want change events without owning Connect workers, offsets or a rota.
| Who does what | Stage 1 24/7 support | Stage 2 Proactive monitoring | Stage 3 Managed, your infrastructure | Stage 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Debezium day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Stage can start as an ad hoc engagement or an annual partnership, and you can move up or down a Stage as your team changes.
One partner for Debezium
Support is one part of what AceMQ does for Debezium. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Debezium is an open-source platform for change data capture. It reads a database's transaction log, such as the PostgreSQL write-ahead log, the MySQL binlog or Oracle redo logs through LogMiner, and turns every committed insert, update and delete into an event. Those events usually flow through Kafka Connect into Kafka topics, where other systems consume them, without polling the database or changing the application. The project is part of the Commonhaus Foundation.
Each Debezium source connector reads the database's own change log rather than querying tables, so the impact on source database performance is small and no change is missed between polls. After an optional initial snapshot, the connector turns each committed row-level change into a change event that carries the row before and after the change, plus metadata such as the transaction and log position. On Kafka Connect, the connector runs as a task on a Kafka Connect worker, writes events to Kafka topics, and stores its log position as an offset in Kafka, so a restarted connector resumes where it stopped instead of losing data. Schema evolution is handled by recording table structure changes alongside the events, and Kafka consumers then feed data warehouses, search indexes, caches and microservices from the same real-time data pipeline.
The open-source project offers community channels: a chat server, a mailing list and an issue tracker. Red Hat sells a supported Red Hat build of Debezium as part of its subscriptions, and managed Kafka services support their own connector platforms. For self-managed Debezium on Kafka Connect or Debezium Server, AceMQ provides 24/7 support with a 15-minute emergency SLA, covering the connectors, the source databases and the Kafka cluster together.
No. Debezium connectors normally run on Kafka Connect and write to Kafka, but Debezium Server runs the same connectors as a standalone application and sends change events to other systems, including RabbitMQ, Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs, Apache Pulsar and Redis streams. The Debezium engine can also be embedded in a Java application. We help teams choose based on volume, fan-out and what they already run.
The current release series is tested with Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, Db2 and Db2 for IBM i, MongoDB, Informix, Cassandra, Spanner, Vitess, CockroachDB and others. Each connector has its own database prerequisites, such as logical replication on PostgreSQL, row-based binlogs on MySQL, CDC enabled per table on SQL Server, and ARCHIVELOG mode with supplemental logging on Oracle.
Yes, and that is where most of our CDC work sits. Core banking, insurance policy and ERP systems usually run on Oracle, SQL Server or Db2, and they carry the hardest parts of CDC: large transactions, strict change windows, DBAs who need to approve every database setting, and audit requirements on the change stream. We prepare the database with your DBAs, run the initial snapshot without disrupting production, and hand over runbooks for the failure modes above.
Almost always a replication slot. PostgreSQL keeps every write-ahead log segment that a logical replication slot has not confirmed. If the connector stops, falls behind, or only watches tables that rarely change while other tables are busy, the slot holds WAL until the disk fills. The fix is a combination of monitoring slot lag, configuring heartbeats, and alerting before the disk is at risk, not dropping the slot during an incident.
24/7 incident response with a 15-minute SLA for P1 incidents, a written root cause analysis for each one, connector and snapshot configuration, upgrades across Debezium release series, Kafka Connect and Kafka cluster operations, and support for the source database settings CDC depends on. Every ticket goes to a named senior engineer, with no per-incident charge.
Yes. AceMQ works on Debezium in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Debezium environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Debezium is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Debezium for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a Debezium Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
