Databricks Zerobus CDC Removes Kafka From the Path, Keeps Capture With Database Teams

Databricks outlined a database replication path that bypasses Kafka while keeping capture under the database team’s control. Databricks Zerobus CDC combines Zerobus Ingest, its managed ingestion service, with Debezium, an open-source change data capture platform. Change data capture, or CDC, records database changes for processing elsewhere. The attraction is a shorter route into analytics, with reliability responsibilities that still require deliberate engineering.

The architecture addresses a specific organizational problem: a database team can permit outbound traffic while refusing incoming connections from an external analytics service. Apache Kafka, an event streaming platform, already supports architectures with source-controlled capture. The change here is removing that intermediate platform when Databricks is the intended destination.

That distinction matters for database administrators, platform engineers, and analytics buyers evaluating another ingestion option. A shorter transport path can reduce infrastructure ownership. It does not automatically produce a correct replica, establish a recovery policy, or settle which team handles a failed update. Those decisions determine whether simplification survives production.

Databricks Zerobus CDC Gives Source Teams a Direct Destination

Databricks described the architecture in a November 5, 2026, engineering post. Its push-based CDC architecture connects Debezium Server directly to Unity Catalog, Databricks’ governance layer, through Zerobus Ingest. The destination stores events in Delta tables, tables using the open Delta Lake storage format.

According to Databricks, its engineers built the typed sink, the component that delivers captured records to the destination. NVIDIA contributed envelope mode, which retains the change event and associated delivery metadata. Databricks says the sink ships with Debezium Server 3.7.

The concrete change is a supported direct delivery path, with capture remaining inside the source team’s environment.

That division gives organizations a different way to assign responsibility. The database team operates capture near its database. The analytics platform receives changes without requiring that team to adopt an intermediate event platform solely for transportation.

Consider an illustrative enterprise deployment with a privately hosted order database. Security reviewers allow a local process to send approved data outward. They do not allow an outside service to initiate database connections. A source-operated process fits that direction of access, provided reviewers approve the destination, identity, and permitted data.

This example explains architectural fit rather than documented customer adoption. The announcement establishes the integration and its intended use. It does not establish that every restricted enterprise network can approve the connection, or that every database workload needs this design.

For buyers, the important distinction is between an integration becoming available and a migration becoming justified. A team with working infrastructure needs evidence that changing the path improves its own operating model. An announcement alone cannot answer that question.

For teams designing a new pipeline, however, the starting decision changes. They can evaluate whether the destination needs an intermediate transport service at all. That question belongs early in architecture review, before deployment standards make a particular component feel mandatory.

The immediate consequence is narrower than replacing an enterprise streaming platform. Databricks has described a route for a particular job: moving database changes into its governed analytical environment. Its usefulness depends on how closely the actual requirement matches that job.

A sensible evaluation therefore starts with ownership and destination requirements. Which team controls database access? Where must the changes go? Who needs independent access before analytics processing? Those answers determine whether a direct sink removes unnecessary work or removes a capability someone still needs.

The Pressure Falls on Pipelines Built for a Single Destination

The strongest challenge targets intermediate infrastructure whose only purpose is delivering changes to Databricks.

That framing keeps the comparison honest. Kafka offers capabilities beyond forwarding records into an analytical table. Its event streaming model includes durable event storage, subscriptions, and processing. Those capabilities matter when multiple applications consume the same stream or need independent processing schedules.

A direct destination changes that relationship. It makes the analytics platform the immediate receiving system. That can fit a pipeline whose requirements end there. It deserves closer scrutiny when other teams expect the ingestion layer to serve their applications too.

Imagine a database feed used for reporting, search indexing, and application notifications. The architectural decision must account for every consumer. Counting only the reporting path would understate the system’s responsibilities and make the direct route appear more comprehensive than it is.

Now consider a different organization. Its database changes feed only an analytical replica, and nobody needs a shared event distribution layer. In that setting, maintaining an intermediate platform demands a separate justification. Existing familiarity can support that justification, but familiarity alone does not establish necessity.

This creates pressure on platform teams to explain the purpose of each component. The useful question becomes what operational capability disappears when a component disappears. A clear answer supports retaining it. An unclear answer identifies a candidate for simplification.

The announcement also puts pressure on procurement conversations built around component lists. A managed ingestion service and an event platform do not perform identical jobs. Comparing them requires a common workload, a common recovery objective, and an explicit account of who operates the remaining software.

There is no verified workload comparison here that establishes universal savings or superior end-to-end performance. Buyers should resist converting a shorter diagram into a financial conclusion. Staffing, existing services, incident handling, and downstream processing all affect the outcome.

The same restraint applies to migration urgency. A stable Kafka deployment serving several consumers presents a different decision from a proposed cluster serving one destination. The direct route has its clearest argument where intermediate transport would otherwise become a new operational obligation.

For engineering leaders, this is an opportunity to revisit responsibility boundaries. Database administrators should define acceptable capture behavior. Platform teams should define destination operations. Analytics teams should define acceptable freshness and correctness. A smaller transport layer becomes useful when these responsibilities remain explicit.

The resulting competitive question is practical: how much infrastructure must an organization operate to deliver the data product it actually needs? Databricks has strengthened its answer for a destination-focused workload. Broader streaming requirements still demand a broader comparison.

Durable Delivery and Correct Replication Remain Separate Jobs

The most consequential detail in Databricks Zerobus CDC is the acknowledgment boundary. An acknowledgment tells the producer that the destination has accepted responsibility for data. A source offset records capture progress, allowing the producer to resume from a known position.

The Debezium Server sink documents at-least-once delivery, meaning retries can deliver an event more than once. It validates records within a target-table group and waits for acknowledgment before completing source progress. A later failure can cause an earlier acknowledged group to be replayed.

Envelope mode supplies an idempotency_key, an event identifier used to recognize repeated delivery. Downstream processing must use that identity to remove duplicates. Identifying a repeated event does not establish which distinct event should take precedence.

Durable delivery protects the handoff; downstream logic must still establish the correct business state.

An illustrative order update shows why this matters. Suppose a customer changes an order’s delivery address. The destination accepts the update, but capture restarts before its progress is fully committed. Replaying that update should leave the analytical representation unchanged after duplicate handling.

An append of every received record would preserve the repeated delivery. That can be useful evidence in a raw event collection. It becomes a problem if reporting treats every arrival as a separate business action. Transport success and analytical interpretation answer different questions.

Ordering introduces another distinction. Suppose an order changes from pending to approved, then from approved to canceled. Repeating the approval event must not restore the earlier status. The pipeline needs a rule that distinguishes source sequence from arrival time.

This is why delivery metadata deserves attention during procurement and architecture review. A team needs to know what information survives transport and what its downstream engine requires. An integration that preserves useful evidence still needs a processing contract that consumes it correctly.

The failure boundary also shapes incident investigation. Operators should be able to distinguish an event awaiting delivery from an event awaiting processing. They should identify repeated delivery without confusing it with repeated business activity. Otherwise, recovery creates uncertainty precisely when people need clear evidence.

These are practical acceptance criteria rather than reasons to reject the design. A direct route can be dependable when its responsibilities are understood. Problems arise when teams interpret an ingestion guarantee as a guarantee about the final analytical table.

The appropriate test is therefore more demanding than seeing records arrive. Interrupt capture after successful delivery, restart it, and inspect the resulting business state. Exercise updates and deletions as well as inserts. A pipeline earns confidence when recovery preserves meaning, not merely connectivity.

That evaluation should involve the people responsible for reports. Engineers can verify event handling while analysts verify the resulting interpretation. Agreement between those perspectives establishes a stronger acceptance boundary than either team can provide alone.

A Landed Change Stream Still Needs an Analytical Contract

A separate boundary exists between durable storage and query availability. Databricks’ durability acknowledgment documentation explicitly distinguishes them: acknowledgment confirms durability before the record becomes queryable in the Delta table.

That distinction prevents a common measurement error. Successful ingestion does not necessarily mean an analyst can already see the corresponding business change. A freshness commitment must cover the path from the source transaction to the table or report people actually use.

The useful service objective measures when correct information becomes available to its intended consumer.

For an operations dashboard, that endpoint might be the current order status. For an audit workflow, it might be a preserved history of changes. These products can share captured events while requiring different downstream behavior and different acceptance checks.

Databricks documents AUTO CDC processing for building those representations. AUTO CDC is a pipeline interface that applies change records using defined keys and sequencing. Its Type 1 processing retains current state; Type 2 processing retains historical versions.

The business distinction deserves attention before implementation. A current-state table answers what a record looks like now. A history table supports questions about earlier states. Choosing between them affects what users can investigate after an incident or disputed report.

Consider an illustrative support workflow involving a canceled order. An agent looking up current status needs the cancellation reflected correctly. An investigator reviewing the case might also need to understand the preceding approval. The data product should identify which question it promises to answer.

A raw event collection alone leaves that promise unclear. Users might interpret repeated arrivals as repeated actions or assume that every stored version represents a distinct business transition. A documented analytical contract should explain the relationship between captured events and published records.

This contract also gives teams a useful reconciliation target. They can compare source state with the published current-state representation. They can separately inspect whether retained history matches the intended business interpretation. Each comparison tests a different responsibility.

The Databricks community’s PostgreSQL CDC walkthrough provides a concrete technical example. It follows PostgreSQL changes through ingestion and into a current-state table. The walkthrough checks inserts, updates, and deletes, making those operations visible acceptance cases.

That example is useful for understanding the integration. It does not establish performance across every production dataset, network policy, or recovery scenario. Teams should treat a walkthrough as a reproducible starting point and extend its checks around their own failure conditions.

The organizational implication is straightforward. Removing intermediate transport does not remove the need for a data product owner. Someone still defines correctness, approves freshness expectations, and decides whether historical interpretation meets business needs.