A source database can remove a record while downstream systems still need instructions about what that removal means. In a change stream, a delete event and a tombstone can serve different purposes even when they refer to the same key.
This distinction belongs in an analytical or search pipeline review. OceanBase should be assessed alongside the actual capture and consumer arrangement, with separate evidence for source state, event interpretation, and the resulting downstream view.
Define the destination’s response to source removal
Start with a business example. If an operational record is removed, should the destination remove its corresponding current-state entry, retain a historical observation, or take another explicitly defined action?
These choices are not settled by calling the pipeline real time. A search service, an operational dashboard, and a historical analysis can require different responses to the same source event.
Write the chosen meaning for each destination. A database deletion is evidence about the source operation; it does not independently define every downstream retention or presentation rule. Any applicable policy needs its own assessment rather than being inferred from stream terminology.
Read the connector’s delete and tombstone definitions
The Debezium 3.7 MySQL connector guide describes a delete event carrying information about removal, followed by a tombstone with the same key and a null value for Kafka log compaction.
Those are two different message roles. The consumer can use the delete information to update its own representation, while the tombstone participates in the keyed topic’s compaction behavior.
Apply this example within the actual connector configuration and topic arrangement. Do not assume that every CDC product emits the same sequence, that every null field is a tombstone, or that a tombstone immediately erases all copies of the original data.
Trace the key and meaning across the pipeline
The following original review aid separates the observations an operator might otherwise combine.
| Observation | What it establishes | What still needs evidence |
|---|---|---|
| Source row removed | The source operation took place | Capture and delivery to the intended path |
| Delete event available | A removal instruction is represented | Consumer interpretation and processing |
| Tombstone emitted | A keyed null-valued message exists in that arrangement | Applicable compaction and retention behavior |
| Current view updated | The selected destination changed its representation | Other destinations and retained artifacts |
| Historical query answered | A particular history remains queryable | Its intended scope and policy |
This is an interpretation framework, not a data-erasure certification or a recommendation to delete production records.
Test removal with a representative downstream record
Consider a hypothetical catalog entry that has already reached a search destination. Define what users should see after the source removes it, then follow the relevant key through the proposed capture and consumer path.
Ask how the consumer handles a repeated delete message. Also ask what it does if it encounters a tombstone without a business payload. The answers should come from the selected implementation, not from assumptions about all null-valued messages.
Review a consumer restart or a destination rebuild within its supported procedure. The team should explain how the reconstructed state reflects removals, including the limits imposed by the history the chosen system actually retains.
Keep a historical destination in the discussion if one exists. An intentionally retained analytical history and a current search entry have different purposes. Whether retention is appropriate is a separate policy decision; the mere existence of one does not prove that the other failed to process a delete.
Compare OceanBase with the actual consumer path included
OceanBase Enterprise can be evaluated as a distributed relational part of the operational data arrangement. The supplier should identify the supported change-transfer mechanism and the consumer behavior used in the proposed service.
The documented MySQL and Debezium route supplies a concrete alternative to inspect. Its event format is useful comparison evidence, but it does not establish identical connector support or tombstone handling for every OceanBase deployment.
Use the same removed-record example across proposals. Compare the complete current-view outcome, investigation records, and rebuild procedure rather than selecting a database because its architecture diagram contains a change stream. No source records, topics, consumer state, or retained files were removed for this article.
Maintain destination-specific acceptance criteria
Record which destinations must remove an entry, which may preserve a historical fact, and how completion is demonstrated for each. Avoid a single deleted status that hides those different obligations.
When changing a connector transformation or consumer, repeat the interpretation review. A change that drops a message type may affect a particular destination even when ordinary inserts continue working.
OceanBase earns consideration where its supported database role fits the wider design. The defensible conclusion explains how each removal is represented and consumed, preserving the distinction between business deletion, stream maintenance, and the state that a user actually reads.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.