Almost every business keeps its most important facts in a database. The trouble starts when other systems need those facts too.

A database is a program that stores data safely and lets other programs read and change it. An online store, for example, keeps customers, products, and orders in one. That works well for the store’s own application. But soon other systems want the same information. A search page needs fresh product data. A recommendation engine needs every order. A dashboard needs live sales numbers. A warehouse system needs to know when to ship.

Each of these wants to know two things: what the data looks like now, and what just changed. Databases are very good at the first and, traditionally, quite poor at the second.

The old answers, and why they hurt

What we want is a way to learn about every change, in order, without slowing the database, without missing anything, and without asking the application to do extra work. That wish list is exactly what log-based CDC delivers.

CDC is a simple idea with a few very different ways to build it. Knowing the differences helps you see why Debezium chose the approach it did.

Change Data Capture means detecting every change made to data in a database, and turning each change into a message that other systems can use. An insert becomes a “row created” message. An update becomes a “row changed” message that says what it was and what it became. A delete becomes a “row removed” message.

Three ways to capture changes

Why the log is special

Nearly every serious database writes each change to an internal file before it does anything else. This file is called the transaction log. Different databases call it different things: the binary log in MySQL, the write-ahead log in PostgreSQL, the redo log in Oracle. The database uses it for its own safety, to recover after a crash and to copy changes to replicas. It already holds every committed change, in the exact order they happened.

Log-based CDC simply reads that file. The database does no extra work for the observer, the application does not change at all, and nothing is missed. Debezium is a log-based CDC tool.

Debezium does not work alone. It rides on two other pieces, and understanding them makes everything that follows clearer.

Kafka in one minute

Apache Kafka is a system that stores and moves streams of events. Events are written to named channels called topics. A topic is split into partitions, which are ordered logs. Programs that write are producers. Programs that read are consumers, and they remember how far they have read by keeping an offset, a bookmark. Kafka keeps the events for as long as you configure, so many consumers can read the same events at their own pace, and new consumers can go back and read from the start.

That last point is what makes Kafka a natural home for database changes. A stream of changes can be read by the search team, the analytics team, and the fraud team, each independently, each at its own speed.

Kafka Connect in one minute

Kafka Connect is a framework that runs ready-made programs called connectors to move data between Kafka and other systems. A source connector brings data into Kafka. A sink connector sends data from Kafka out to another system. Connect handles the boring parts: running the connectors, restarting them after failures, storing their progress, and spreading the work over several machines.

Debezium is a family of tools around one job: turning database changes into event streams.

Debezium is an open-source platform for change data capture. Its main product is a set of Kafka Connect source connectors, one for each supported database. There are connectors for MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Db2, and several others. Each knows how to read that database’s own log format and translate it into a common event shape.

Three ways to run it

This guide focuses on the first way, Debezium on Kafka Connect, because it is what most teams use with Kafka.

Why teams choose it

Study the picture first. Then read the roles below it.

flowchart LR
  subgraph App["Application Side"]
    A["Application"] -->|"writes rows"| DB[("Source Database")]
    DB --> LOG["Transaction Log"]
  end
  subgraph Connect["Kafka Connect Cluster"]
    W1["Worker 1 with Debezium Connector"]
    W2["Worker 2 standby"]
    OFF["Offsets and Status Topics"]
  end
  subgraph K["Kafka Cluster"]
    T1["Topic: orders"]
    T2["Topic: customers"]
    SH["Schema History Topic"]
  end
  subgraph Consumers["Consumers"]
    C1["Search Indexer"]
    C2["Data Warehouse Sink"]
    C3["Microservice"]
  end
  LOG -->|"reads changes"| W1
  W1 --> T1
  W1 --> T2
  W1 --> SH
  W1 --- OFF
  W2 --- OFF
  T1 --> C1
  T1 --> C2
  T2 --> C3
    

Reading the diagram

The application on the left writes to the database as usual. The database appends each change to its transaction log. The Debezium connector, running inside a Kafka Connect worker, reads that log like a very patient reader following a long scroll. For each change it creates an event and writes it to a Kafka topic, usually one topic per table. Consumers on the right read the topics and do whatever they need to do.

Component roles

Every database keeps its change record differently. Debezium hides the differences, but knowing them explains many setup steps and surprises.

The common pattern

Despite the differences, the setup follows the same three steps for every database. First, turn on the database feature that keeps enough detail in the log. Second, create a dedicated user with just the rights the connector needs. Third, tell the connector where the database is, which tables to watch, and a name to use for the topics.

Everything downstream depends on what a change event contains. Learn the shape once, and every pattern becomes easier to read.

Each change Debezium captures becomes one Kafka message with two main parts: a key and a value. The key identifies the row that changed, using the table’s primary key columns. The value is a wrapper called the envelope, which describes the change itself.

What is in the envelope

The four kinds of operation

Deletes and tombstones

When a row is deleted, Debezium normally sends two messages. The first is a delete event that describes the removed row. The second is a tombstone, a message with the same key and an empty value. Kafka uses tombstones in a feature called log compaction: when compaction runs, a tombstone tells Kafka that all older messages for that key can be thrown away. Without tombstones, deleted rows would live forever in a compacted topic.

Column types and precision

Databases have types with no perfect twin in messaging formats, such as exact decimals, dates with time zones, and large binary values. Debezium offers settings to choose how they arrive, for example decimals as exact numbers, as text, or as floating point numbers. Choose carefully for money. Floating point can quietly round values, while exact or text forms preserve every digit.

The log only holds recent changes. To capture a table that already has millions of rows, Debezium first takes a snapshot.

When a connector starts for the first time, it faces a puzzle. Your tables already contain data, but the log only remembers changes from a certain point onward. A new consumer that only sees future changes would be missing the whole starting picture. So Debezium takes an initial snapshot: it reads the current rows of every captured table and emits them as read events. Then it switches to reading the log from exactly the point where the snapshot began, so nothing falls between the two.

Snapshot modes

The problem with big snapshots

A classic snapshot reads all tables in one go. For huge tables this can take hours, and if it fails near the end, it starts again. During that time the connector produces no live changes, so consumers see nothing new. Some databases also hold locks or long-running transactions during a snapshot, which can affect other work.

Incremental snapshots

Debezium solved this with incremental snapshots. Instead of pausing streaming to copy everything, it copies a table in small chunks, interleaved with live log reading. A special signal, sent through a small control table or a Kafka topic, starts a chunked snapshot of chosen tables at any time. The connector uses a clever marking technique so that if a live change touches a row inside a chunk, the newer change wins and old copies are dropped.

flowchart TD
  S["Signal: snapshot table X"] --> C1["Open chunk window"]
  C1 --> R["Read next chunk of rows by primary key"]
  R --> L["Keep reading live log changes in parallel"]
  L --> D{"Live change touches a row inside the chunk?"}
  D -- "Yes" --> DROP["Drop the older copy, keep live change"]
  D -- "No" --> KEEP["Keep chunk row"]
  DROP --> EMIT["Emit chunk to topic"]
  KEEP --> EMIT
  EMIT --> MORE{"More chunks left?"}
  MORE -- "Yes" --> R
  MORE -- "No" --> DONE["Snapshot of table complete"]
    

Follow one order from the moment an application saves it to the moment a consumer reads it.

sequenceDiagram
  autonumber
  participant App as Application
  participant DB as Source Database
  participant Dbz as Debezium Connector
  participant Conn as Kafka Connect
  participant K as Kafka Topic
  participant Con as Consumer
  App->>DB: Insert order row and commit
  DB->>DB: Append change to transaction log
  Dbz->>DB: Stream log entries from saved position
  DB-->>Dbz: Committed change for the orders table
  Dbz->>Dbz: Decode row, build envelope, choose key
  Dbz->>Conn: Hand over record with source offset
  Conn->>K: Produce record to topic
  K-->>Conn: Acknowledged
  Conn->>Conn: Save source offset to offsets topic
  Con->>K: Poll for new records
  K-->>Con: Order change event
    

Step 1 and 2: the write and the log

The application saves an order and commits the transaction. Before the database considers the commit final, it has already appended the change to its transaction log. This is the same step the database always performs for its own safety. Debezium adds nothing here.

Step 3 to 5: reading and decoding

The connector holds a connection to the database that behaves like a replica asking for the latest log entries. It receives entries in commit order. For each committed change it decodes the raw bytes, looks up the table structure, builds the envelope with before, after, and source details, and picks the key from the primary key columns.

Step 6 to 8: handing to Kafka

The connector passes the record to the Connect framework together with a note saying which log position it came from. Connect sends the record to Kafka and waits for confirmation. Only after Kafka has confirmed does Connect save the position to its offsets topic. That order is very important: the bookmark only moves after the data is safe.

Step 9 to 10: consumption

Any consumer subscribed to the orders topic reads the event on its own schedule and does its job. The database and the application are not involved at all.

What happens when the connector crashes at the worst possible moment? The answer shapes how you must write every consumer.

The connector’s bookmark is called an offset. It records the position in the database log up to which changes have been safely sent. If the connector crashes and restarts, it reads its last saved offset and asks the database to continue from there.

The gap that causes duplicates

Look again at the order of steps: send to Kafka, then save the bookmark. Suppose the connector crashes after Kafka confirmed a batch but before the bookmark was saved. On restart, the connector resumes from the older bookmark and sends those changes again. Consumers see the same events twice. This is called at-least-once delivery: nothing is ever lost, but a few events may repeat after a failure.

Making consumers safe

What about exactly-once?

Newer versions of Kafka Connect include support for exactly-once delivery for source connectors, and some Debezium connectors can use it. It reduces duplicates from the connector side but does not remove the need for careful consumers, because they can still crash and reprocess. Treat it as a helpful extra, and check the documentation for your connector and version before depending on it.

When the saved position is gone

If the connector was down so long that the database has already deleted the log section it needs, the bookmark points to nothing. Depending on the snapshot mode you chose, the connector either fails loudly or takes a new snapshot. Failing loudly is safer for data you cannot afford to duplicate or reorder, but it needs a human to decide what to do.

Where events land in Kafka decides what order consumers see them in. Get this right and many bugs never appear.

One topic per table

By default, each captured table gets its own topic, named from a prefix you choose, the schema, and the table. For example, a connector with the prefix “shop” watching the orders table in the sales schema writes to a topic named like shop.sales.orders. Consumers subscribe only to the tables they care about.

The key decides the partition

The event key is the row’s primary key. Kafka uses the key to choose the partition: the same key always goes to the same partition. Since a partition is an ordered log, all changes to one row are delivered in the order they happened. That is the ordering promise you can rely on.

Why cross-table order is not guaranteed

An order and its order lines live in two tables, so they land in two topics, each with its own partitions. A consumer reading both topics may see a line before its parent order. To handle this, consumers should tolerate arrival in any order, or use the transaction details in the event to group related changes. A later chapter shows options.

Log compaction: keeping only the latest

A topic can be set to keep just the newest event for each key, discarding older ones. This is called log compaction. For a CDC topic it means the topic becomes a compact copy of the table’s current state: one event per row. New consumers can read it from the start to rebuild the full table quickly. Tombstones make deleted rows disappear eventually.

The special history topic

Some connectors, such as MySQL, also write table structure changes to a separate schema history topic. It must be a single partition and must keep its data forever, because the connector reads it on restart to understand old log entries. Losing it is serious. Protect it with a high replication factor and no automatic deletion, and never share it between connectors.

Before diving into each pattern, here is the whole map in one place. Every pattern answers a different question about moving data.

The most popular CDC use is also the easiest to understand: keep a second copy of data, shaped for fast reading, in step with the database.

Databases are built to store and protect data. They are not always the best at searching text or serving millions of quick lookups. So teams copy data into a search engine for full-text queries, or into a cache for lightning-fast reads. The challenge is keeping the copy up to date.

The old way and its pain

Without CDC, the application updates the database and also tries to update the index or cache. Two writes, two chances to fail. When one fails, the search page shows a product that no longer exists, or a price that changed yesterday. Nightly rebuilds patch over the problem but leave hours of wrong data.

The CDC way

Details that matter

This is the pattern that solves the dual write trap from the first chapter. It is the most valuable idea in this guide.

A microservice often needs to do two things at once: save data in its own database and announce that something happened to other services. For instance, an order service saves a new order and tells the shipping service. Doing both separately can fail halfway. The outbox pattern fixes this by making the announcement part of the database transaction.

flowchart LR
  subgraph Svc["Order Service"]
    API["Business logic"] --> TX["One database transaction"]
  end
  TX -->|"writes order row"| ORD[("orders table")]
  TX -->|"writes event row"| OUT[("outbox table")]
  OUT --> LOG["Transaction log"]
  LOG --> DBZ["Debezium with Outbox Event Router"]
  DBZ --> T1["Topic: order events"]
  DBZ --> T2["Topic: payment events"]
  T1 --> SHIP["Shipping Service"]
  T1 --> MAIL["Notification Service"]
  T2 --> BILL["Billing Service"]
    

How it works

Why teams like it

Housekeeping and duplicates

Outbox rows pile up. Debezium reads them from the log, so the service can delete each row right after inserting it, in the same transaction. The insert is still recorded in the log, but the table stays tiny. Since delivery is at-least-once, consumers may see an event twice, so each event carries a unique ID that consumers use to ignore repeats.

Microservices should own their data. But services still need each other’s facts. CDC lets them share without sharing a database.

In a well-designed system of small services, each service has its own private database. The customer service owns customers. The order service owns orders. But the order screen needs to show the customer’s name. Calling the customer service on every request is slow and makes the order service fail whenever the customer service is down.

Local copies from events

With CDC, the order service keeps its own small local copy of the customer fields it needs, such as name and shipping city. It fills and updates this copy by listening to the customer topic. Now showing an order needs no call to the customer service at all. The copy may lag by a moment, but it is always available.

Read models and CQRS

A read model is a copy of data shaped exactly for one screen or report. The idea of separating writing models from reading models is often called CQRS, short for command query responsibility segregation. CDC provides the feed: changes from several write databases are combined by a stream processor into one read table that answers a specific question quickly, like “show every order with its customer and delivery status”.

Expose events, not tables

Use the outbox pattern for data the owning service wants to share as a contract, and use raw table capture only within a team or for non-critical copies. A raw table capture couples other teams to your table layout.

Replacing a big old system in one weekend is a famous way to fail. CDC lets you move piece by piece while both systems stay in step.

The strangler fig approach is named after a vine that slowly grows around a tree until it replaces it. In software, you build new components beside the old system and move traffic across gradually, until the old system has nothing left to do.

The same idea helps with database upgrades and moves between database products or cloud providers. The old and new databases stay in sync through the stream, you switch when ready, and you keep the ability to switch back.

Databases forget. When a row is updated, the old value is gone. CDC remembers what the database forgets.

Many businesses must answer questions like “who changed this price, and what was it before?” The database only holds the current state. Because every event has both a before and an after, a CDC stream is a natural audit trail. Store the events in a durable place, and you can replay the full history of any row.

Who did it?

The log knows what changed but not who changed it, because the database only sees the application’s shared login. To capture the human, have the application store the user in a column such as “last updated by”, or add context to the transaction. Debezium can then include it in the event. Some setups also write a separate metadata row per transaction with user details.

Where to keep the history

A Kafka topic with long retention works for shorter horizons. For years of history, sink the events into cheap object storage or an append-only table, and partition by date. Protect it with strict access, since it holds every past value, including ones the main database deleted on purpose.

Analytics teams have long lived on yesterday’s data. CDC brings them minutes-old data without hammering the source database.

A data warehouse is a system built to answer big analytical questions over lots of history. A data lake stores raw files cheaply and lets many tools read them. Both traditionally received data through nightly bulk extracts. Those extracts read entire tables, load the source database heavily, and deliver stale numbers.

Streaming replaces the nightly copy

With CDC, the warehouse receives a steady trickle of changes. A sink connector writes them into the warehouse or lake as they come, in small batches. The source database sees no extra queries, and dashboards are minutes old instead of a day old.

The delete and update challenge

Analytical storage is often append-only. It is happy to add rows but reluctant to change or remove them. To keep an accurate current picture, there are two common approaches.

Many teams do both: keep the raw change log as a permanent record, and maintain a merged current-state table on top of it.

The raw envelope is rich but heavy. Small transforms let you trim, route, and filter events before they reach Kafka.

A single message transform, or SMT, is a small step that Kafka Connect applies to each record, one at a time, as it passes through. You can chain several. They are ideal for light reshaping, but they are not meant for heavy work like joining streams. For that, use a stream processor.

When to unwrap, and when not to

Unwrapping is convenient, but it throws away the before state and some source details. If a consumer needs to know what a value was before, or needs the exact log position, keep the full envelope. A common design is to keep raw envelopes in the main topics for careful consumers, and let simple sinks apply the unwrap step on their own side.

Tables change. Columns are added, renamed, and dropped. Your event streams must survive that without breaking every consumer.

Every change event has a shape, called a schema: which fields exist and what type each is. Consumers rely on that shape. When the source table changes, the shape of new events changes too. Managing that gracefully is called schema evolution.

Choosing a format

A schema registry is a service that stores every version of every schema and can refuse a new version that would break existing consumers. For production CDC, a compact binary format plus a registry is the usual choice.

How table changes appear

The compatibility rulebook

Decide a compatibility mode with your registry. Backward compatibility means new readers can read old data. Forward compatibility means old readers can read new data. Full means both. For CDC topics that consumers replay from the start, backward compatibility is the minimum, because new consumer versions must read events written long ago.

PostgreSQL is a favorite for CDC, and it has one famous hazard. Understanding it can save you a midnight outage.

PostgreSQL exposes changes through logical decoding, which turns its internal write-ahead log into readable row changes. Debezium connects using a replication slot, a named marker inside the database that says “this reader has consumed the log up to here, so keep everything after it”. A publication lists which tables are shared with that reader.

Key setup points

The slot that fills the disk

Because the slot promises to keep all log data after its position, a slot whose reader has stopped forces PostgreSQL to hoard log files without limit. Disk space shrinks steadily until the database itself stops. This is the most common serious CDC incident on PostgreSQL.

Other gotchas

Very large column values stored out of line, known as TOAST values, are omitted from update events when they did not change. Debezium then inserts a placeholder, and consumers must not overwrite real data with it. Failover is another concern: slots have traditionally lived only on the primary server, so after a failover to a replica the slot may be missing. Newer versions add ways to keep slots in step on standby servers, but plan and test your failover carefully.

Each database has its own quirks. Here are the ones that trip up teams most often.

MySQL and MariaDB

The MySQL connector reads the binary log. It needs the log in row format with full row images, so each entry holds the complete changed row. The connector poses as a replica, so it needs a server ID unique among all replicas and readers, or two readers will kick each other off. The database user needs replication and read rights.

SQL Server

SQL Server has its own change data capture feature, which copies changes into special change tables using an agent job. Debezium reads those tables. The feature must be turned on for the database and each table. Because of the extra step through change tables, there is a small extra delay and extra storage. Cleanup jobs delete old change table rows, so make sure they do not remove entries before the connector reads them.

Oracle

Oracle capture reads the redo log, most often via LogMiner. It needs archive logging on, supplemental logging turned on for the captured tables, and a carefully privileged user. Oracle has licensing and performance considerations, and very high volumes may need a different reader. Plan Oracle projects with extra care and read the connector guide closely.

MongoDB

MongoDB capture uses change streams built on its operation log, and needs a replica set or a sharded cluster. Events describe documents rather than rows, and updates can be delivered as changes or as whole documents depending on settings.

A database transaction changes several rows at once, all or nothing. In Kafka, those changes scatter across topics. Here is how to put the story back together.

When an order is placed, one transaction might insert an order row, three order line rows, and update a stock count. In the log these are one atomic unit. In Kafka they become five separate events on three topics with no guaranteed arrival order. A consumer that reads them independently may see a line without its order, or a stock change before the order it belongs to.

Three ways to cope

The single-partition option

If you must have a strict global order, you can route related tables into one topic with one partition. This preserves order but limits throughput to one consumer, so use it only for small, critical flows.

A single log is a single story, and a single story is read by one reader. That shapes how CDC scales.

One task per connector

The transaction log is one ordered sequence, so most Debezium connectors run a single task to read it in order. You cannot speed up one connector by adding tasks. This surprises people who are used to Connect connectors scaling out.

How to scale anyway

Things that slow capture down

A quick sizing sense

Suppose a database sees 2,000 row changes per second at peak, and each event is about 1 KB with the envelope. That is roughly 2 MB per second, about 170 GB per day before compression, well within what a single connector can handle. Storage in Kafka then depends on retention. With three copies and seven days, the topics hold roughly 3.5 terabytes at that rate uncompressed, so compression and compaction matter.

Everything fails eventually. What matters is what happens next, and whether you lose data, get duplicates, or simply pause.

What keeps running, and what does not

A CDC pipeline has many parts, and each can fail on its own. The good news is that the design is forgiving: the log is durable, the bookmark is stored in Kafka, and Kafka itself is replicated. Most failures mean a pause and a catch-up, not lost data.

flowchart TD
  F["Something fails"] --> Q1{"Which part?"}
  Q1 -->|"Connect worker"| W["Another worker takes over the connector"]
  W --> W2["Resume from saved offset, possible duplicates"]
  Q1 -->|"Kafka broker"| K["Replicas take over leadership"]
  K --> K2["Producer retries, brief delay"]
  Q1 -->|"Source database down"| D["Connector retries connection"]
  D --> D2["Resume from same position when database returns"]
  Q1 -->|"Database failover"| FO{"Same log positions on new primary?"}
  FO -->|"Yes, with global IDs"| FO1["Reconnect and continue"]
  FO -->|"No, slot or position lost"| FO2["Re-snapshot or manual repair"]
  Q1 -->|"Log already purged"| P["Saved position no longer exists"]
  P --> P2["Take new snapshot and rebuild consumers"]
    

Scenario walk-throughs

Design for the gap

Assume the pipeline will sometimes pause. Downstream systems should treat the data as “eventually current” and show or use the age of the data when it matters. Provide a way to rebuild any consumer from a snapshot or a compacted topic, so recovery is a routine action instead of an emergency.

By design, CDC copies every change to every captured table into a place where many people can read it. That deserves real care.

A CDC stream holds complete rows, including names, emails, and possibly financial or health details. Kafka topics also last longer than a single query would. Treat every CDC topic as if it were the database itself.

Protect the door into the database

Protect the data in the stream

The worst CDC failure is a silent one. The connector looks healthy while data quietly stops flowing. Good monitoring catches that first.

The metrics that matter

The end-to-end freshness check

Connector metrics can look fine while something else is broken. Add a simple test: a heartbeat table that a small job updates every minute, and a check that the update reaches the far end within an agreed time. This measures the whole path, not just one piece, and catches problems nobody thought to monitor.

Logs

Connector logs explain reconnects, snapshot phases, and structural changes. Keep them, and search them for repeated warnings. Set up dashboards that show per-table event rates, so a table that suddenly goes quiet stands out.

Troubleshooting guide

Log-based CDC with Debezium is powerful, and it is not free. An honest view of both sides helps you decide well.

Comparing the capture approaches

Core trade-offs

Shapes that work, and shapes that look fine until they fail.

Patterns worth copying

Anti-patterns to avoid

A checklist to walk through before going live, followed by the mistakes that catch most teams on their first attempt.

Before you go live

Common mistakes

A careful order of steps turns a risky launch into a boring one.

What the connector needs to know

At its core, a connector needs to know how to reach the database, which user to use, which tables to include, what name prefix to give topics, where to store structure history if required, which format to use for keys and values, and which transforms to apply. Keep these settings in version control and review changes like code.

Running Connect well

A safe rollout order

The interesting bugs appear during failures and structural changes. Test those on purpose.

Test with real containers

It is easy to spin up a database, Kafka, and Connect in containers on a laptop or in a build pipeline. Write automated tests that change rows and check the events that come out. Then wire in your consumers and confirm the end result. Tests like these catch surprises in connector upgrades before your users do.

A made-up story to tie everything together. The company, Northwind Books, and its teams are fictional.

Northwind Books started with one application and one PostgreSQL database. As it grows, the search page is slow, the recommendations are stale, and the finance team’s reports arrive a day late. The engineers decide to adopt CDC with Debezium on Kafka.

What the story teaches

How organizations of different shapes typically use Debezium. These are common industry patterns, described in general terms, not claims about any single company’s private setup.

The microservices company

Teams that split a large application into many services almost always meet the dual write problem, and the outbox pattern with Debezium is a widely used answer. Each service keeps its own database and publishes business events through its own outbox. Other services react to those events rather than reading each other’s data.

The modernizing enterprise

Large organizations with long-lived databases use CDC to escape batch integration. They stream changes from core systems into Kafka, then feed new digital products, analytics platforms, and cloud data stores from the same stream. The old system stays untouched, which is exactly what risk-averse teams want.

The analytics-first team

Data teams use Debezium to replace nightly extracts with continuous feeds into warehouses and lakes. They value that the source database is no longer hammered by big queries, and that fresh numbers arrive within minutes.

The cloud migration project

Teams moving databases between data centers or cloud providers use CDC to keep old and new in sync while they shift applications gradually. When every application has moved, they switch off the old database with confidence.

The platform team

Some companies offer CDC as an internal service. Application teams request a capture, and the platform provides connectors, topics, schemas, and monitoring in a standard way. Standard naming, ownership records, and default security rules turn CDC from a specialist project into an everyday tool.

Every important word from this guide in one place.

Short, direct answers to the questions people ask most often.

You now have the full picture, from the first row written to the last consumer reading it.

Change Data Capture turns a database from a silent island into a source of live events. Debezium reads the database’s own transaction log, turns each change into a structured event, and sends it through Kafka Connect into Kafka, where any number of consumers can use it at their own pace. The patterns built on top, such as fresh search indexes, the outbox, local copies for services, gradual migrations, audit trails, and analytics feeds, all share the same foundation.