Change Data Capture solves an important problem: it tells downstream systems what changed in a source database. But for many operational applications, knowing what changed is only the beginning. The application ultimately needs a current, queryable representation of what is true now.
Getting from one to the other requires more than capturing database changes. The changes must be ordered, transformed into the shape consumers need, applied to maintained state, and delivered through a system that can recover when the data path is interrupted.
That distinction becomes important when CDC moves beyond replication and analytics into operational workloads.
What does CDC actually give you?
Change Data Capture, or CDC, tracks changes made to a source system and makes those changes available downstream. Log-based CDC commonly reads the database transaction log and emits records representing inserts, updates, and deletes without repeatedly scanning entire source tables. Google Cloud describes CDC as the process of identifying and capturing source modifications, while Debezium exposes database row changes as ordered change-event streams.
A typical change event may tell you that an order row changed from:
status = pending
to:
status = paid
along with information such as the operation type, source, timestamp, and—in some CDC systems—the record state before and after the change. Debezium's event model is a good illustration: its change records contain operation metadata and row-level before/after state.
That is extremely useful.
But it still represents a change.
An application asking for an order does not usually want to replay every order event and reconstruct the answer itself. It wants an answer such as:
What is the current state of order ORD-1042?
That is a different responsibility.
CDC answers “what changed.” Operational applications often need “what is true now.”
Consider an order-management application.
The state required to make one operational decision may be distributed across an order database, payment system, fulfillment system, customer record, and support platform. Each system remains authoritative for the facts it owns, but no individual change event necessarily represents the complete situation the consuming application needs.
Tapstate describes Operational State as a continuously maintained representation of current enterprise reality: current rather than merely historical, incrementally updated, consolidated across operational systems, and shaped around the consuming workflow.
This creates a useful distinction:
CDC is therefore not “insufficient” in the job it is designed to do. The issue is that capture and application-ready state are different jobs.
The gap between a CDC stream and an application-ready state
Once a CDC connector produces changes, five additional concerns determine whether those changes become useful operational state.
1. Establish a reliable starting point
A continuous data path needs a baseline before it can keep anything current.
Depending on the source connector and use case, that may begin with an existing-data load or another connector-supported starting mode. After that baseline is established, the system must know where ongoing change processing should continue.
This is why production CDC systems expose concepts such as snapshots, source positions, offsets, or checkpoints. Debezium, for example, supports initial snapshots before continuing with captured changes, while Tapstate's architecture explicitly preserves source positions and checkpoints as part of the maintained data path.
Without a trustworthy handoff between baseline and continuing changes, “real time” is not enough—the downstream representation may simply be wrong.
2. Turn source-oriented records into consumer-oriented data
A database log reflects how the source database changed. An application model reflects what a consumer needs.
Those shapes are rarely identical.
A useful operational view may require filtering records, renaming or normalizing fields, enriching values, reshaping nested structures, or combining information into a representation that makes sense to the consuming workflow.
Even Debezium's documentation notes that its native change-event format can be too complex for some downstream consumers and provides transformations that reshape event records before they are consumed.
Tapstate treats this as a first-class stage rather than an afterthought. Its public product model places ordered, reviewable transformation between Capture and Serve so that source-oriented changes can become consumer-oriented records on the same data path.
3. Materialize changes into current state
A stream of mutations is not the same thing as a queryable current-state model.
Suppose a CDC stream contains:
INSERT order 1042 → pending
UPDATE order 1042 → paid
UPDATE order 1042 → shipped
The current operational answer is not the three-event sequence. It is the maintained representation in which order 1042 is now shipped.
Creating that representation means applying incoming changes to state according to explicit rules: which key identifies the entity, how updates are applied, how deletes behave, how fields are mapped, and what happens when source schemas change.
This is the materialization step.
The concept is not unique to Tapstate. Streaming databases and incremental materialized-view systems also use change streams to maintain results as new writes arrive.
Tapstate's architecture makes this responsibility explicit: source activity passes through ordered pipeline rules and updates a configured target representation using stable keys, mappings, delete handling, and schema-change policy.
4. Make maintained state usable by applications
Even correctly maintained state still needs a serving path.
For an analytics workload, the destination may be a warehouse or lakehouse optimized for scans and historical analysis. For an operational workload, the consumer may instead be an application, API, workflow, automation system, or AI agent that needs a current entity or situation at request time.
This distinction changes the architecture.
The deliverable is no longer merely a topic containing changes. It is a maintained result that downstream software can consume without reconstructing the entire data path itself.
Tapstate calls this Serve: materializing and delivering current state through supported targets so that multiple consumers can reuse the same maintained result.
5. Preserve enough operating state to recover
The happy path is only part of a production data path.
Connectors restart. Networks fail. Targets slow down. Processes are upgraded. A source or target may impose its own recovery constraints.
When that happens, the system needs to know where processing stopped and how to continue without simply guessing.
That means retaining more than data records. The operating path needs progress and diagnostic context such as positions, checkpoints, mappings, status, and retry information.
Tapstate explicitly includes this operating state in its architecture and describes recovery as resuming or retrying from a connector-supported known position while preserving the configured transformation and delivery behavior.
This is one reason production CDC is better thought of as an operating discipline than as a connector checkbox. Materialize's production CDC guide similarly treats snapshotting, streaming, resnapshotting, pipeline operation, and destination ownership as distinct parts of running CDC in production.
From CDC to operational state: the complete path
The resulting architecture can be summarized as:
Source systems → Capture → Transform → Materialize → Serve → Applications
Capture observes the source changes.
Transform converts source-oriented records into the shape required downstream.
Materialization applies those changes to a maintained representation.
Serving makes that representation available to operational consumers.
Across the entire path, positions, checkpoints, mappings, delivery rules, and recovery context keep the system operable over time.
Tapstate groups these responsibilities into a simpler product model:
Capture → Transform → Serve
The Serve stage includes materialization and delivery of the maintained result. Tapstate describes the platform as a unified operational data engine for this full path, with systems of record remaining authoritative and adjacent event or analytical systems retaining their own roles.
This is also the broader role of an Operational Data Platform: not simply extracting changes, but maintaining an operational data path that turns source-system truth into current data that applications can actually use.
Does this mean every CDC workload needs an Operational Data Platform?
No.
CDC alone can be the right abstraction when the desired output is the change stream itself, when another downstream platform already owns transformation and state maintenance, or when the use case is straightforward replication into a system designed to consume those changes.
Kafka and other event backbones also remain valuable when the primary requirement is event distribution, fan-out, replay, or decoupling producers and consumers. Warehouses and lakehouses remain the natural systems for many historical and analytical workloads.
Tapstate's own architecture draws these boundaries explicitly rather than claiming that one operational path should replace every adjacent data system.
The need for a broader operational-state path becomes clearer when the consumer requires a maintained, application-ready answer rather than a raw stream of database mutations.
A practical test: is CDC the destination or the beginning?
Ask what the downstream consumer ultimately needs.
If the answer is: “Give me every committed database change so another system can process it,” then CDC may be the deliverable.
If the answer is:
“Give me the current customer, order, inventory, entitlement, or account state so an application can act on it,”
then CDC is usually the first stage of a larger state-maintenance problem.
That larger problem includes transformation, keys, deletes, schemas, materialization, serving, progress tracking, and recovery.
The architectural question is therefore not whether CDC matters.
It is where the responsibility of CDC ends—and who owns everything that comes next.
Where Tapstate fits
Tapstate is an Operational Data Platform built around one continuous operational data path.
Teams can begin with Capture for supported source reads and change capture, add ordered transformation as the data needs to be reshaped, and use Serve to materialize and deliver consumer-ready current state through supported targets. The same path retains the progress and recovery context required to operate it over time.
The goal is not to turn CDC into something it was never intended to be.
The goal is to connect CDC to the responsibilities that operational applications eventually need anyway:
Capture the change. Transform the data. Maintain the state. Serve the answer.
FAQ
Is CDC enough for real-time applications?
Sometimes. If the application consumes change events directly and owns the required processing itself, CDC may be enough. If the application needs a current, queryable entity or cross-system operational view, additional transformation, materialization, and serving responsibilities are typically required.
Does CDC create a current-state table?
Not automatically. CDC produces information about changes. A downstream system must apply those changes according to keys, update/delete semantics, ordering, and other rules to maintain a current representation. Systems such as streaming databases, lakehouse pipelines, or an Operational Data Platform can perform that materialization.
What is the difference between CDC and Operational State?
CDC describes changes occurring in source systems. Operational State is the maintained representation of what is currently true and useful to an operational consumer. CDC can be one of the mechanisms used to keep that state current.
Do I need Kafka after CDC?
It depends on the workload. Kafka is useful when events need durable distribution, fan-out, replay, or independent subscribers. It is not automatically required simply because CDC exists. The important question is whether the downstream workload is primarily consuming events or consuming maintained current state.
Can Tapstate be adopted only for CDC first?
Yes. Tapstate's public product model explicitly supports progressive adoption: teams can start with Capture and delivery, then add ordered transformation and current-state materialization as requirements grow.
How do initial load and continuous CDC fit together?
A production data path generally needs both a trustworthy baseline and a known position from which continuing changes can be processed. The exact behavior depends on the source connector. Tapstate preserves connector-specific source positions and checkpoints so the path can continue or recover according to the capabilities of the source and target.
