Debezium Change Data Capture (CDC) converts selected database row changes into change events that applications can process. It can establish an initial picture of source tables and then read later changes from the database’s transactional log. However, an initial snapshot is not a complete history of every earlier edit. A captured DELETE event is not proof that every downstream system removed the row. A connector showing RUNNING is not, by itself, evidence that consumers have applied all changes.
If you want to understand Debezium PostgreSQL WAL replication, MySQL binlog CDC, initial versus incremental snapshots, Debezium event envelopes, tombstone messages, schema history topics and connector signaling, this guide gives a direct practical explanation. Separate what happened in the source database, which log position Debezium reached, what event the connector emitted and how the destination ultimately applied that event. These stages can advance at different times and have different recovery rules.
We will use a fictional international education service that maintains anonymous course registrations. Source rows can be inserted, updated or removed, and a research warehouse wants an accurate current-state table. Sometimes the source becomes unavailable, its log retention approaches a limit or a user requests an incremental snapshot for only a few tables. These examples use invented identifiers and emphasize safe reasoning rather than instructions to change a live database.
Quick answer: does Debezium copy every change?
Debezium reads supported database changes through connector-specific CDC mechanisms after it establishes a suitable initial or resumed position. A new connector can take an initial snapshot of current records and then stream changes from the appropriate log position. It is not necessarily able to reconstruct source rows deleted before that starting point. Nor can it continue from a source-log position whose required log segment has been permanently removed. A correct recovery plan must consider the database connector, offset history, source retention and sink state.
Keep technical strings such as connector name, topic.prefix, snapshot.mode, signal.enabled.channels, source table identifiers, LSN, binlog file positions, before, after, op, ts_ms, snapshot flags, transaction IDs and Kafka topic names literal inside code and logs. Translate descriptions around them without changing the machine contract. A message that is structurally valid may still reflect incomplete source coverage or a late downstream transformation.
1. CDC records changes after a defined source position
Change Data Capture is the process of observing relevant changes in source data and making those changes available to downstream systems. Database-log-based CDC reads transaction records or logically decoded changes rather than repeatedly comparing every table row to a past copy. The exact feature and event coverage depend on the source database and Debezium connector.
Suppose registration EDU-1001 changes from pending to approved after Debezium begins reading its source log. The connector can emit a corresponding change event when supported. But if the status had changed three times before the connector ever started, an initial snapshot may only show the current value. Translate “CDC enabled” as ongoing change observation from a defined baseline, not unlimited retrospective reconstruction.
2. A connector is specific to its source database
Debezium has connectors for supported databases, including PostgreSQL and MySQL, with different underlying log technologies, setup requirements and data-type behavior. A configuration valid for PostgreSQL logical decoding is not automatically correct for MySQL binlog or SQL Server change tracking. Product names should be retained and version context checked.
A global education platform might store registrations in PostgreSQL while an older course catalog lives in MySQL. Both can feed change events, but their log coordinates and snapshot rules differ. An error about a missing PostgreSQL replication slot should not be translated as a MySQL binlog permission problem. Technical accuracy begins by naming the source platform.
3. A database transaction is not the same as one change event
One source transaction can insert or update several rows across related tables. Debezium can emit row-level change events and optional transaction metadata under supported configuration. The number of events does not necessarily equal the number of business transactions or the number of learners affected.
A course enrollment action might update a seat counter and insert a registration row in the same database transaction. Two row events may describe one intended registration. Counting both as two new learners would be wrong. Translate “row change emitted” differently from “enrollment created”. Business-level analysis should follow the correct entity identifiers and transaction boundaries.
4. An initial snapshot establishes a current-row baseline
An initial snapshot reads eligible source tables to create a starting representation of their contents, using connector-specific consistency and locking mechanisms. The connector then streams changes from an appropriate log position so updates occurring around snapshot time are not silently skipped under its supported workflow. That is a baseline-building process, not proof that every earlier historical version was captured.
If the source currently contains 500 anonymous enrollments, the snapshot can make those current rows available to the destination. It cannot automatically disclose every prior withdrawn enrollment if the source no longer stores those histories. A translated “initial snapshot completed” message should state the observed current-row coverage and the handoff to streaming, not “all past enrollment activity archived”.
5. Snapshot modes control startup behavior
Debezium connectors provide snapshot.mode options with names and availability depending on connector and version. Modes govern when or whether an initial snapshot runs and what happens when no offset is available. A no-data snapshot mode may capture schema information without reading full table data, while other modes follow their own semantics.
A support page that says “snapshot disabled” must clarify whether current data were intentionally omitted, whether streaming continues and what schema history is expected. Copying an old configuration list into a newer connector guide is unsafe when option names have evolved. Retain the literal option value and consult the documented release before telling operators what state the destination will contain.
6. Snapshot records and change-stream records differ
A snapshot event represents an existing source row observed as part of a snapshot process. A streaming event records a change that occurred through the source log. Their envelope metadata can identify this distinction. Two events describing the same business key at different stages do not necessarily mean two new registrations happened.
An initial snapshot may output the current state of registration EDU-1001, and a later update event may output its approved status. A destination should apply them according to its ordering and upsert policy. Translate “snapshot read” as baseline data and “update event” as a later mutation. This prevents raw message counts from inflating business totals.
7. Event envelopes separate before and after values
Debezium change events commonly include a before structure for previous row values and an after structure for resulting row values where the connector and operation provide them. Operation metadata helps explain whether the event is a create, update, delete or snapshot read. These fields are part of a machine-readable event contract.
For a status update from pending to approved, before may show pending and after may show approved. Neither is a separate new learner. A translator should never rename literal JSON keys inside examples while claiming the payload is unchanged. Explain the semantics in nearby prose and ensure downstream code receives the original protocol structure.
8. The op field identifies the operation category
Debezium event operations include codes such as c for create, u for update, d for delete, and r for a snapshot read under relevant connectors. These codes are not alphabetic abbreviations a translator can freely replace. They are protocol values interpreted by consumers.
A current-state sink can use these codes to decide whether to insert, update or remove a row. A history sink might preserve the event with the original operation category. If a report treats every r or u event as a new enrollment, it may overcount. The correct documentation explains what the code means and what the destination should do, without changing the literal event value.
9. A delete event is not always the same as a tombstone
A Debezium delete event can include the old row identity and an after value indicating removal. Debezium may also emit a separate tombstone message with a null value for compacted Kafka topic handling, depending on configuration. The tombstone helps downstream log compaction represent a removed key; it is not necessarily another source DELETE.
Our fictional database removes registration EDU-1001. The connector may produce a delete change event and a following tombstone with the same key. Counting those as two separate enrollment cancellations is wrong. Translate “delete event” and “compaction tombstone” distinctly, and explain the purpose of each within the messaging system.
10. Tombstones do not prove every copy was erased
A null-valued tombstone can influence Kafka compaction and the state reconstructed from a compacted topic. That does not automatically remove historical archives, secondary stores, backups or already delivered reports. A translated “tombstone published” label must not claim universal privacy deletion.
For sensitive data, the organization needs an independently verified retention and erasure process across relevant destinations. A tombstone is one change in one event stream. Describe that narrow effect accurately, and do not make a compliance guarantee without evidence about all copies and systems.
11. PostgreSQL uses logical decoding and WAL positions
The Debezium PostgreSQL connector consumes change information using PostgreSQL logical decoding of its Write-Ahead Log (WAL), with replication slot and publication configuration under supported versions. LSN positions identify progress in the log; they are not timestamps, course numbers or records that should be localized.
If a connector resumes from a saved LSN after interruption, it can continue from the retained WAL position under the supported recovery model. A translated “WAL caught up” status refers to a particular source stream position and observation time. It does not guarantee that the downstream warehouse has applied every message or that every school submitted complete data.
12. Replication slots have source-storage consequences
A PostgreSQL logical replication slot can retain WAL needed by a consumer until the consumer advances or the configured limits and server behaviors intervene. A stalled consumer can therefore contribute to source storage growth. Translating “replication slot retained” as “safe backup stored” is dangerous; the slot serves streaming continuity and can threaten capacity if neglected.
An operator notices growing WAL storage during a connector outage. The right response is to inspect slot lag, source retention, disk limits and a safe recovery plan. Dropping a replication slot without considering lost CDC position can make incremental recovery impossible. A reader-friendly guide states what would be lost and what reconciliation would then be required.
13. MySQL binlog positions serve a different log mechanism
The MySQL connector uses the binary log under its supported configuration. Binlog file positions and GTIDs, when enabled, help describe source change progress. They are not equivalent to PostgreSQL LSNs even though both locate changes. Permissions, log format and retention rules differ.
A troubleshooting guide must not prescribe a PostgreSQL publication fix for a MySQL connector’s missing binlog. Preserve literal connector-specific fields and describe where to inspect source health. If binlog segments needed for recovery have expired, a new snapshot or other controlled resynchronization may be required. Translate the failure as “required source log position unavailable” rather than “all enrollment data deleted”.
14. Source timestamps and connector timestamps are separate
Debezium event envelopes can contain timestamps related to source change times and connector processing. Their exact fields and precision depend on version and source. A timestamp showing when the connector processed a row does not necessarily say when the learner changed the course selection. Business event time, source transaction time and capture time may differ.
An offline upstream service may commit a change after receiving a delayed request. The report should define whether it groups by occurrence time, database commit time or ingestion time. Translate each clock’s meaning rather than calling every timestamp “registration date”. This avoids incorrect temporal conclusions from otherwise valid CDC events.
15. Snapshot streaming handoff needs consistency controls
During initial snapshotting, the source database may continue receiving changes. Debezium connectors use documented techniques to coordinate the initial view with the log-streaming position, but the details differ by source and snapshot mode. The phrase “snapshot complete” does not guarantee that a downstream consumer has already processed all intervening changes.
For our research system, one row can be read during snapshotting and then updated again before the snapshot finishes. The event processor must preserve the relevant ordering and latest-state semantics. A localized support article should distinguish captured baseline, source changes during capture, emitted events and target application. That sequence explains why duplicate-looking keys can be expected during a controlled transition.
16. Incremental snapshots can backfill selected rows while streaming continues
Debezium supports ad hoc incremental snapshots through the signaling mechanism on eligible connectors. Instead of taking one all-at-once snapshot, it reads data in chunks and coordinates with ongoing streaming so the change feed can continue. This can help capture newly added tables or repair certain selected data gaps with less disruption than a full blocking snapshot.
Suppose a new anonymous course-category table is added to the allowed capture list. An incremental snapshot can populate its existing rows while other captured tables continue streaming. The team must specify the correct data collections and connector capabilities. A translated “incremental snapshot initiated” status does not yet prove all requested chunks finished or the destination reconciled them.
17. Snapshot chunk size affects resources and progress
Incremental snapshotting divides eligible rows into chunks, usually coordinated using a stable primary-key order or connector-specific mechanism. Chunk sizing influences memory, query load and how many progress cycles are needed. Smaller chunks do not automatically make a snapshot semantically more accurate, and larger ones do not necessarily make it complete faster.
For a source with millions of rows, an operator may tune chunk size after observing database load and snapshot progress. A useful UI should show chunks completed, remaining scope and any errors. Do not translate “two chunks processed” as “two students registered”; chunk count is an implementation metric. Test snapshot behavior on synthetic tables before applying configuration changes to live sources.
18. Snapshot signaling is an instruction, not a completion event
Debezium signals can request actions such as execute-snapshot, stop-snapshot, pause or resume under current supported connector capabilities. The signaling channel could be a source table, Kafka topic or another supported mechanism. Submitting a signal does not automatically mean the requested snapshot finished. Progress notifications and connector metrics provide separate evidence.
A technician sends an execute-snapshot signal for two educational source tables. The system accepts the signal and begins work later. The translated message should distinguish “request recorded”, “snapshot started”, “chunks being read” and “snapshot completed”. Treating an accepted signal as final data validation can mislead readers and hide an interrupted snapshot.
19. Source signaling requires a configured channel
Debezium documentation explains that incremental snapshot signals often rely on a source signaling channel and its watermarking mechanism to coordinate snapshot reads with streaming events. Other channels may be available, but their support and retry behavior are not identical. A connector that accepts a Kafka signal does not necessarily have every prerequisite for source-table snapshot coordination.
For a school data platform, the engineer should verify the connector’s actual signal.enabled.channels setting, source permissions and expected signaling collection. If a command appears ignored, check whether its channel was enabled and whether the connector acknowledged it. Translate “signal submitted” separately from “requested action performed”. Configuration must be verified on the real deployment, not guessed from the format of a JSON message.
20. Incremental snapshot watermarks are not global event-time guarantees
Debezium’s incremental snapshot watermarking helps coordinate snapshot chunks with overlapping streaming changes, reducing inconsistencies such as duplicate or outdated rows under the supported algorithm. This watermark concept is different from Apache Flink’s event-time watermark, which helps time-window operators judge event-time progress. Using the same word does not make their meanings identical.
An enrollment changes while its row is being read by an incremental snapshot. The connector’s coordination prevents an old snapshot row from incorrectly overriding a newer streamed update in the intended capture sequence. That is the relevant guarantee. A translated guide should not claim that the watermark proves every school in the world delivered all data for a day.
21. Snapshot stop and pause are different operations
A stop-snapshot signal ends an eligible incremental snapshot operation under the supported mechanism. Pause and resume features can temporarily suspend and later continue work in capable connectors. None of those actions automatically deletes records already emitted or rolls back downstream warehouse updates. Operators must understand the current capture state and destination effects separately.
Suppose a database experiences high read load during a large backfill. A technician pauses an incremental snapshot rather than aborting it. The correct message is “snapshot paused; prior emitted chunks remain in downstream processing”. If the operation is stopped, restarting may require a new request and reconciliation. Translate each lifecycle control according to its actual consequence.
22. Notifications describe connector progress, not destination truth
Debezium supports notifications for certain snapshot lifecycle events, including started, paused, resumed, aborted and completed in relevant configurations. These help operators observe work. But a completed source snapshot notification does not guarantee that a downstream consumer has applied every emitted event and rebuilt its analytics table.
If the CDC connector finishes reading a new course catalog, the destination still needs to ingest the messages and validate the current rows. A localized status should say “snapshot source capture completed” and show a separate “warehouse application completed” milestone if the latter is actually confirmed. Source and sink progress are not the same clock.
23. Offsets are connector progress, not a business timestamp
Debezium connectors record source positions through the relevant offset storage mechanisms in their runtime. Depending on connector, these may include PostgreSQL LSNs, MySQL binlog positions or other source coordinates. The offset identifies how far the capture process progressed, not the actual date that a learner completed a course.
A connector can be caught up to the latest visible source-log position while a downstream topic consumer is several minutes behind. A correct technical status names both positions and their observation times. Translate “connector source offset advanced” rather than “all reports refreshed”. Do not round or reformat machine offsets into a local-language number string.
24. Connector status RUNNING is not a full end-to-end success verdict
Kafka Connect or another Debezium runtime can report a connector or task as RUNNING. That state is useful, but it does not by itself establish successful event delivery, destination processing or zero source lag. A connector may be connected yet making little progress, or may be capturing a subset of tables intentionally.
The research service should monitor source-log lag, errors, processed event rates, task health and consumer destinations. A translated green RUNNING badge should not say “every source record verified”. Ask whether the source has produced relevant new transactions and whether emitted events are being acknowledged by the messaging platform.
25. Source retention can make restart impossible at the old position
Debezium restart behavior depends on source log segments still being available for the saved offset. PostgreSQL WAL may be constrained by replication-slot retention settings, while MySQL binlogs follow their retention and purge policies. If required history is gone, simply restarting a Worker cannot reconstruct missing log entries.
Suppose a connector is offline for weeks while source changes continue. On return it requests a log position that no longer exists. The correct action is to assess a controlled new snapshot, current-state reconciliation and the limitations of lost historical changes. Translate “source position unavailable” rather than “every source record deleted”. The original database may still contain current rows even though some change history is unrecoverable.
26. Transaction metadata has a narrower scope than the source business
Some Debezium connectors can emit transaction metadata or boundary events under supported configuration. These help consumers understand which row changes were grouped in the same source database transaction. But one business process can span more than one database or external service, so a transaction ID does not automatically certify the completion of an entire registration workflow.
Our fictional application might reserve a seat in one system and send a confirmation through another. Debezium could capture the seat transaction, while the message provider remains unavailable. A translated “transaction committed” message should name the source database, not claim that every outside step succeeded. This distinction reduces erroneous customer assurances.
27. Event ordering depends on source transactions and topic layout
Debezium emits source changes in connector-defined order, but messaging topics, partitioning and downstream parallel consumers introduce additional ordering considerations. One cannot simply assume that all changes from every source database in different countries share one global sequence. Use source transaction order and stable entity identifiers to reason about causal changes.
If an approval arrives after a pending-status event for the same enrollment, the consumer must ensure its latest-state representation follows the intended order. A later wall-clock arrival from another partition may not be a later source transaction for that entity. A clear translation distinguishes “event emitted later” from “business state became later” and preserves sequence metadata.
28. Primary keys shape the destination’s latest-row interpretation
CDC events usually identify source rows by an appropriate key. Downstream systems depend on that identity to apply updates and deletes correctly. If an enrollment number is unique only within one campus, using the number alone as a global key can overwrite an unrelated campus record. Debezium does not automatically correct an incorrectly modeled business grain.
A source key might include campus_id and enrollment_id. The sink should use the appropriate composite identity. A translated field label should not misrepresent it as a globally unique learner ID when the source uses a different key scope. Testing two synthetic campuses with the same local enrollment number can expose the error before publication.
29. Log compaction changes how history is visible
Kafka topics receiving Debezium events may use compaction so a consumer can reconstruct a latest keyed state. That is not a guarantee that every intermediate update remains available as an independent audit event forever. Topic retention, compaction settings and downstream archival strategy determine the historical record.
For course-status monitoring, a compacted latest-state topic may be appropriate. For research requiring a complete chronological record of status transitions, the team may need a separate governed event archive. Translate “compacted state available” differently from “every past status transition retained”. One describes a recoverable state view; the other requires independent history-preservation evidence.
30. Schema history topics support decoding source changes
Certain Debezium connectors, notably MySQL, use internal schema history to interpret change events as source tables evolve. This is not equivalent to the user-facing topic containing row-change events. Its configuration, retention and recovery requirements can be essential for connector restart.
An operator who sees an internal schema history topic should not assume it is an optional duplicate of the course data and delete it to save space. Losing required schema history can prevent the connector from interpreting retained binlogs correctly. A translated warning should state the technical purpose and recovery risk. Keep internal topic names and configuration keys exact.
31. Database DDL is different from CDC row events
A database schema alteration is not the same thing as a row update. PostgreSQL logical decoding has limitations around emitting DDL operations as consumer-facing change events, and other connectors handle schema changes differently. A CDC consumer should not assume that changing a source table’s structure automatically produces a readable event equivalent to altering every existing row.
If a source adds a language_code column, downstream schemas and converters may need to evolve. A translation should distinguish “table definition changed” from “rows with new field values emitted”. The correct migration process checks compatibility, source connector behavior and destination consumers, not just whether the source database accepted an ALTER statement.
32. Schema Registry and Debezium serve different responsibilities
Debezium captures and emits source changes; a schema registry can help manage message schemas and compatibility for serializers and deserializers. Schema compatibility does not guarantee that the business values are accurate, and a registered schema does not create missing CDC events. The two technologies complement each other under a particular deployment.
For an anonymous enrollment message, a registry may confirm the updated field structure is compatible with the configured policy. It cannot prove the enrollment number belongs to the right campus or that a delayed delete was processed. A translation should explain the schema contract alongside the data-capture result without collapsing them into one “everything valid” status.
33. Heartbeats help observe progress during low activity
Debezium heartbeat features can provide evidence of connector progress or health in configurations where normal change events are sparse. Their exact effects, including any source-side query, differ by connector and setting. A heartbeat is not necessarily a business event and should not be counted as a new registration or source-row change.
A rarely updated course catalog might produce few real CDC messages. Heartbeats can help the runtime observe progress and retain manageable offsets under appropriate conditions. A translated metric should say “connector heartbeat” rather than “course update received”. This avoids artificial inflation of business activity from operational signals.
34. Delete handling must be verified downstream
One destination may apply a Debezium delete event to remove the current row, while another may retain the delete event in an append-only audit table. A search index or dashboard could remain stale until its own consumer acts. The source CDC emission is not a universal erase operation.
For registration EDU-1001, the database DELETE is captured, then the messaging layer carries its event, and the warehouse applies it. Each stage has a separate success condition. A localized confirmation should say precisely whether the row was deleted in the source, event delivered or current-state target updated. Stronger privacy assurances demand wider checks.
35. Source snapshots can create duplicate-looking keys by design
An incremental snapshot may emit a row that also changed while streaming continued. Correct connector algorithms and downstream ordering are intended to reconcile this overlap, but raw event logs can still contain repeated keys. A report counting each message as a brand-new enrollment would misread the data.
A synthetic row enters the snapshot at status pending and is updated to approved seconds later. The destination should present the latest state according to the consumer’s verified ordering and merge rules, not two distinct learners. A translated operator dashboard can show “snapshot read event” and “streaming update event” rather than two new registrations.
36. Exactly-once business effects require the whole pipeline
Debezium source capture and offset tracking provide important recovery properties, and Kafka Connect can support stronger delivery semantics in particular configurations. But the source log, broker, sink connector, warehouse transaction and business report form a larger system. A generic “exactly once” label is unjustified unless the specific end-to-end configuration and failure behavior have been tested.
A warehouse merge keyed by source identity can make repeated event deliveries safe. A notification service without idempotency can still send the same message twice after ambiguous acknowledgment. Translate “CDC event processed under this connector guarantee” rather than “every external side effect happened exactly once”. Readers deserve the true boundary.
Worked example: a missing WAL segment blocks CDC recovery
A PostgreSQL source runs for several days while its CDC connector is offline. WAL storage retention changes under pressure and the saved LSN is no longer available. On restart, the connector cannot resume from the old position. The current source table still has valid enrollments, but the full sequence of updates during the gap may be lost from accessible logs.
The support team compares authoritative current rows with destination data, identifies the unsupported historical gap and plans a controlled reinitialization. A new snapshot can establish the latest state but cannot necessarily reconstruct every intermediate transition. The translated incident report should distinguish “current state restored” from “all historic events recovered”.
Worked example: an incremental snapshot races with an update
An operator requests an incremental snapshot for a new campus source table while the system continues receiving updates. Registration EDU-204 is read in one snapshot chunk and changed shortly afterward. A reader sees two events for the same key and incorrectly concludes that two separate people enrolled.
The correct investigation checks snapshot metadata, source commit positions and the latest-state consumer’s merge logic. Debezium’s supported incremental snapshot watermark coordination helps manage the overlap; downstream processing must still apply the correct entity identity. Translate “snapshot overlap” as data-capture timing, not business duplication.
Worked example: a schema history topic is mistaken for disposable logs
A technician finds a low-traffic internal topic associated with a MySQL Debezium connector. Assuming it is redundant, they plan to remove it. The connector actually uses that topic to remember source schema evolution needed for decoding binlog events after restart.
A careful review identifies the internal topic’s purpose and retention requirements, then follows documented connector recovery guidance. The translated dashboard should label it “CDC schema history metadata” rather than “unused message archive”. Deleting apparently quiet infrastructure without understanding it can break the very recovery process users depend on.
A Debezium translation and recovery checklist
- Name the exact source database and connector release.
- Keep source log coordinates, topic names, connector configuration and JSON envelope fields literal.
- Distinguish initial snapshot, incremental snapshot and streaming events.
- Check whether snapshot.mode captures data, schema or neither under the deployed connector.
- Verify source log retention and connector offsets before a long outage or restart.
- Explain CDC operation codes and tombstones without counting them as independent learners.
- Check the signaling channel before sending execute-snapshot, stop or pause requests.
- Treat snapshot notifications as capture-progress evidence, not final warehouse reconciliation.
- Preserve transaction, primary-key and timestamp scopes when building a latest-state sink.
- Review schema history, DDL handling and downstream compatibility during migrations.
- Test delete, late update, restart, duplicate delivery and source-log expiration with synthetic data.
- Avoid exposing credentials or personal records in CDC payload examples and operational logs.
Frequently asked questions
What is Debezium CDC?
It is change capture from supported source databases, usually based on their transactional logs, emitted as events that other systems can consume. It does not automatically create complete histories from before monitoring began.
How is an initial snapshot different from an incremental snapshot?
An initial snapshot establishes current source-table baseline data when the connector starts under its configuration. An ad hoc incremental snapshot reads selected rows in chunks while streaming can continue under supported synchronization.
Is a Debezium r operation a new registration?
Not necessarily. It commonly identifies a snapshot read of an existing source row. Use the row identity and source context rather than counting every raw event as a new business action.
Why can a delete produce two Kafka messages?
A delete change event can be followed by a null-valued tombstone for compaction under configured behavior. That is not automatically two independent deletions.
Can Debezium restart after source logs have expired?
Not by ordinary replay from a position no longer retained. A controlled new baseline and reconciliation may be required, with acknowledged limits on reconstructing intermediate history.
Does a RUNNING connector mean the warehouse is current?
No. Source capture, event publishing, sink application and report refresh are different stages. Inspect their actual positions and timestamps separately.
Why does MySQL Debezium need schema history?
It can use retained schema history to interpret changes in binlog events as source table definitions evolve. It is not a disposable duplicate of the business payload topic.
Do source heartbeats mean new source rows?
No. They help signal connector activity or progress under its configuration. They should not be treated as learner or course events.
Does a schema-compatible event guarantee correct data?
No. Schema compatibility checks representation; domain accuracy, source completeness and entity identity require separate validation.
Can a tombstone prove personal data were erased everywhere?
No. It is a messaging mechanism relevant to one topic and its consumers. Full erasure requires independent verification of affected stores and backups under applicable policy.
Official sources and further reading
The authoritative Debezium PostgreSQL connector guide explains WAL, snapshots and offsets. The Debezium signaling guide covers incremental snapshots, signal channels, pause and stop behavior, and the Debezium notifications guide describes progress messages. Refer to the actual source connector’s documentation for source-specific limits and metadata.
For connected eduKateSG reading, start with Master Art of Translation, then compare Airbyte incremental sync and CDC and PostgreSQL replication and WAL. Related systems still require separate interpretation of source, transport and destination guarantees.
Conclusion: captured change is not an automatically correct report
A faithful Debezium translation distinguishes the current-row baseline, later source changes, log positions, emitted events and consumer-applied results. It does not turn connector health into proof of warehouse completeness or a tombstone into universal erasure. These differences help readers make safe recovery and reporting decisions while keeping the meaning of database changes intact.