A Lakehouse-Native Event Bus Pattern for Data Platforms

DeltaBus

A Lakehouse-Native Event Bus Pattern for Data Platforms

Download the White Paper

Most data platforms built on the Lakehouse add a separate message queue. Kafka, SQS, Azure Event Hubs. It’s an another cluster to manage, separate billing line and another governance gap, because events flowing through an external bus exist completely outside your Unity Catalog boundary.

The infrastructure you already have in Databricks, Delta Lake's append-only storage, Change Data Feed, Unity Catalog governance, contains everything a production event bus needs. DeltaBus is the pattern that proves it.

DeltaBus is the messaging backbone powering every component of Auraa, tenant provisioning, ingestion orchestration, data quality, agent-to-agent communication, running in production on Databricks with no external dependencies.

Download the White Paper to Learn:

Download the White Paper

Frequently Asked Questions

Why are external message buses like Kafka structurally mismatched to data platform operations?

External message buses introduce a separate cluster to manage, a separate billing line, and events that flow completely outside the Unity Catalog governance boundary. For platform operations workloads (tenant provisioning, ingestion orchestration, data quality notifications, agent-to-agent communication), all of those events need to be governed, auditable, and queryable alongside the data they affect. Routing them through an external bus breaks that continuity. The Lakehouse already has append-only storage, Change Data Feed, and Unity Catalog governance: everything a production event bus needs.

How does DeltaBus turn a Delta table into a complete publish-subscribe event bus?

DeltaBus enables Change Data Feed on a Delta table and treats it as an event log. Publishers append structured event records. Subscribers poll using checkpoint-based CDF reads, tracking their last-processed Delta version. This gives at-least-once delivery, checkpoint-based deduplication to achieve effectively-once processing semantics, and a permanent queryable history of every event. All of this runs inside the existing Unity Catalog governance boundary with no external coordination service.

What is the ZeroBus SDK and how does dual-mode publishing work?

The ZeroBus SDK is the publishing interface used by Auraa's platform components. It delivers sub-10-second confirmed event delivery when the bus is available. When DeltaBus is not reachable, ZeroBus automatically falls back to in-memory buffering and replays on reconnection. This fallback is transparent to the caller: the publishing component does not need to handle connectivity failure logic.

What does DeltaBus cost compared to Kafka and managed queue services?

DeltaBus setup takes approximately 5 minutes, creating a CDF-enabled Delta table. A comparable managed Kafka cluster or Azure Event Hubs configuration takes 2-6 hours. Operating cost for DeltaBus is approximately $50/month in Delta storage. Comparable managed queue services for the same platform operations workloads cost $2,000-15,000/month. There is no idle compute cost: DeltaBus uses serverless compute that scales to zero when subscribers are not polling.

What are the deliberate trade-offs of DeltaBus compared to a dedicated message queue?

The whitepaper identifies three trade-offs, each deliberate for platform operations: 5-10 second event latency (unsuitable for real-time financial transactions, appropriate for tenant provisioning and ingestion coordination), per-topic ordering (events within a single Delta table are ordered; cross-topic ordering requires application-level sequencing), and single-workspace scope (DeltaBus operates within one Databricks workspace; cross-workspace messaging still requires an external bus). For Auraa's platform operations workloads, none of these are disqualifying.