BDC Connect: Zero-Copy Data Sharing for SAP Analytics
What you'll learn: How SAP Business Data Cloud Connect eliminates data silos by enabling zero-copy sharing across Databricks, Snowflake, BigQuery, Microsoft Fabric, and Amazon Athena—without physical replication, reducing costs, latency, and governance complexity.
Data silos fragment enterprise intelligence. Teams across your organization operate with disconnected views of customer behavior, operational performance, and market trends. SAP Business Data Cloud Connect addresses this challenge with a fundamentally different approach: zero-copy data sharing that keeps SAP data products in one governed place while giving the platforms your teams already use direct access to them.
Unlike traditional data replication—which duplicates data and multiplies infrastructure costs—or federation—which adds query overhead—BDC Connect establishes direct, governed access paths between SAP analytics solutions and major cloud platforms. It's SAP's answer to the enterprise challenge of building unified analytics architectures without the burden of physical data movement.
What is BDC Connect?
SAP Business Data Cloud Connect is the BDC service that shares data products with partner data platforms without copying them. It works in both directions: SAP-managed data products (curated from SAP applications) and custom data products (built in SAP Datasphere's object store) can be shared into Databricks, Snowflake, or Google BigQuery, and data products built on those platforms can be published back into the BDC catalog. It is available only with an SAP Business Data Cloud subscription and is set up once per partner connection.
How Zero-Copy Sharing Works
The principle is simple: the data product is stored once in BDC, and partners read it in place through an open sharing protocol instead of receiving extracted copies. Under the hood, SAP uses Delta Sharing, the open protocol for sharing tables without copying them, so a Databricks workspace, a Snowflake account, or Google BigQuery can mount an SAP data product and query it with its own engine. In June 2026 Databricks announced OpenSharing, the next evolution of Delta Sharing, now hosted by the Linux Foundation; existing Delta Sharing integrations remain compatible, and Databricks' own documentation now describes the SAP connector in OpenSharing terms.
Data stays in BDC: SAP data products live in BDC's object store; the partner platform reads them where they are rather than landing a second copy.
Metadata travels with the share: Data products are described with SAP's open metadata standards (Open Resource Discovery and CSN), so table and column meaning arrives with the data instead of being reverse-engineered.
Queries run on the consumer's engine: Databricks SQL, Snowflake, or BigQuery executes the query against the shared tables, using that platform's compute.
Access is granted per data product: A BDC user with sharing rights chooses which data products go to which connected platform, and the consuming platform's own controls (Unity Catalog, Snowflake roles, Google Cloud IAM) decide who can query them there.
The SAP Business Data Cloud Strategy
BDC Connect exists within SAP's larger Business Data Cloud strategy, which accepts that modern enterprises run analytics across several platforms and need shared business context without forcing all data into one silo. Instead of asking customers to move SAP data into every platform, SAP curates it once as governed data products and shares those outwards — while letting partner platforms share their results back so SAP Analytics Cloud, Datasphere, and intelligent applications can use them.
Zero-Copy Sharing vs. Traditional Approaches
Physical Replication: Copies all data to destination system. High storage costs, latency from ETL processes, data freshness challenges, governance complexity across copies.
Federation (Virtual Integration): Queries remote data at query time without replication — for example, SAP Datasphere remote tables over Google BigQuery or Amazon Athena. Query performance depends on network latency and source system load, with limited caching and complex optimization for heterogeneous sources.
Zero-Copy Sharing (BDC Connect): Shares governed data products natively between platforms through Delta Sharing, so each platform's own engine queries the same stored data. Business meaning travels with the data product, queries are optimized by the consuming platform, and there is no extraction pipeline to operate.
BDC Connect Architecture
Understanding how BDC Connect fits into your data landscape is crucial for implementation planning. The architecture spans three layers: source platforms, SAP orchestration, and consuming applications.
How Data Flows Through BDC Connect
1. Data products in BDC: SAP-managed data products are curated from SAP applications such as SAP S/4HANA and SAP SuccessFactors into BDC's object store; custom data products are built in SAP Datasphere's object store, including BW data exposed through the Data Product Generator.
2. One-time connection: An SAP BDC administrator provisions a BDC Connect instance in SAP for Me and exchanges an invitation link with the partner platform's administrator; trust between the platforms is established with mutual TLS and OpenID Connect.
3. Share and mount: A user with sharing rights selects data products in the BDC catalog and shares them to the connected platform, where they are mounted — as a shared catalog in Unity Catalog, as a catalog-linked database in Snowflake, or in BigQuery and Google's Knowledge Catalog — and queried with that platform's engine.
4. Share back: Results built on the partner platform, such as ML features or enriched datasets, are published back to the BDC catalog as data products described with ORD and CSN metadata, where SAP Analytics Cloud, Datasphere, and intelligent applications can consume them.
Key Architectural Patterns
SAP data out to the lakehouse: Share SAP-managed data products into the platform your data engineers and data scientists already use, and keep the business meaning attached. This is the most common starting point.
Round trip for AI and ML: Train or score models on shared SAP data in Databricks, Snowflake, or BigQuery, then publish the results back into BDC so planning and analytics in SAC can use them without another pipeline.
Hybrid sourcing: Keep harmonization-heavy modeling in SAP Datasphere, share the curated result outward with BDC Connect, and use replication or federation only where a specific source, target, or latency need requires it.
BDC Connect by Platform
BDC Connect rolled out to different platforms on different timelines. Here's the state of zero-copy sharing across major cloud analytics platforms as of November 2026:
Databricks
GA October 2025
Integration: OpenSharing (formerly Delta Sharing) into Unity Catalog
BDC Connect for Databricks shares SAP data products into existing Databricks workspaces through zero-copy sharing — Delta Sharing, which Databricks now calls OpenSharing — with Unity Catalog as the governance and discovery layer; once connected, the SAP BDC account acts as both a share provider and a recipient. SAP Databricks, the Databricks environment provisioned inside BDC, has been generally available since April 2025, and at SAP TechEd 2026 the partners announced Lakeflow, Agent Bricks, Unity Gateway, and Lakebase for SAP Databricks plus a Joule–Genie integration.
Key capabilities:
Mount shared SAP data products as Unity Catalog catalogs
SAP semantic metadata (comments, keys, governance tags) synced into Unity Catalog
Publish Databricks results back to the BDC catalog
Workspaces on AWS, Azure, and Google Cloud
Use cases:
Train ML models on governed SAP data
Send Databricks predictions back to BDC for SAC planning and reporting
Combine SAP and non-SAP data in one lakehouse
Snowflake
GA May 2026
Integration: Snowflake Zerocopy Connector for SAP BDC
BDC Connect for Snowflake shares SAP data products with existing Snowflake accounts, where they are mounted as catalog-linked databases and queried directly — including joins across several data products. Customers who prefer a Snowflake environment inside BDC can use SAP Snowflake instead; both became generally available in May 2026.
Key capabilities:
Mount SAP data products as catalog-linked databases
Bidirectional: publish Snowflake data back to BDC
Cross-cloud and cross-region connections
Access managed through Snowflake roles and connector privileges
Use cases:
Snowflake-centered analytics teams that need SAP business data
Joining SAP data products with non-SAP data in Snowflake
Returning enriched datasets to SAP for planning and analytics
Google BigQuery
GA July 2026
Integration: Delta Sharing with BigQuery and Knowledge Catalog
BDC Connect for BigQuery gives zero-copy, bi-directional access: SAP tables, metadata, and business semantics appear in BigQuery and Google's Knowledge Catalog (formerly Dataplex), and Google-side data products can be published back to BDC through BigLake Delta Sharing. At general availability it supports BDC tenants hosted on Google Cloud and AWS, with Azure-hosted tenants to follow.
Key capabilities:
Query SAP data products in place from BigQuery
Discovery through Knowledge Catalog
Publish BigQuery data products back to BDC
Generally available globally for Google Cloud customers
Use cases:
GCP-native analytics ecosystems
Vertex AI and BigQuery ML on governed SAP data
Combining SAP data with Google datasets such as Maps or Trends
Microsoft Fabric
Public preview
Integration: Zero-copy sharing with Microsoft OneLake
BDC Connect for Microsoft Fabric, announced at Microsoft Ignite in November 2025, is designed for bi-directional zero-copy sharing between BDC and OneLake, so SAP data products can be analyzed in Power BI and other Fabric experiences and Fabric datasets can flow back into BDC. General availability was originally targeted for Q3 2026; at the time of this review it is in public preview and no GA date has been confirmed.
Key capabilities (as announced):
SAP data products available in OneLake without replication
Fabric datasets shared back into BDC
Analysis with Power BI, including Copilot in Power BI
Multi-agent collaboration between Microsoft 365 Copilot and Joule
Use cases:
Microsoft-centered analytics estates
Power BI on governed SAP data products
Until GA: Microsoft's mirroring for SAP Datasphere as the supported interim path
When to Use BDC Connect (vs. Other Methods)
BDC Connect isn't always the right tool. Choosing between zero-copy sharing, federation, replication, and live connections depends on where the data lives, which engine needs to query it, and how fresh it must be:
BDC Connect vs. SAP Datasphere Federation
Use BDC Connect when: SAP data products need to be used inside Databricks, Snowflake, or BigQuery — or results from those platforms need to come back into BDC — and you want each platform's own engine and governance to work on the shared data without an extraction pipeline.
Use Datasphere Federation when: Datasphere itself needs to read a remote source at query time — a database, a data warehouse that is not connected through BDC Connect, or a service such as Amazon Athena — to combine it with SAP models in Datasphere and SAC.
BDC Connect vs. Datasphere Replication
Use BDC Connect when: The data already exists as a data product in BDC, several platforms need the same governed data, and you want to avoid running one replication flow per consumer.
Use Datasphere Replication when: You need data from a source that is not yet a data product, want to transform it locally in Datasphere, or must deliver it to a target that cannot consume a Delta share — Datasphere's premium outbound integration exists for exactly that.
BDC Connect vs. SAC Live Connections
Use BDC Connect when: The consumer is a data platform rather than a dashboard — data engineering, data science, or AI work that needs SAP business data next to non-SAP data.
Use SAC Live Connections when: Business users need stories and planning directly on an SAP source or on Datasphere models, with the data staying where it is and SAC handling the presentation.
Decision Matrix
Multi-Platform Governance
Need unified governance across Databricks, Snowflake, BigQuery?
✓ Use BDC Connect
Sub-Second Query Latency
Every millisecond counts in operational dashboards?
✓ Use Live Connections or Replication
Complex Transformations
Need to harmonize and enrich data before delivery?
✓ Use Datasphere + BDC Connect
Cost-Constrained Large Data
Billions of rows, limited storage budget?
✓ Use BDC Connect
Zero-Copy vs. Replication: Decision Framework
The fundamental trade-off in modern data integration is choosing between zero-copy sharing (via BDC Connect) and physical replication. Neither is universally "better"; the choice depends on your use case, cost model, and performance requirements.
Choose Zero-Copy Sharing (BDC Connect) When
Data volume is large: Copying large SAP datasets into every platform is expensive and slow; sharing the data product once avoids a pipeline per consumer.
Several platforms need the same data: If data engineering works in Databricks and analytics in Snowflake, both can mount the same SAP data product instead of maintaining two extracts.
Business meaning matters: Shared data products arrive with SAP's metadata, so teams spend less time decoding SAP tables.
Results should flow back: Models and enriched datasets can be published back into BDC for SAC planning and analytics.
You want compute where the users are: Queries run on the consuming platform's engine, so its existing capacity management and cost controls apply.
Choose Replication When
The source is not a data product yet: Data that isn't available as an SAP-managed or custom data product has to be brought in another way first.
The target can't consume a share: Systems without Delta Sharing support or a BDC Connect partner connector still need replicated data.
You need local transformation: Datasphere transformations on replicated data can be simpler and cheaper than reshaping data on every consuming platform.
Compliance or data residency rules apply: Some regulations require data to be stored in specific regions or systems. Replication lets you control placement explicitly.
Your team is fluent in replication tooling: Cultural and skill factors matter. Replication flows and established ETL tools may be faster to implement in the short term.
Hybrid Approach (Recommended for Most Organizations)
Share curated SAP data products outward with BDC Connect, keep harmonization-heavy modeling in Datasphere, and replicate only the sources and targets that cannot take part in sharing. This balances cost, latency, and complexity.
Example: A retail organization shares its SAP sales and customer data products with Snowflake, where marketing joins them with web and loyalty data. The resulting customer segments are published back into BDC, and SAC uses them for campaign and inventory planning — with no nightly extract in either direction.
Who Pays for What
Zero-copy sharing changes where costs land rather than removing them. On the SAP side, BDC Connect is a BDC capacity service metered on inter-region data transfer (per GB) and processing requests (per block of API calls), so keeping BDC and the partner platform in the same region avoids the transfer charge.
On the partner side: Every query against a shared data product runs on the consuming platform and uses its compute — Databricks compute, Snowflake credits, or BigQuery capacity. A dashboard or notebook that fires many queries per refresh adds up there, not in BDC.
Practical rule: Model the consumer-side compute before you promise savings, and watch both bills; avoiding replication saves storage and pipeline effort, not query cost.
Implementation Considerations
Prerequisites and Licensing
SAP Business Data Cloud: BDC Connect is only available with an SAP BDC subscription. An administrator provisions a BDC Connect instance in SAP for Me and assigns capacity units to it; SAP notes that this quota is not enforced, so monitor actual consumption. Check with your SAP account team how sharing volume and region choices affect your capacity units.
Cloud Platform Requirements:
Databricks: A Unity Catalog–enabled workspace; a workspace admin with CREATE PROVIDER and CREATE RECIPIENT privileges completes the SAP BDC connection with the invitation link from the SAP BDC admin
Snowflake: A Standard, Enterprise, or Business Critical account on AWS or Azure in a supported commercial region (trial accounts are excluded); a Zerocopy Connector enrolled with a single-use invitation link from SAP for Me (created automatically for SAP Snowflake accounts); Snowflake's offering-specific terms for the connector accepted; and share-back enabled if you want to publish data to BDC
BigQuery: The BigLake API and a BigLake Delta Sharing catalog enrolled with your SAP BDC environment, in the same project and region as the data you publish
Microsoft Fabric: Currently a public preview; confirm requirements with SAP and Microsoft before planning production use
Network Connectivity: Sharing runs between cloud services, so plan region placement early. SAP requires the BDC Connect instance to sit in the same region and on the same hyperscaler as the data products it shares — data products hosted in several data centers need one BDC Connect instance per location — while the partner platform itself may run on a different hyperscaler or in a different region — Snowflake, for instance, documents cross-cloud and cross-region connections. Cross-region traffic is metered, so placement is a cost decision as well as a technical one.
Network and Security Configuration
Trust between platforms: The connection is established by exchanging an invitation link between the SAP BDC administrator and the partner platform's administrator, and secured with mutual TLS and OpenID Connect rather than shared passwords.
Databricks: After the connection is created, the SAP BDC account appears as both a share provider and a recipient, governed through Unity Catalog permissions
Snowflake: Roles need privileges on the Zerocopy Connector to mount shared data products as catalog-linked databases or to publish shares back
BigQuery: Shared SAP data products are governed in BigQuery and Knowledge Catalog with your Google Cloud IAM controls
SAP BDC: Users need catalog roles that allow them to share data products to target systems
Network Isolation: SAP publishes the domains and IP ranges used by BDC Connect, and partners document their own private-connectivity options — Databricks on AWS, for example, supports PrivateLink to the SAP-managed storage behind shared data products, set up with SAP's assistance. Involve both sides before the first share.
Performance Considerations
Query Performance: Because queries run on the consuming platform, performance depends on that engine, the size of the data product, and how well queries filter it — not on a round trip through Datasphere.
Optimization Strategies:
Share curated, analysis-ready data products rather than raw extracts
Filter early and select only the columns you need in partner-side queries
Materialize frequently used joins or aggregates on the consuming platform when that is cheaper than recomputing them
Keep BDC and partner workloads in the same region where possible
Cost Implications: Partner-side queries consume Databricks compute, Snowflake credits, or BigQuery capacity, while BDC Connect itself consumes BDC capacity units for cross-region transfer and processing requests. Monitor both sides to catch runaway workloads.
Governance Implications
Data Lineage: Lineage does not automatically span platforms. BDC describes data products with ORD and CSN metadata and each partner catalog tracks usage on its side, so impact analysis across SAP and partner platforms needs an explicit operating model.
Access Control: Governance happens in two places: BDC decides which data products are shared with which connected platform, and the consuming platform decides which of its users can query them. Since September 2026, BDC's data product governance can also require consumers to accept terms and a data steward to approve access, leaving a permanent access agreement.
Compliance and Audit: Queries are logged by the consuming platform's own audit facilities, while sharing decisions are made in BDC. For GDPR, HIPAA, or SOX evidence, plan how you will combine both trails — and note that partner terms can restrict onward sharing of SAP data products outside your own accounts. Zero-copy also does not mean nothing is ever stored on the partner side: SAP permits caching accessed data where a use case requires it, and Google notes that a BigQuery connection stores cached data at rest in its region, so include partner regions in data-residency reviews.
Common Misconceptions About BDC Connect
Myth 1: "Zero-Copy Means No Performance Impact"
Zero-copy refers to data movement, not query cost or latency. Every query still runs on the consuming platform's engine against the shared tables, so poorly filtered queries are as slow and as expensive as they would be on any other large table.
Myth 2: "We Can Replace All Replication with BDC Connect"
BDC Connect covers data that exists as a data product and platforms that can consume a share. Sources that are not data products yet, targets without a connector, and local transformation needs still call for replication or federation. Hybrid approaches are common.
Myth 3: "It Only Works with SAP Data"
The outbound direction carries SAP data products, but sharing is bi-directional: data built in Databricks, Snowflake, or BigQuery — including non-SAP data combined there — can be published back into the BDC catalog as data products for SAP Analytics Cloud, Datasphere, and intelligent applications.
Myth 4: "It Eliminates the Need for Datasphere"
SAP-managed data products can be shared without any Datasphere modeling, but Datasphere still matters: it is where custom data products are built, where harmonization happens, and where SAC models get their semantic layer. BDC Connect moves governed data between platforms; it does not design it.
Myth 5: "All Platforms Have Full Parity"
Rollout is staggered. Databricks (GA October 2025), Snowflake (GA May 4, 2026), and Google BigQuery (GA July 2026) are generally available; Microsoft Fabric is in public preview with general availability not yet announced; and Amazon Athena, announced with AWS at SAP Sapphire 2026, is planned for H1 2027. Capabilities vary by platform maturity. Check current status before locking in architectural decisions.
Limitations and Boundaries
Technical Limitations
Supported Data Types: BDC Connect shares tabular data products through Delta Sharing. Native Apache Iceberg support in BDC is part of the lakehouse capabilities announced at SAP TechEd 2026 (general availability planned for Q1 2027), and sharing documents or other unstructured content is not part of SAP's documented scope for BDC Connect.
Transformation Scope: BDC Connect shares data as it is defined in the data product. Reshaping happens either before sharing (in Datasphere or in the data product definition) or after sharing on the consuming platform, so decide deliberately where each transformation belongs.
Freshness: Consumers see the data product's current state, so freshness is governed by how often the data product itself is updated in BDC. It is not a substitute for event streaming or operational real-time integration.
Operational Boundaries
Two-Sided Availability: A share depends on both BDC and the partner platform being available. Plan monitoring and incident ownership across both sides rather than assuming one team can see everything.
Governance Propagation: Revoking or changing a share in BDC and changing permissions on the partner platform are separate actions. Test how quickly each takes effect before you rely on it for highly sensitive data.
Contractual Boundaries: Partner terms can limit what you may do with shared SAP data products — for example, Snowflake's terms bar sharing SAP data products in their original form outside your own accounts unless your SAP agreement permits it. Databricks' documentation also states that, when workloads include SAP data shared through its connector, Databricks may disclose per-workload usage information to SAP for billing and administrative purposes.
Cost Considerations
Consumer Compute: Every query against a shared data product consumes the partner platform's compute. A notebook or dashboard that runs many queries per refresh can add up quickly; caching and aggregation on the consuming side are the main cost controls.
BDC Capacity: Building and refreshing custom data products, and cross-region sharing through BDC Connect, consume BDC capacity units like any other workload. Size them with SAP's estimator instead of assuming sharing is free.
Related Reading
Explore connected topics to deepen your understanding of SAP analytics integration patterns:
Integrations Overview
Comprehensive guide to all SAP analytics integration approaches, including federation, replication, and live connections.