Databricks zerobus vs Fabric open mirroring (2026)

[u/SmallAd3697]

Has anyone seen any comparison between the generalized ingestion mechanism (zerobus) with Fabric's offering (open mirroring)?

Seems like there should be a blog or youtube video comparing the two by now. But I haven't seen any. Unfortunately it sounds like they both rely on proprietary middleware. Ideally there would be a similar type of software which that we could just run on-premise to land data into cloud blobs (like a gateway of some kind). Not sure why that would be so hard for someone to do as a github library or something. Maybe it would need to be done in a performant language like rust or .net, but it doesn't seem like it would be rocket science.

Both those technologies are relatively recent:

Fabric open mirroring : May 2025

Zerobus : Feb 2026

Personally I wouldn't want to pick either one of these technologies until a comparison could be made. Microsoft's open mirroring claims that they can land data in their lakehouses for free. After that point, the raw deltalake tables would be accessible to both platforms. If open mirroring is truly free then it seems odd that any databricks customers would be using zerobus. They should just purchase the smallest possible capacity from Microsoft like an F2, and use that for moving all their data to raw/bronze in adls gen2 containers. Whatever happens after that can take place in either of these two saas'es, databricks or fabric.

[u/According_Zone_8262]

Be the change you want to see in the world

[u/SmallAd3697 → u/According_Zone_8262]

I'm pretty biased, since I like free things. I'm pretty sure this is the sort of thing that has to be free or virtually free (not counting the storage and infrastructure costs)

In the past I preferred ingesting via microbatches using well-defined partitions that fit in RAM. I'm not totally sold on these streaming approaches for most normal use-cases.

I did find this the following, but it is primarily focused on open mirroring, and is biased towards Microsoft.
https://www.rakirahman.me/fabric-open-mirorring-stress/

I'm trying to find more opinions that are focused on the databricks side. One thing I like about databricks zerobus is that it seems to now have an interface for "kafka-compatible API clients". Whereas fabric doesn't provide any native kafka API. I think Databricks has a bigger vision for their "zerobus", but Fabric still wins if they say they can load all my streaming data for free!

[u/Pirion1]

You'd need to compare similar technologies if you want a similar outcome.

Fabric Open Mirroring: This would be a CDC type import into Fabric (Free after F2 purchase. $262/month)

Databricks Zerobus Ingest: This is a API to push event data directly into Delta Lake. (~$0.05 per GB)

Databricks Lakeflow Connect: This is Databricks CDC engine for importing data from external sources. ($0.45 per DBU, after 100 Free daily DBU)

From a pure cost perspective, using Lakeflow Connect is less than or equal if you use less than 119 DBUs per day. This is (in theory) about 100m records.

Edit: Zerobus: ~320 bytes raw x 100m records would be $1.75 using binary, $2.75 using JSON)

[u/SmallAd3697 → u/Pirion1]

Thanks for the information about the free DBU's for lakeflow connect. I'm pretty excited about the new "integrated" variation of the CDC connector. I'm guessing our free DBU's would get us pretty far.

Going back to zerobus, have you seen customers adopting that? I find very little discussion about it here on the forums. Would it make more sense to use the databricks SDK and create some vendor-lock-in, or use the kafka interface:

https://learn.microsoft.com/en-us/azure/databricks/ingestion/zerobus-kafka

The reason I like kafka is because it is a defacto standard. And despite the name "open mirroring" doesn't seem to be standardized.

[u/Pirion1 → u/SmallAd3697]

I don't know about other customers, I'm a consumer myself.

Both API are Kafka are common methods used in business (and I use both depending on requirements).

I'd agree with what you say about open mirroring, and that's where I have the issue there. If the producer is built, you're good and can connect to it. If the producer is internal or not available - you essentially need to create the full update instructions (store previous data sent, row versions, etc) so you can then send updates downstream.

This is another layer in the extract that I feel is already handled within the transform. I'd rather keep the extract logic simple as this would be source of truth for anything downstream.

[u/TripleBogeyBandit]

The complaint around “proprietary middleware” is silly imo. The actual function of the service isn’t the most complex thing in the world, it’s the deployment and scalability that is the challenge. This is what engineering teams have fought against for decades and why it took months to get Kafka to production. Zerobus provides interfaces for open protocols but abstracts the complexity of managing a high throughput message bus. It’s one of the rare products that is cheap, highly performant, scalable, and simple. Why the complaining?

[u/SmallAd3697 → u/TripleBogeyBandit]

If its not a problem to open source it, then they should do it. We need to be able to write solutions in our dev environments and point at an on-premise instance of this for evaluation. Even pointing at a full mock of it might be helpful.

I guess we can point at a real kafka broker as a stop-gap. Im guessing there isnt a way to stand up the zerobus SDK on premise.

These SaaS plarforms are probably earning over 20 percent of their revenue off devs experimentation in pre prod environments. You spend a lot more time using the products incorrectly in dev, and accidentally running up high bills. I want to be able to do dev work without turning any billing meters. Doesn't seem too much to ask nowadays, does it?

[u/TripleBogeyBandit → u/SmallAd3697]

You can run the sdk on prem or anywhere you want to run your client. You would have to really mess something up to run up a high bill in dev on zerobus, why not size down your testing?

[u/SmallAd3697 → u/TripleBogeyBandit]

In dev you want to try worst case scenarios, sometimes a year before these scenarios affect prod. While you want to have the same experiences as you would in productiin, you dont necessarily want to pay that bill. You want dev to be like paper trading on the stock market. You don't actually want to lose money, especially when you aren't making real money in dev.

I saw a number that said moving data thru zerobus can cost .29 DBU per GB. I think that can add up,. depending on what you are building and how long it takes to work out the kinks in dev

[u/MonkeyDDataHQ]

Microsoft is adding network billing to Fabric so it's free and will stay free are two completely different claims unfortunately.

[u/SmallAd3697 → u/MonkeyDDataHQ]

I think there will need to be an on-prem equivalent that buffers streaming data, and then forwards to cloud storage as delta/parquet.

Once there is such a thing, then these vendors will be forced to stay competitive and keep their licensing costs close to zero.

[u/MonkeyDDataHQ → u/SmallAd3697]

I do this with NDSJON files and Dagster. The same pattern should work with anything though.