CDC streams vs. materialized views: When to use event streams, queryable state, or both

TL;DR

CDC streams and maintained queryable state solve different problems. Use CDC streams when systems need to react to individual database changes, like inserts, updates, and deletes. Use materialized views, dynamic tables, streaming tables, or maintained tables when applications, dashboards, or APIs need fast access to current, historical, or aggregated state.

• Use CDC streams for event-driven workflows, microservice fanout, replay within retention limits, and reacting to changes.
• Use maintained queryable state for SQL queries, API lookups, dashboards, joins, aggregates, and current-state views.
• Use both when teams need independent event consumers plus query-optimized serving tables.
• CDC streams preserve change events only when capture and retention policies keep them. Maintained state preserves business history when the model stores versions or snapshots; some systems separately retain bounded table versions for time-travel or recovery.

What is the difference between CDC streams and materialized views?

A CDC stream is a continuous flow of database change events you use for processing and reaction.

A materialized view or maintained table is a queryable state layer that stores materialized representations: current, historical, or derived tables. Use streams to react, state to query, or both when consumers need each.

What are CDC streams, change feeds, and maintained queryable state?

Teams often conflate source database logs, external event streams, platform-scoped change feeds, and materialized representations.

Maintained queryable state is the umbrella term for persisted, queryable representations derived from changing data. Materialized representations refers broadly to materialized views, materialized tables, dynamic tables, streaming tables, and aggregate tables.

Different systems use different product names, but the core architectural question stays the same: are consumers reading an event history or querying a maintained state?

What are source logs such as WAL and binlog?

Source logs are internal database transaction records used for recovery and replication. Think PostgreSQL write-ahead log (WAL) or the MySQL binlog.

Change data capture (CDC) tools read these logs. But source logs don't serve as a general-purpose downstream fanout layer.

Production CDC commonly starts with an initial consistent snapshot, records the source log position, and then continues by tailing the WAL or binlog from that position. For MySQL sources, Debezium also documents the role of an initial consistent snapshot before streaming from the binlog.

Snapshot mode, source-log retention, and persistent connector offsets are part of the CDC recovery contract. Connectors that reconstruct historical table schemas, such as Debezium's MySQL connector, also require durable internal schema-history storage. If the WAL or binlog position needed for recovery has been purged, the connector may require a new snapshot or another rehydration path.

What are external CDC streams?

CDC streams are extracted database changes (inserts, updates, and deletes) published to an external event stream or broker.

Debezium change records use a Kafka message key plus a value envelope. The envelope includes an operation type, timestamps, and source metadata; before and after contents vary by operation and source configuration, and transaction metadata is optional. In Kafka, ordering is guaranteed within a topic partition. Ordering by key follows when records with that key are routed to the same partition; there is no global order across partitions or table topics.

Replay depends on topic retention and cleanup policy, any supported remote storage, external archives, and operational policy. Standard implementations include Debezium CDC events in Kafka topics, managed CDC connectors, and Kafka-compatible event streams.

What are platform-scoped change feeds?

Platform-scoped change feeds are change-tracking mechanisms within a specific warehouse or lakehouse. Examples include Snowflake Streams and Databricks Change Data Feed. Lakeflow Spark Declarative Pipelines is instead a managed batch and streaming pipeline framework that can maintain streaming tables and materialized views; it is not itself a change feed.

These feeds support incremental processing inside their respective platforms. Their retention, replay capabilities, and fanout semantics differ significantly from those of external, durable event streams.

What are streaming database changelogs?

Streaming database changelogs are update streams used by systems like Materialize or RisingWave to maintain query results or expose downstream changes.

The exact semantics depend on the engine and whether the changelog is purely internal state maintenance or externalized for downstream consumption.

What is maintained queryable state?

Maintained queryable state refers to persisted query results derived from applying changes over time. These representations can take several forms:

• Current state / SCD type 1: One row per business key with the latest known value.
• Historical state / SCD type 2 / snapshots: Explicitly modeled history using versions, validity windows, or periodic snapshots.
• Derived state / aggregates: Maintained metrics like counts, totals, rollups, and denormalized tables.
• Streaming database materialized views: Continuously maintained SQL views over changing inputs.

Maintained queryable state can preserve history when modeled to do so. But it doesn't automatically preserve every event transition the way a retained CDC stream or changelog can.

Example: Processing a database update as an event vs. querying state

Consider an e-commerce order changing its status from Processing to Shipped.

How does a CDC stream process an update?

A downstream consumer receives an explicit change event containing the transition data. For example:

• op: update
• order_id: 123
• before.status: Processing
• after.status: Shipped
• ts: 10:01

Because the consumer sees the transition itself, a downstream service can react as soon as the event reaches it, with latency determined by capture, transport, processing, and sink behavior. For example, the service can send a shipping confirmation email, update a fulfillment workflow, or trigger a mobile push notification.

For external side effects like emails, payments, notifications, or HTTP calls, design for retries and duplicate delivery. Use an idempotent destination operation, deduplicate on a stable event or command ID, or atomically coordinate the consumed offset with the external write when the destination supports it. Do not assume that a bare WAL or binlog position uniquely identifies every CDC record.

Replay and backfill paths need careful design. You don't want to re-send customer-facing side effects during a recovery operation.

How does maintained queryable state represent an update?

In this model, a consumer application executes a query against the serving layer:

SELECT status FROM orders WHERE id = 123

The returned result is Shipped. The consumer sees the latest modeled state. They don't necessarily see the fact that the order changed from Processing to Shipped exactly at 10:01.

To query the transition or its exact timing in a state-based architecture, the design must explicitly include historical state, SCD Type 2 records, periodic snapshots, audit tables, or retained CDC events.

The stream is useful for reacting to the change, while the maintained table, view, or dynamic table is useful for lookup and analysis.

![][image1]

CDC streams vs. maintained queryable state: Five production comparison points

CDC streams and maintained queryable state aren't interchangeable.

How do CDC streams and maintained state compare for ordering, retention, and replay?

CDC streams

• Usually preserve ordering within a topic partition or a specific key, not across all events globally.
• Per-key or per-partition ordering doesn't imply global, cross-table, or transaction-atomic ordering.
• Transaction-boundary metadata is connector-specific and often optional. Consumers that need atomic multi-row or multi-table behavior must verify connector metadata and design downstream buffering, reconciliation, or coordination.
• Kafka replay depends on the required records remaining in the topic or an archive; compaction can remove older per-key revisions.
• Kafka retention is configurable per topic; do not assume either finite or indefinite history. Design around the effective cleanup policy, retention limits, consumer recovery, audit requirements, and backfill needs.

Maintained queryable state

• Exposes a table or view result rather than a raw event sequence.
• May overwrite prior values in current-state models unless you explicitly capture history in the schema.
• Replay in this context usually means rebuilding the state from an upstream stream, a source database snapshot, warehouse/lakehouse history, or archived raw data.

How do CDC streams and maintained state compare for latency, freshness, and transformations?

CDC streams

• Latency depends on source logs, connector behavior, broker throughput, network conditions, processing engines, and sink performance.
• Work well for low-latency routing, filtering, enrichment, and event-driven workflows.
• Stream processors like Apache Flink or Kafka Streams can transform changes in flight before they reach downstream systems.

Maintained queryable state

• Freshness depends entirely on the system's refresh model: continuous maintenance, incremental refresh, scheduled jobs, target lag, query-time compute, or warehouse capacity.
• Works well when consumers want SQL-accessible state rather than individual event handling.
• Dynamic tables, materialized views, and streaming tables can reduce query complexity by precomputing joins, aggregations, and denormalized shapes.

How do CDC streams and maintained state handle joins, deletes, upserts, and latest state?

CDC streams

• Complex joins require stateful processing, especially when joining multiple changing tables or streams. Regular streaming joins can retain both inputs in Flink state indefinitely, while event-time temporal joins require correctly configured watermarks to account for late data.
• Delete events are explicit. Consumers must handle them correctly.
• Kafka compacted topics can retain the latest record per key, while tombstones are commonly used to delete keys from compacted state entirely.
• A compacted topic may look like a latest-state table, but it still fundamentally serves an event-streaming role with offsets, partitions, consumers, and broker retention policies. It doesn't provide immutable history.

Maintained queryable state

• Joins, aggregations, and denormalized results are maintained in the serving system.
• Source deletes propagate according to the maintainer's refresh or incremental-maintenance semantics. Mutable serving tables may instead apply them through DELETE, MERGE, or keyed upserts; many materialized or dynamic views are read-only.
• Current-state tables collapse event history unless you model delete history or versioned history separately.
• Table upserts optimize for query serving. Compacted topics optimize for event distribution and stream processing.

How do CDC streams and maintained state handle schema evolution, contracts, and governance?

CDC streams

• Consumers can break when source schemas change unexpectedly. Watch out for column additions, removals, renames, type changes, nullable-to-required changes, and primary key or business key changes.
• Schema Registry compatibility rules can protect consumers from incompatible Avro, Protobuf, and JSON Schema evolution. Configured data contracts can also enforce defined data-quality rules, but neither validates all downstream business logic.
• Common breakage modes include deserialization failures, incompatible sink schemas, failed consumers, invalid transformations, and broken upsert logic.
• Governance needs include topic ownership, schema compatibility, ACLs, PII handling, lineage, retention, and contract enforcement.

Maintained queryable state

• Materialized views, dynamic tables, and serving tables can fail, lag, or require complete rebuilds when upstream schemas drift.
• Downstream breakage can include failed refreshes, incompatible MERGE statements, broken dashboards, invalid BI models, and permission issues.
• Governance needs include table ownership, permissions, data masking, lineage, refresh ownership, and dependency management.

How do CDC streams and maintained state compare for operations, recovery, and backfills?

CDC streams

• Monitor connector lag, broker health, consumer lag, dead-letter queues, schema compatibility failures, sink errors, and replay behavior.
• Recovery depends on retained source-log positions and persistent connector offsets.
• Recover through offset resets, consumer restarts, dead-letter reprocessing, topic backfills, or rehydration from archived events.
• For stateful stream processing jobs, Flink checkpointing helps coordinate recovery of operator state.
• Backfill feasibility depends on whether the required history still exists in the stream, source log, object storage archive, or another retained system. Exactly-once state inside a stream processor does not by itself cover external effects; end-to-end exactly-once requires replayable sources plus transactional or idempotent sinks. Backfill runbooks must explicitly suppress, route, or deduplicate customer-facing side effects.

Maintained queryable state

• Monitor refresh lag, target lag, failed refreshes, warehouse/job failures, stale reads, query performance, and storage growth.
• Recover through incremental rebuilds, full recalculations, snapshot comparisons, or reprocessing from upstream streams or change feeds.
• Backfills often require a known source of truth: retained CDC events, source snapshots, lakehouse table history, warehouse snapshots, or archived raw data.

Many production systems combine these patterns. CDC streams distribute changes to independent consumers, processors clean or enrich those changes, and maintained queryable state serves dashboards, APIs, analytics, or operational lookups.

Not every workload needs every layer. Choose layers based on consumer requirements.

CDC stream and maintained state tools: Kafka, Flink, streaming databases, warehouses, and lakehouses

CDC and event backbone tools

Best for durable change-event distribution, fanout, retention windows, compaction, and replay. Kafka producers and consumers are decoupled, and topics support multiple subscribers.

• Examples: Apache Kafka, Debezium, managed CDC connectors, Confluent Cloud.

Continuous stream processing tools

Best for transforming, filtering, joining, enriching, and routing CDC events in motion. Outputs can include clean event streams, enriched topics, sink updates, or maintained state elsewhere.

Apache Flink can treat table changes as changelog streams and continuous queries as dynamic tables.

• Examples: Confluent Cloud for Apache Flink, Apache Flink, Kafka Streams.

Streaming databases for maintained queryable state

Best for continuously maintaining SQL views over changing inputs for low-latency queries. These systems provide fresh queryable state to applications and dashboards without requiring teams to build all the stateful processing logic manually.

• Examples: Materialize, RisingWave.

Warehouse and lakehouse tools for maintained state

Best for warehouse and lakehouse-internal transformations, BI, reporting, and analytics where managed refresh semantics are acceptable.

Modern systems offer incremental modes rather than strictly full-batch recalculations, including warehouse-specific refresh modes for dynamic tables.

• Examples: Snowflake Dynamic Tables, Snowflake Streams with Tasks that maintain standard tables, Databricks Lakeflow materialized views or streaming tables, and standard RDBMS materialized views. Delta Change Data Feed is an input to incremental processing, not a maintained-state serving object.

How CDC streams, stream processors, and maintained state fit together

A CDC stream can feed stream processors, streaming databases, warehouses, lakehouses, feature stores, and operational databases simultaneously.

A platform-scoped change feed may be enough when all consumers and transformations live inside one warehouse or lakehouse. A durable external stream is more useful when multiple independent systems need access to the same change events without querying the OLTP database.

![][image2]

CDC streams vs. materialized views: Quick comparison

When should you use CDC streams, maintained queryable state, or both?

How Confluent supports managed CDC streams, event processing, and Flink

As a complete Data Streaming Platform, Confluent provides the streaming, connecting, processing, and governing capabilities for architectures that need durable CDC event distribution, independent consumers, and stream processing.

• Connectors are pre-built integrations that move data between Kafka and other external systems without custom code. Fully managed Confluent Cloud connectors (from an ecosystem of 120+ integrations), including Debezium-based CDC source connectors for PostgreSQL, MySQL, and Microsoft SQL Server, stream database changes into Kafka topics without teams operating Kafka Connect infrastructure.
• Fully managed, serverless Apache Flink on Confluent Cloud can clean, join, transform, and route change events before they land in downstream serving layers. The Real-Time Context Engine maintains materialized views from these streams for low-latency AI queries.
• Stream Governance, Schema Registry, and configured data contracts enforce schema compatibility and defined data-quality rules before records reach consumers. These controls reduce schema-related failures, but they do not validate materialized-view SQL, refresh behavior, or downstream consumer business logic.
• Kafka-backed CDC topics support configurable time- or size-based retention and log-compaction policies, while separate consumer groups provide independent fanout. Consumers can replay only records that still exist under those policies, so compaction preserves the latest value per key rather than a complete event history.

Conclusion: Choosing between CDC streams, maintained queryable state, and both

CDC streams and maintained queryable state solve fundamentally different production problems.

Streams preserve and distribute change events for immediate reaction, independent fanout, and replay within configured retention limits. Materialized views, dynamic tables, streaming tables, and other maintained representations serve queryable state for applications, dashboards, and analytics.

Start with your consumer requirements: reaction versus lookup, latency, replay, history, governance, and ownership. Then choose streams, maintained state, or both.

Build your stream layer with Confluent's CDC connectors and fully managed Apache Flink.

FAQ

What is the difference between a CDC stream and a materialized view?

A CDC stream contains individual database change events: inserts, updates, and deletes. A materialized view or maintained table stores queryable state derived from those changes, like the latest row, an aggregate, or a denormalized result.

When should I use a CDC stream instead of a materialized view?

Use a CDC stream when downstream systems need to react to each change event, trigger workflows, support microservice fanout, or replay events within a retention window. Streams are best when the event itself matters.

When should I use maintained queryable state instead of CDC events?

Use maintained queryable state when consumers need fast SQL or API access to current, historical, joined, or aggregated data. It's the better fit for dashboards, lookups, analytics, and serving layers.

Can a materialized view replace a CDC stream?

Not always. A materialized view usually exposes the current or derived state, but it may not preserve every individual change event unless history is explicitly modeled. If consumers need event-by-event processing, a CDC stream is usually required.

When should I use both CDC streams and materialized views or tables?

Use both when multiple systems need independent access to change events and other consumers need fast queryable state. A common pattern is using CDC streams for fanout and processing, then maintaining query-optimized tables for applications, dashboards, or analytics.

Do CDC streams provide a complete audit history?

Only if the capture configuration emits every required change and metadata, and a non-compacting retained or archived copy preserves those records. A compacted topic alone is not a complete audit history because older revisions can be removed. CDC streams can support row-change history and replay, but they do not automatically provide complete or indefinite audit history.

Does maintained queryable state preserve historical changes?

Business history must be modeled with versions, snapshots, audit tables, or retained change events. Some platforms separately retain bounded system versions for time-travel or recovery, but that is not the same as preserving every change event in an audit log.

Are Kafka compacted topics the same as materialized tables?

No. A compacted Kafka topic can retain the latest record per key, but it's still an event-streaming construct with offsets, partitions, consumers, and broker retention behavior. A materialized table is optimized for query serving.

Which layer should serve dashboards that need fresh data: CDC streams or maintained queryable state?

Maintained queryable state is the serving layer for dashboards that query current, joined, or aggregated data; its freshness is bounded by the chosen system's measured end-to-end maintenance lag. CDC streams may feed that layer when changes need to propagate continuously.

How do CDC streams and materialized views handle deletes?

CDC streams usually emit explicit delete events that consumers must process correctly. Materialized or dynamic views incorporate source deletes through refresh or incremental-maintenance semantics; mutable maintained tables may use DELETE, MERGE, keyed upserts, or tombstones according to the target system.