One phrase, three different claims

When evaluating a change data capture tool, one of the first questions teams ask is whether it “supports” their database. It is a necessary question. But the answer often compresses several different ideas into a single label.

A support claim makes at least one thing visible: the connector has been designed and validated to work with the source under some defined conditions. Depending on the product, project, and stated support policy, that validation may cover connecting to the database, taking an initial snapshot, following ongoing changes, recovering from certain interruptions, or operating under additional scenarios.

The label alone rarely tells the reader how broad that validation was.

Three different dimensions tend to sit behind the same phrase:

  • Functional compatibility — the connector works with the database’s interfaces under the conditions that were tested.
  • Production reliability — the connector behaves correctly under the workload, topology, database version, and recovery conditions of a particular deployment.
  • Accumulated operational knowledge — what a team or community has learned through testing and production exposure about how that database behaves under CDC over time.

Their relationship is worth stating precisely:

  • Functional compatibility is necessary, but it does not establish production reliability.
  • Production reliability is specific to a workload, topology, database version, and operating environment. It does not establish reliability universally for every deployment of the same connector.
  • Accumulated operational knowledge can improve design, testing, and diagnosis, but it does not automatically prove that a current implementation is reliable.
  • Knowledge can transfer through people, test suites, incident records, and engineering practices, but it does not automatically transfer into a rewrite, fork, or new implementation.

None of this means support claims are dishonest or intentionally incomplete. It means the phrase compresses a great deal of scope into very little language—and the ambiguity lives in that compression.

Comparison of functional compatibility, production reliability, and accumulated operational knowledge when evaluating a CDC connector.
A “supports CDC” claim can rest on very different forms of validation. Evaluate the evidence behind the claim, not only the label.

Functional compatibility—the easiest dimension to check, and an incomplete answer on its own

Functional compatibility is the most visible dimension.

Can the connector authenticate and connect? Can it read existing data where an initial snapshot is required? Can it follow ongoing changes and represent inserts, updates, and deletes in a usable structure?

A basic compatibility test may focus on the happy path:

  • ordinary transactions;
  • no concurrent schema change;
  • no source failover;
  • a consumer that keeps up;
  • a clean restart under expected conditions.

This is a legitimate and necessary baseline.

More mature projects may test far beyond it. The important point is that the support label alone does not reveal how far the validation went.

The practical takeaway is not to distrust compatibility claims. It is to ask what was actually tested to produce the claim.

Validation of connect, snapshot, and stream behavior is different from validation under schema drift, failover, restart, backpressure, or unusually large transactions. Knowing which conditions were covered matters more than the label by itself.

Production reliability—conditions that emerge under particular workloads and topologies

Reliability is not a single property a connector either has or lacks. It is a set of behaviors under defined operating conditions, and each condition is worth examining on its own terms.

Schema change during an active stream

A column is added, dropped, renamed, or changed while the connector is actively streaming.

Does the connector detect the change? Does it continue emitting correctly structured events? Does it require a restart or manual intervention? How are downstream consumers informed that the source schema has changed?

This is a realistic operating condition in many long-lived production databases, not merely an edge case associated with poor system management.

Long-running or unusually large transactions

A batch job or long transaction may keep source-side state open for longer than usual. Depending on the database and connector design, this can affect:

  • transaction buffering;
  • memory consumption;
  • event visibility;
  • source log retention;
  • recovery time;
  • downstream latency.

Whether the connector handles the condition acceptably is specific to the workload and source behavior. A generic compatibility test may not exercise it.

Source failover and replica promotion

When the source database fails over and another instance becomes primary, what happens to the connector’s notion of where it stopped reading?

Can it resume from a valid position? Does the transition require reconciliation? Under what conditions could records be replayed, duplicated, delayed, or missed?

The answer depends on the database, replication topology, connector design, and recovery procedure. Testing it requires exercising the actual topology rather than inferring the result from a general support statement.

The boundary between initial snapshot and live streaming

Any CDC deployment that combines an initial snapshot with ongoing streaming must manage the transition between the two.

The system needs a defensible answer to a simple question:

How does it move from “the state captured during the snapshot” to “changes occurring from this point onward” without leaving an unexplained gap or overlap?

Snapshotting and streaming can each work correctly in isolation while the transition between them still produces duplicates, omissions, or recovery ambiguity.

Database-version differences

Two versions of the same database engine may differ in replication behavior, defaults, configuration requirements, or edge cases.

Version differences are not a failure class by themselves. They multiply the complexity of every other condition.

“Supports this database” and “has been validated against this database version, topology, and configuration” are therefore different claims.

A connector tested thoroughly against one combination of these variables has established something meaningful about that combination. It has not necessarily established the same result for another.

End-to-end delivery guarantees are not owned by the connector alone

It is tempting to ask whether a connector provides at-least-once or exactly-once delivery as though the answer were a single connector-owned property.

A connector can define its own reading, checkpointing, and recovery behavior. But the end-to-end result usually depends on several components acting together:

  • the source’s position or offset model;
  • the connector’s checkpoint;
  • processing state between capture and delivery;
  • sink-side transactional behavior;
  • acknowledgements between components;
  • retry handling;
  • downstream deduplication or idempotency.

A better set of questions is:

  • After a crash and restart, what could be duplicated?
  • What could be replayed?
  • What could be delayed?
  • Under which conditions could something be missed?
  • Which component owns each guarantee?
  • Where is deduplication or transactional coordination performed?

A statement such as “the connector provides exactly-once” is incomplete unless the scope and participating components are clearly defined.

Ordering: know what scope the guarantee actually covers

Ordering also needs a defined scope.

There are three different questions:

  • What ordering does the source provide? A source may provide ordering within a transaction log, partition, shard, or transaction without providing a single global order across independent streams.
  • What ordering does the connector preserve? The connector should make clear which source-provided ordering guarantees it retains.
  • Is stronger ordering reconstructed elsewhere? A processing or serving layer may introduce an explicit coordination, sequencing, or reconciliation mechanism to construct a stronger order.

A connector cannot describe a stronger source-wide order as simple preservation if the source does not provide that order. It may, however, participate in constructing one through an explicit mechanism of its own.

The distinction matters because a source and connector can both behave correctly while still failing to give a downstream consumer the ordering it expects. In that situation, the missing guarantee may never have been assigned to any component in the architecture.

Missing or changing primary keys: a modeling problem, not automatically a connector failure

Tables without a stable primary key—or with keys that change over time—create a difficult CDC condition.

But the underlying difficulty is primarily one of identity and data modeling:

How do you durably identify the same record across its history when the source itself does not provide a stable identifier?

A connector or downstream model may support configured composite keys, surrogate identifiers, before-and-after images, or other mechanisms. Those approaches can help, but they do not remove the underlying ambiguity in the source model.

Treating every identity problem as a connector failure often directs the solution toward the wrong layer.

The more useful questions are:

  • What identity information does the source expose?
  • What does the connector preserve?
  • What identity rule has the downstream model chosen?
  • How are deletes and key changes represented?
  • Is that decision explicit and stable enough for consumers to rely on?

Accumulated operational knowledge—the dimension a feature list cannot capture

Everything above can, in principle, be tested.

In practice, testing every possible interaction exhaustively is difficult. Production systems generate combinations that specifications and clean test environments do not always anticipate:

  • a particular transaction shape;
  • a particular failover sequence;
  • a schema change during an in-flight snapshot;
  • an unusual database configuration;
  • a source-version-specific behavior;
  • a retry path that interacts unexpectedly with downstream state.

This is where accumulated operational knowledge matters.

It is not a vague claim of “experience.” It is deeply technical knowledge:

  • which conditions have caused problems before;
  • what the failure looked like;
  • why it occurred;
  • what changed in the implementation;
  • what regression test was added;
  • what operational guidance was documented afterward.

This knowledge can accumulate through production incidents, deliberate edge-case testing, public issue histories, community contributions, and the test suites that grow from them. A feature list has no field that adequately represents it.

It is equally important to state what this knowledge does not prove.

Historical experience does not automatically establish that the current implementation handles the same condition correctly today. The lesson still needs to be encoded and validated against the code that now exists.

Knowledge can transfer through people, tests, documentation, and engineering discipline. It does not transfer automatically merely because a rewrite, fork, or new product addresses the same problem.

A framework for evaluating any CDC tool against your source

Instead of stopping at “does this support CDC for my database?”, ask:

  1. What specific conditions were validated behind the support claim?
  2. Was the connector tested only for basic connectivity and ordinary streaming, or under realistic production conditions for this source?
  3. How does it behave during a schema change while actively streaming?
  4. What happens during an unusually long-running or large transaction?
  5. What happens during source failover or replica promotion?
  6. If an initial snapshot is used, how is the transition to ongoing streaming handled?
  7. After a crash and restart, what can be duplicated, replayed, delayed, or missed?
  8. Which component owns recovery, deduplication, and transactional delivery?
  9. What ordering scope does the source provide, and what ordering scope does the connector preserve?
  10. If the table lacks a stable primary key, how is identity handled?
  11. Has this database version, topology, and workload pattern actually been exercised before?
  12. What evidence exists—tests, incident records, operating guidance, or documented recovery procedures—to support the claim?

The objective is not to produce one universal reliability score. It is to determine whether the evidence behind the connector matches the conditions your system will actually encounter.

A concrete way to see the gap

Consider two connectors from two different teams, both truthfully claiming to support CDC for the same database.

Both complete the same ordinary functional tests. They connect, read existing data where required, and stream normal changes correctly.

One has also been deliberately validated against a realistic recovery condition—such as source failover, restart and resume, snapshot-to-stream handoff, or a schema change during an active stream. The test is documented: what was done, what was observed, and what changed afterward.

The other has not yet been exercised against that condition.

Nothing has necessarily gone wrong with the second connector. It simply has less evidence for that scenario.

From the outside, both connectors can make the same truthful support claim. But the evidence behind the two claims is not equivalent.

This is not a story about one tool succeeding and another failing. It is a story about why identical wording can rest on very different amounts of validation.

Where mature open-source tooling can close much of the gap

None of this implies that a specialized or unified commercial product is required.

Mature open-source CDC projects can accumulate substantial operational knowledge through:

  • public issue histories;
  • shared testing;
  • community contributions;
  • regression suites;
  • operation across many independent environments.

For a team with strong knowledge of the source database and the resources to operate the connector directly, an open-source project may already provide the compatibility, reliability evidence, and accumulated operational learning the workload requires.

It should be evaluated using the same questions as any commercial product or internally built connector.

The relevant distinction is not open source versus commercial. It is the scope and quality of the evidence behind the implementation being considered.

Where this distinction matters most—and where a validated connector may already be sufficient

The distinction between compatibility, reliability, and accumulated operational knowledge becomes especially important when several of the following are true:

  • the source uses a non-default or heavily customized configuration;
  • failover or replica promotion is part of the expected topology;
  • transaction sizes or change volume are unusually high;
  • schema changes occur while the stream is active;
  • recovery requirements are strict;
  • the operational cost of missing, duplicating, or reordering changes is high;
  • the team has limited experience with the source’s replication mechanism.

A connector may be entirely sufficient when it has been validated against:

  • the actual database version;
  • the actual topology;
  • representative transaction sizes;
  • expected change volume;
  • relevant schema-change behavior;
  • the required failover and recovery scenarios.

A standard topology, stable schema, moderate workload, no unusual recovery requirements, and a team with real operational knowledge of the source replication mechanism may allow a mature open-source, commercial, or internally built connector to meet the requirement without additional infrastructure.

The validation is the point—not the brand of the tool or the wording on its landing page.

How we think about this at tapstate

At tapstate, we treat connector engineering as a source-specific knowledge problem, not only a code-completeness exercise.

Tapdata’s historical experience informs the questions, edge cases, and testing disciplines brought into Tapstate. But historical experience is not a substitute for validating each current connector against its supported source versions, topologies, workloads, and recovery conditions.

The principle applies to Tapstate in exactly the same way it applies to every other connector or platform discussed in this article: the evidence behind the current implementation matters more than familiarity with the problem alone.

Reliable capture is foundational, but it is not the final operational outcome. Changes still need to be transformed, maintained, recovered, and served as usable state.

Tapstate therefore treats Capture as one continuous responsibility alongside Transform and Serve.

The better follow-up question

“Does it support CDC for my database?” is a necessary first question, but it is not enough on its own.

The more useful follow-up is:

  • What conditions were tested?
  • What evidence supports the claim?
  • How closely do those conditions match my actual source, topology, workload, and recovery requirements?

That question applies whether the connector is open source, commercial, or built in-house.

A support label tells you where to begin the evaluation. The evidence behind it tells you how far you can rely on the answer.