About a year after SAP presented Business Data Cloud (BDC) to the world, the announcements of partnerships with other vendors in the context of Delta Share have been popping up nearly every quarter. From Snowflake to Google to Microsoft; SAP is extending the reach of its Business Data Cloud Connect-functionality. This blogpost will present a short recap on what Delta Share is and how it actually functions underneath the (figurative) hood.
What is Delta Share again?
Let’s first get some clarity on the concept of Delta Share (also sometimes simply referred to as ‘zero-copy’ in SAP communication). As indicated in our previous blogposts and White Paper, Delta Sharing is an open-source protocol for file transference developed by Databricks. It was first used in their proprietary Data Lakehouse as part of the Delta Lake technology and functions in conjunction with their Unity Catalog.
How Delta Sharing works is that it copies data in the format of Apache Parquet files from one system to another via the network. This means that, despite the fact that you may have semantically-rich data structures in your BDC system, if you choose to share this data via Delta Share, the data will be ‘flattened’ to Parquet format during this process (see the below graph for a schematic overview).
This method of data sharing should not be confused with data federation (sometimes also coined as virtualization). Data sharing via Delta Share does not support advanced data functionalities such as joins, aggregations or nested queries. Additionally, Parquet files also have no key indexes, which further shows that the technology was not designed for direct querying. For example, if you query a Delta Shared-object from an SAP Databricks system, the relevant Parquet files for that respective query are pulled for presentation from the source system (e.g. SAP Datasphere). This will result in network traffic, but not ETL-processes that result in physical data movement/replication.
What this means for you is that if you intend to share SAP data via Delta Share, you will have to anticipate the fact that you will receive flat, non-indexed data files that will have to be remodeled in the target system if you want to use it for data market purposes (e.g. querying or reporting) effectively. Note that SAP is increasing broader support for Parquet files in BDC, with support for using them in replication flows if they are shared from Amazon SSS, Microsoft Azure Data Lake (G2) or Google Cloud Storage as of this month (February 2026).
What is possible (and permitted)?
Let’s continue with the example that we sketched in the previous paragraph, where we shared data (e.g. a Standard Data Product) from Datasphere to SAP Databricks for enrichment. This can be done via, for example, Mosaic AI or a Databricks Notebook. If you want to Delta Share data from Business Data Cloud to external systems, for example an external Databricks Enterprise instance, you cannot do so directly from the SAP Databricks workspace. First, you will have to physically move your (curated) data (or custom Data Product) to a Space with the type ‘SAP HANA Data Lake Files’ in the Datasphere component of BDC. Technically, this data can subsequently be shared to (external) targets via Delta Share, where you can then layer something like Lakeflow Change Data Capture (CDC) on top in your Databricks Enterprise system.
I say ‘technically,’ because there is another important factor to take into account. As of today still, SAP’s documentation states that moving SAP data towards an external (non-SAP) data warehouse is not permitted. Whether it is via Delta Sharing or ODBC/JDBC, which are both technically feasible, third-party protocols are prohibited and violating these terms could result in contract termination or potential financial penalties. The default option to realize scenarios like these from an SAP point-of-view is still via outbound premium replication flows.
However: there are versions of SAP’s Business Data Cloud supplement visible online (more specifically, the ‘Usage Guidelines’) that state that ‘Third Party Integrations’ are only permitted to temporarily store Data Products for performance optimization purposes, so not for distributing Data Products to subsequent systems (e.g. MS Power BI, Tableau or an external Data Lake). However, once data is enriched (e.g. through joins, unions or AI processing) this data is no longer considered an SAP BDC Data Product and thus is no longer subject to the rules laid out in the BDC Supplement. This ‘resultset’ may then be stored within a target partner system and used as a native data object. For more information, always ensure that you consult the required papers (contracts, supplements) yourself before undertaking scenarios with your SAP data that are not clearly described in the standard BDC documentation.
If you want tailored advice and quality in-depth support to continue your organization’s data and analytics journey, do not hesitate to contact Expertum. Alternatively, feel free to read our other blogposts on SAP Business Data Cloud or download our SAP Datasphere White Paper here.