Debezium Consulting & Services

Debezium Consulting: CDC Design, Implementation and Operations

Debezium consulting from AceMQ covers the whole of a change data capture (CDC) pipeline: preparing the source database, choosing between Kafka Connect and Debezium Server, getting snapshots, schema history and offsets right, and running the result in production. That includes replacing a Kafka-based CDC pipeline at American National Insurance with Debezium publishing straight to RabbitMQ.

A senior engineer, not an SDR. No sales sequence attached.

Emergency SLA
<15min
Customers
130+
Countries Served
26+

Without a Kafka cluster you do not need, or a snapshot you have to run twiceFor production incident cover, see AceMQ Debezium 24/7 support.

Customers

  • Microsoft
  • Henry Schein
  • Enbridge
  • Gojek

Partners

  • Broadcom
  • Redis
  • VMware Tanzu
  • OSSeva

The Problem

Why teams call us about Debezium

Eight Debezium problems that teams bring to AceMQ: connectors that snapshot everything again after a restart, a lost schema history topic, a purged database log, WAL held by a replication slot, and deletes that reach RabbitMQ as empty messages. If one describes your pipeline, that is where the review starts.

  1. 01

    A connector restarts and snapshots every table again because its offsets lived in a file on storage that did not survive the restart

  2. 02

    The schema history topic was trimmed by retention or recreated, and the connector refuses to start

  3. 03

    The database purged the binlog or archive logs during an outage, so the connector has no position to resume from

  4. 04

    PostgreSQL disk fills with WAL held by a replication slot that a connector watching quiet tables never confirms

  5. 05

    SQL Server changes stop because the SQL Server Agent that drives CDC is not running

  6. 06

    Consumers see duplicate change events after a failure and the downstream writes are not idempotent

  7. 07

    A Kafka cluster, a Connect cluster and a registry were built to move a handful of tables to a few consumers

  8. 08

    Deletes arrive on RabbitMQ as empty messages, because the broker has no null payload for a Debezium tombstone

A good fit if you run, or are about to build, change data capture from Oracle, SQL Server, PostgreSQL or MySQL, and want Debezium experts who work the database side and the messaging side together.

Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Debezium.

Running Debezium in production? Get a quote from a senior engineer, answered within one hour.

Contact Us

How it breaks, and the fix

What happens when one Debezium sink task stalls?

Debezium delivers change events at least once, and its sink tasks are Kafka consumers. If one sink task blocks on a lock in the target database and overruns its poll interval, the group rebalances, every sink task pauses, and change events queue on every topic.

One blocked sink task, one stalled group

One Debezium connector, three topics, three sink tasks

Illustrative

  1. The connector writes change events to three topics and three sink tasks apply them to the target database. Lag stays near zero.

  2. Sink task 2 waits on a row lock in the target database and overruns max.poll.interval.ms. The group rebalances, all three sink tasks pause, and change events queue on every topic while the source keeps producing them.

  3. Writes are idempotent upserts keyed on the primary key, batches are sized to finish inside the poll interval, and the lock source is removed. A replay after a rebalance now causes no duplicates, and the queues drain.

Pipeline lag is often a sink problem rather than a Debezium problem, and the MilliSecondsBehindSource metric will not show it, because it measures the connector's lag behind the source database. Because Debezium is at-least-once, every restart or rebalance replays events, so the sink must upsert on the primary key and handle delete tombstones. AceMQ also checks max.poll.interval.ms, batch size and the log retention at the source.

Our Services

Debezium Consulting & Services

AceMQ's CDC consulting runs as five Debezium service lines: Kafka Connect CDC architecture, Debezium Server with RabbitMQ, source database preparation, snapshots with schema history recovery, and upgrades with monitoring. A senior engineer leads each one, and any of them can roll into 24/7 support.

  • 01

    Kafka Connect CDC Architecture

    When Kafka already runs in your estate, Debezium belongs on Kafka Connect. We design the pipeline around the Connect cluster rather than bolting connectors onto it.

    • Connector configuration, topic naming, key design and transforms for each source database
    • Connect worker sizing, task rebalancing and the offset, config and status topics
    • A schema history topic with one partition and retention that cannot silently delete it
    • Serialisation choices and schema evolution handling for downstream consumers
  • 02

    Debezium Server and RabbitMQ

    Where Kafka is more than the workload needs, Debezium Server runs the same connectors as a standalone application and publishes to RabbitMQ, with exchanges and routing keys doing the fan-out.

    • The rabbitmq sink: exchange per topic or a fixed exchange, routing key static, from the topic or from the record key
    • Persistent delivery, publisher confirm timeouts and a placeholder value for delete tombstones, since RabbitMQ has no null payload
    • RabbitMQ Streams through the rabbitmqstream sink where replay and large fan-out matter
    • Offsets and schema history moved off Kafka to stores that survive a restart
  • 03

    Source Database Preparation

    CDC needs settings changed on the source database, and those changes usually need a DBA's approval. We write the change list your DBAs need and prove the settings in a test environment first.

    • Oracle in ARCHIVELOG mode with supplemental logging, and the LogMiner configuration
    • SQL Server CDC enabled per table with the SQL Server Agent jobs running
    • PostgreSQL logical replication, slot lifecycle and heartbeats against WAL growth
    • MySQL binlog_format ROW and binlog_row_image FULL, with retention longer than the longest planned outage
  • 04

    Snapshots, Schema History and Recovery

    The three things that turn a CDC restart into an incident. We decide them at design time and rehearse the recovery.

    • Snapshot mode per connector, and incremental snapshots with signalling tables for backfilling tables added later
    • Schema history recovery, including the cases where recovery mode is unsafe because the schema changed after shutdown
    • Offset storage and what a lost offset means for each source
    • Idempotent consumer design, because delivery is at least once
  • 05

    Upgrades, Monitoring and Operations

    A CDC pipeline is only as good as the alerts on its lag and the discipline of its upgrades.

    • Planned upgrades across Debezium release series with offsets and schema history preserved
    • Lag monitoring from the MilliSecondsBehindSource metric, and replication slot and log retention alerts
    • Capacity checks on the source database, the Connect cluster and the destination
    • A written root cause analysis for every production incident
  • 15 MIN SLA

    24/7 Debezium Support

    Named senior engineers on your account — 15-minute emergency response, no ticket routing, no junior triage.

    • 15-minute emergency response SLA
    • Named engineer, zero cold-start
    • Proactive CVE & health monitoring
    • Quarterly deployment reviews
    Compare the four Debezium support stages

Want AceMQ to take this off your team's plate? Tell us about your Debezium estate.

Contact Us

24/7 Support

Debezium Support When It Matters Most

AceMQ Debezium support gives you named senior engineers and a 15-minute first response when change events stop, 24/7. Lower severities get 1-hour, 4-hour and next-business-day responses. The same response times cover the connectors, the source database settings CDC depends on, and the Kafka or RabbitMQ side.

  1. 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
  2. 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
  3. 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
  4. Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements

P1 escalation path

A replay of one P1, from the first page to the written root-cause analysis

SLA 15:00
T+Elapsed15:00
Engineer on your bridge

15-minute P1 response, 24/7.
A response time, not a resolution time.

  1. T+00:00

    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.

    Paged
  2. T+15:00

    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.

    Live
  3. T+30:00

    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.

    If needed
  4. After

    Written root-cause analysis

    Root cause, the fix applied and the prevention steps, delivered after every P1.

    Every P1

How Our Support Actually Works

Beyond SLAs — the model behind senior-only, zero-cold-start expert access.

  • Named Engineers on Your Account

    Every ticket is handled by a senior SME assigned to your account — not a pool of anonymous agents. Zero cold-start. No re-explaining your environment.

  • Live Escalation on Any Ticket

    Any ticket can be escalated to a live session with your named engineer via calendar booking. No gatekeeping, no approval required — direct access, always.

  • Proactive Risk Mitigation

    Quarterly health checks on your deployment plus shared intelligence from 50+ support customers — we surface risks before they reach production.

  • Critical Bug & CVE Intelligence

    Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.

Compare Debezium support plans

How It Works

What actually happens next

A Debezium engagement runs in four stages: a source and requirements review scoped per database, a written architecture and plan within a week, implementation with your DBAs and platform team, then a handover with runbooks. Each stage ends in writing, so your DBAs can review it first.

Scoped per source database

Source and requirements review

We review each source database's log settings and retention, the tables and volumes to capture, the consumers and their delivery needs, and what your DBAs must approve before a connector touches production.

Within a week of the review

Written architecture and plan

A recommendation on Kafka Connect or Debezium Server, where offsets and schema history live, how snapshots will run, and the failure modes to rehearse, with the reasoning attached so it can be reviewed by your DBAs and platform team.

Scoped per engagement

Implementation alongside your team

We prepare the database with your DBAs, configure the connectors, run the initial snapshot without disrupting production and wire the destination, rehearsing a restart and a recovery before go-live.

Ongoing

Handover and optional cover

Runbooks for snapshots, schema history recovery, offset handling and upgrades, plus 24/7 support with a 15-minute emergency SLA if you want it.

  • Written findings before any change
  • Every change staged and reversible
  • Your engineers and DBAs in the room
  • You keep the runbooks
  • Ad hoc engagements or an annual partnership

A senior engineer, not an SDR. No sales sequence attached.

Customer Success

Real Debezium Results

Change data capture work from AceMQ: replacing a Kafka CDC pipeline with Debezium and RabbitMQ, an Oracle LogMiner lag remediation, MySQL binlog and schema history support, and a PostgreSQL replication slot case. Each card links to the full write-up: the environment, what AceMQ changed, and the result.

1 / 5 case studies

  • Consulting

    Replacing Kafka with Debezium + RabbitMQ for Change Data Capture

    American 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.

    KafkaRabbitMQDebeziumKubernetes
    Read case study : Replacing Kafka with Debezium + RabbitMQ for Change Data Capture
  • Remediation

    Debezium Oracle LogMiner Lag Remediation

    Regional 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.

    DebeziumOracleKafkaKubernetes
    Read case study : Debezium Oracle LogMiner Lag Remediation
  • Support

    PostgreSQL WAL and Replication Slot Support

    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.

    PostgreSQLDebeziumKafkaPrometheus
    Read case study : PostgreSQL WAL and Replication Slot Support
All use cases

Solutions

Every way AceMQ works with Debezium.

AceMQ covers Debezium end to end: CDC design and implementation, 24/7 support and incident management, proactive monitoring, managed pipelines on your infrastructure or on AceMQ's, support for the release you run, and a fixed-price health check.

Projects

Build, fix or move Debezium

Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.

Support and managed services

Keep Debezium running

Four stages of ongoing cover once you are live. Each stage hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Debezium for you.

Compare the four Debezium support stages

Side by side

Debezium on Kafka Connect or Debezium Server: which fits?

Debezium connectors run either as source connectors on Kafka Connect, which write to Kafka topics, or inside Debezium Server, a standalone application that streams changes to other destinations. The choice sets where offsets and schema history live and what you operate. Each row below answers one question about it.

Debezium on Kafka Connect compared with Debezium Server on destinations, connectors per process, offsets, schema history, best fit and what to settle first
QuestionDebezium on Kafka ConnectDebezium Server
Where do the change events go?To Kafka topics.To Kafka, RabbitMQ, Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs, Apache Pulsar, Redis streams, NATS and other sinks.
How many connectors run per process?Many, as tasks on shared Connect workers.One connector per Debezium Server instance.
Where are offsets stored?In Kafka.In a local file by default, with JDBC and Redis stores as alternatives. On a container's ephemeral disk, the file is lost at the next restart.
Where is schema history stored?In a Kafka topic that needs one partition and retention that never deletes it.In Kafka by default. File and Redis stores exist for deployments without Kafka.
When is it the better fit?Kafka is already the backbone, there are many sources, or consumers need to replay.There are a few sources, the destination is not Kafka, and you do not want to run Kafka.
What must you settle first?Partition count and retention on the schema history topic.Persistent storage for offsets and schema history, or both vanish on restart.

Comparing Debezium with managed CDC, Airbyte and Fivetran? Read Debezium alternatives: CDC tools compared.

Not sure which option fits? A senior Debezium engineer will scope it with you.

Contact Us

One partner, not five

We Support Your Entire Tech Stack

Debezium rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Messaging & Streaming

Databases & Caching

Search & Analytics

Lakehouse & Compute

Observability & Monitoring

Data Integration

Cloud & Containers

API Management

VMware Tanzu

See all 52 technologies we supportShow fewer

Guides, articles and comparisons

Go deeper on Debezium.

Guides from AceMQ engineers on Debezium alternatives and on running the Kafka and RabbitMQ platforms Debezium publishes to, plus the AceMQ services for the source databases it reads from, such as PostgreSQL and MySQL.

Related services

Ready to talk Debezium? Get a quote or send us a message.

Contact Us

FAQs

Debezium Questions Answered

Eight answers on Debezium from AceMQ: Kafka Connect or Debezium Server and whether you need Kafka, delivery guarantees, versions, who answers when events stop, how an engagement starts, working with your DBAs, repeated snapshots, and WAL growth.

Still have questions about Debezium? Email an Expert

Should we run Debezium on Kafka Connect or Debezium Server, and do we need Kafka?

Use Kafka Connect when Kafka is already your backbone and consumers replay. Use Debezium Server when you have a few sources and a destination that is not Kafka, such as RabbitMQ, Kinesis or Pub/Sub. You do not need Kafka for Debezium Server, but its schema history defaults to Kafka, so a deployment without Kafka must configure another store.

Does Debezium deliver each change exactly once?

No, it delivers at least once. Offsets are committed periodically, so after an outage or a rebalance a connector can replay events that consumers have already seen. Design consumers and sinks to be idempotent on the primary key, and handle delete tombstones. That is cheaper to build in at the start than to add after duplicates reach a downstream system.

Which Debezium versions are supported, and when do they reach end of life?

The Debezium releases page lists series from 1.9 to 3.7 as stable and states no support period or end-of-life dates, so the practical rule is to stay close to the latest series. AceMQ supports the release you run and plans upgrades across series, keeping offsets and schema history intact.

Who answers when Debezium change events stop flowing, and how fast?

A named AceMQ senior engineer answers within 15 minutes, 24/7, when change events stop, a connector fails and will not restart, or database disk fills with retained logs. Lower severities get a first response within 1 hour, 4 hours or the next business day. A written root-cause analysis follows every P1.

How does a change data capture consulting engagement with AceMQ start?

An AceMQ Debezium engagement starts with a free consultation with a senior engineer, scheduled within 24 hours. Next comes a source and requirements review, scoped per source database, covering log settings and retention, the tables to capture, the consumers and what your DBAs must approve. A written architecture and plan follow within a week of the review.

Can a Debezium engineer work alongside our DBAs and platform team?

Yes, and most CDC work needs both. AceMQ assigns a named senior engineer who prepares the source database with your DBAs, configures the connectors, runs the initial snapshot without disrupting production and rehearses a restart and a recovery before go-live. You keep the runbooks for snapshots, schema history recovery, offsets and upgrades.

Why did our Debezium connector snapshot every table again after a restart?

Almost always because it lost its offsets. A Debezium Server deployment that keeps its offsets file on a container's ephemeral disk forgets its position at the next restart, and a snapshot mode that forces a snapshot on start does the same. AceMQ moves offsets to a persistent volume or a JDBC or Redis store, and picks the snapshot mode per connector on purpose.

Why did our PostgreSQL disk fill up after we deployed Debezium?

Almost always a replication slot. PostgreSQL keeps every WAL segment that a logical replication slot has not confirmed, so a stopped connector, or one watching tables that rarely change, lets WAL grow until the disk is full. The fix is monitoring slot lag, configuring heartbeats and alerting well before the disk is at risk, not dropping the slot during an incident.

Can we work with AceMQ on Debezium without a long contract?

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.

How much does AceMQ Debezium support or consulting cost?

Every AceMQ proposal is tailored to your requirements: your Debezium environment, the SLA you need, the hours of cover and the scope of work. We do not send generic quotes or publish a price list, because two estates of the same size rarely need the same thing. Request a quote and AceMQ replies within 1 hour.

Let's talk

Ready to Design or Fix Your CDC Pipeline?

Whether you are building change data capture from Oracle or SQL Server, deciding if Kafka is the right transport, or repairing a pipeline that keeps restarting into snapshots, AceMQ staffs every engagement with a named senior engineer. Quote requests answered within 1 hour.

A senior CDC engineer, not a sales queueAbout your databases and pipelines, not a pitch deckQuote requests answered within 1 hour

Production incident right now?Email a Debezium Architect

Get in Touch

Talk to a Debezium Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 business day.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 business day.