Who pays cross-cloud egress for Delta Sharing from GCP to Azure?

[mariajsm]

Hi DBX community!! Are cross-cloud egress charges for a Databricks-to-Databricks #DeltaShare billed to the provider account, and do they apply when the shared objects are views backed by Cloudflare?

I'm setting up a Delta Share using Databricks on GCP (us-central1) as the provider. The shared objects are views in Unity Catalog, and the underlying data is stored in Cloudflare R2.

The recipient is a customer using Databricks on Azure (West region). I'd like to understand how the costs are handled in this scenario:

1. Is there a cross-cloud egress/network charge when the Azure recipient queries the shared views?

2. If so, is that egress charge billed to the provider (GCP) or the recipient (Azure)?

3. Since the underlying data is stored in Cloudflare R2, does R2's lack of egress fees change or eliminate any of the Databricks cross-cloud egress charges?

4. Are there additional Databricks compute charges on the provider side when the recipient queries views through Delta Sharing?

5. Is there a recommended architecture to minimize costs if the recipient will query the shared data frequently?

Any clarification or real-world examples of how these charges appear in billing would be greatly appreciated.

[emma_s]

Hi,

Interesting topic, I've pulled together some relevant info for you:

TLDR

If your underlying data is in Cloudflare R2, the cloud-provider egress charge for cross-cloud Delta Sharing is effectively zero because R2 does not charge for egress. However, because you are sharing views (not physical tables), there may be provider-side compute costs for materialisation depending on the recipient's compute type. The recommended approach is to share physical Delta tables from R2 where possible, and ensure the recipient uses serverless compute.

---

How Delta Sharing moves data

Delta Sharing does not stream data through Databricks. It generates short-lived pre-signed URLs pointing to files in your cloud storage, and the recipient's compute fetches data directly from those URLs over HTTPS. This means the egress charge comes from your storage provider, not from Databricks itself.

Since your data is in Cloudflare R2, and R2 has zero egress fees regardless of destination, the cross-cloud data transfer from GCP to Azure does not incur a cloud-provider egress charge. Databricks explicitly documents R2 as an egress-avoidance strategy for OpenSharing. See Monitor and manage OpenSharing egress costs. For R2 pricing details, see Cloudflare R2 Pricing.

When using views

Worth bearing in mind sharing views behaves differently from sharing physical Delta tables.

When a recipient on a different Databricks account queries a shared view, what happens depends on their compute type:

• Recipient on serverless compute (different account): the recipient gets direct access to the underlying data. No materialisation on the provider side. No incremental charge to the provider.
• Recipient on classic compute (different account): the view is materialised and filtered on the provider side, using the provider's interactive serverless compute. The provider pays for that compute.
• Recipient using open sharing connectors: same as classic, materialised on the provider side at the provider's cost.

This is documented at What is OpenSharing? under "How do I incur and check OpenSharing costs?" Also see Create shares for OpenSharing for the view-specific materialisation details.

So to answer your specific questions:

1. Is there a cross-cloud egress/network charge?

For the data transfer itself, no, because R2 does not charge egress. You will still pay R2 storage costs and R2 API operation costs (Class B read requests), but the bytes-out-the-door charge is zero. See Cloudflare R2 Pricing for current rates.

The recipient may incur their own cloud networking costs (e.g. Azure NAT gateway charges for their serverless compute reaching out to R2), but that is on their side.

2. Is egress billed to the provider or the recipient?

For standard OpenSharing (without SecureConnect), egress is a cloud-provider charge billed to whoever owns the storage. Since R2 does not charge egress, the point is moot in your case. See Understand Databricks networking costs for how Databricks networking billing works more broadly.

If you were to enable SecureConnect (the Delta Sharing Network Gateway), Databricks would proxy the data and bill the provider for the transfer. However, R2-backed assets are not currently supported with SecureConnect, so this path does not apply to your setup.

3. Does R2's zero egress eliminate Databricks cross-cloud charges?

It eliminates the cloud-provider data transfer charge, yes. It does not eliminate:

• R2 storage and API operation costs (billed by Cloudflare)
• Databricks compute costs for view materialisation (if the recipient triggers provider-side materialisation as described above)
• The recipient's own compute costs

One limitation to be aware of: providers cannot share R2 tables that use liquid clustering with V2 checkpoint. See Limitations for Cloudflare R2.

4. Are there provider-side compute charges?

Yes, potentially. If the recipient uses classic compute or open sharing connectors, the view is materialised on your side using your interactive serverless compute. If the recipient uses serverless compute, there is no incremental materialisation charge to you.

You can track this in system.billing.usage and the OpenSharing materialisation history system table.

5. Recommended architecture for frequent querying

A few things you can do to keep costs down:

1. Share physical Delta tables from R2 rather than views wherever possible. Tables skip the materialisation step entirely, and the recipient reads directly from R2 with zero egress. See Connect to a Cloudflare R2 external location for setup.
2. Only use views where you genuinely need row/column filtering or masking via current_recipient().
3. Confirm the recipient is using serverless compute. This is the path where they get direct access with no provider-side materialisation cost.
4. For very frequent querying, consider a replication pattern. Share the table with Change Data Feed enabled (WITH HISTORY), and have the recipient clone or sync the data to local Azure storage. This limits cross-cloud reads to incremental refreshes rather than full scans on every query.
5. Do not enable SecureConnect for R2-backed assets. It is not supported and would introduce Databricks-billed data transfer charges if it were.

Where the charges show up in billing

• R2 storage and operations: billed by Cloudflare directly, not visible in Databricks billing
• Provider-side materialisation compute (when applicable): appears in system.billing.usage as interactive serverless compute, attributable by recipient_id
• Recipient compute: appears in the recipient's own Databricks billing
• Network/egress: for standard OpenSharing with R2, there should be no egress line item in either Databricks or GCP billing

Hope that helps! The key takeaway is that R2 solves the egress problem, but sharing views rather than tables introduces a separate compute cost dimension that is worth planning for.