SAP Business Data Cloud

Bundled products with defined roles

SAP Analytics Cloud handles user-facing analytics and planning. Datasphere owns semantic modeling and governance. BW/4HANA remains available for coexistence and migration bridge patterns. Databricks integration (GA October 2025) connects ML and advanced analytics workloads directly.

Licensing impact: one capacity-unit pool now covers every BDC capacity service (including SAP HANA Cloud since Sapphire 2026), changing how teams budget and justify individual component investments.

External connectors on rolling timeline

BDC Connect provides native zero-copy sharing with Databricks (GA October 2025), Snowflake (GA May 4, 2026) and Google BigQuery (GA July 2026). Microsoft Fabric is in public preview: general availability was targeted for the second half of 2026 and had not been announced when this page was reviewed in November 2026. Amazon Athena was announced at SAP Sapphire 2026, with general availability planned for H1 2027. These are not ad-hoc integrations; they are strategic connectors designed for governed data sharing without replication.

Architecture impact: teams can now design data foundations that span SAP and non-SAP platforms with unified governance and minimal data movement.

Foundation direction

It reframes how teams talk about enterprise data access, governed business context, and the relationship between platform services and analytics delivery.

Why that matters: the foundation story influences architecture choices long before any single dashboard or model is built.

Relationship clarity

It increases the need to explain what remains the job of SAP Datasphere, SAP Analytics Cloud, governance controls, and modernization planning.

Watch-out: if the relationship map is unclear, the strategic story becomes noise instead of guidance.

With SAP Datasphere

Datasphere remains central for semantic modeling, business meaning, and governed modeling responsibilities. Business Data Cloud changes the foundation context around that work; it does not make semantic discipline optional.

With SAP Analytics Cloud

SAC remains the business-facing analytics and planning layer. Business Data Cloud can strengthen the foundation behind SAC, but it does not replace the need for thoughtful analytics design, adoption, and governance.

With BW modernization

In legacy estates, Business Data Cloud informs future-state direction. It still does not remove the need for realistic coexistence planning, migration choices, and transitional control of business risk.

It does not replace semantic design

Teams still need explicit metric definitions, model ownership, and business-context stewardship. Those responsibilities do not disappear because the foundation story becomes broader or because more non-SAP platforms enter the estate.

It does not design dashboards

Analytics consumption still needs a business-facing layer such as SAC, careful audience design, and fit-for-purpose decision surfaces.

It does not remove modernization complexity

Legacy estates still require sequencing, coexistence choices, migration routes, and operational guardrails. Strategic framing is not a migration plan.

It does not eliminate governance work

Access control, stewardship, lifecycle checkpoints, and policy decisions remain active design work across the stack.

Myth: It replaces everything below it

Reality: Business Data Cloud reframes the foundation conversation, but semantic design, analytics experience, governance, and modernization work still need explicit decisions. The strategic story does not eliminate the need for these layers; it clarifies how they should relate.

Myth: It tells us exactly what to implement next

Reality: It gives direction, not a complete delivery plan. Teams still need realistic sequencing, operating choices, and clear control boundaries. Strategic framing is not an implementation roadmap.

Myth: It makes older stack knowledge irrelevant

Reality: The broader and more ambitious the strategic story becomes, the more important it is to explain how BW, existing Datasphere implementations, and current analytical patterns still fit. Ignoring what works creates false disruption instead of real progress.

Myth: Once we adopt it, everything becomes easier and faster

Reality: Business Data Cloud changes the framing around what the foundation should do and how it should evolve. Actual benefits come from deliberate use of the platform's capabilities—data products, intelligent applications, managed governance—combined with clear operating ownership and realistic timelines.

Executives

Use this page to understand why the SAP foundation story is changing and what strategic questions should be asked before committing to a future-state direction.

Enterprise architects

Use it to separate platform direction from immediate layer responsibilities and to map how foundation choices affect semantics, governance, consumption, and external platforms such as Databricks or Snowflake.

Platform owners

Use it to test whether operating responsibilities, control points, and SAP plus non-SAP handoffs remain explicit underneath the broader platform framing.

Analytics teams

Use it to understand what should change upstream and what should still be solved in SAC, Datasphere, integrations, catalog governance, and broader mixed-landscape design.

Apache Iceberg and Delta Lake table formats

BDC builds on open, industry-standard table formats rather than proprietary SAP ones. Delta Lake is supported today — SAP data products reach SAP Databricks and Databricks workspaces through zero-copy Delta Sharing — and with the Dremio-based lakehouse announced at SAP TechEd 2026, SAP is adding native Apache Iceberg tables and an Apache Polaris–based catalog (general availability planned for Q1 2027). The point is the same either way: Databricks notebooks, Snowflake queries, and BigQuery SQL work against governed SAP data without an intermediate replication pipeline.

Metadata and semantics travel independently

While table data stays in place, business meaning—metrics, dimensions, transformations, lineage, and data quality rules—is captured in the semantic layer (Datasphere) and made available to consuming platforms via APIs and metadata bridges. A Snowflake user can see not just raw tables but a curated set of semantic definitions that SAP has published. This is governance without duplication: a single source of business truth that multiple platforms consume according to their native query and consumption patterns.

Bi-directional sharing capability

Zero-copy is not one-way. While SAP data moves outbound to external platforms, those platforms can also publish data products back into BDC for broader organizational access. A team in Databricks that creates ML features or enriched datasets can make them available through BDC's governance layer for use in SAC, downstream analytics, or other SAP applications. This eliminates data silos between analytics platforms.

Databricks (GA October 2025)

The first BDC Connect integration to reach general availability. SAP data products are shared into Databricks through zero-copy Delta Sharing and are accessible from notebooks, SQL, and MLflow. Unity Catalog integration ensures that Databricks governance (access controls, lineage tracking, audit) is aligned with BDC permissions. Use cases include ML pipelines running on SAP financial and operational data, advanced analytics combining SAP and external datasets, and real-time feature engineering. Teams using Databricks can now consume SAP data without nightly batch exports or custom API connectors. At SAP TechEd 2026 the partnership was extended again: Lakeflow, Agent Bricks, Unity Gateway, and Lakebase are being brought to SAP Databricks inside BDC, alongside a new SAP Application Data Foundation and a Joule–Genie integration.

Snowflake (GA May 4, 2026)

Strategic partnership with Snowflake. SAP data products are shared into Snowflake through its zero-copy integration for SAP Business Data Cloud, with business semantics preserved and sharing running in both directions; SAP also offers SAP Snowflake, a Snowflake environment provisioned inside BDC that has been generally available since May 2026. Snowflake's governance framework (role-based access, query audit, data governance) wraps the shared data products. Key use case: organizations that have unified their analytics platform on Snowflake can now access SAP master data, transactional data, and governed models without building custom adapters or managing parallel data copies.

Google BigQuery (GA July 2026)

Generally available since July 2026, the BigQuery connection is bi-directional and zero-copy: SAP tables, metadata, and business semantics appear in BigQuery and Google's Knowledge Catalog (formerly Dataplex) and can be queried alongside native datasets, while enriched Google data can be published back into BDC. At launch it supports BDC tenants hosted on Google Cloud and AWS, with Azure-hosted tenants to follow. Use cases include combining SAP operational data with Google analytics, AI/ML workloads, and GCP native services (Vertex AI, BigQuery ML). This is particularly valuable for organizations committed to Google Cloud for analytics but requiring SAP system data as part of the pipeline.

Microsoft Fabric (in preview)

Announced at Microsoft Ignite in November 2025, this connection shares SAP data products into Microsoft OneLake through bi-directional zero-copy sharing — no mirroring or replication — so they can be analyzed in Power BI and other Fabric experiences, while Fabric datasets can flow back into BDC. SAP and Microsoft originally targeted general availability for Q3 2026; at the time of this review it is available as a public preview and no GA announcement has been made. Key use case: organizations using Power BI as their analytics platform will be able to work with governed SAP data products without intermediate data warehousing or custom integration logic. Until then, Microsoft's separate mirroring for SAP Datasphere remains the supported way to land Datasphere data in OneLake.

Data Product Studio (announced; GA not yet confirmed)

Announced at SAP TechEd 2025, Data Product Studio is planned as a visual workspace in Business Data Cloud for modeling, configuring, and managing custom data products across SAP and third-party sources, with SQL-based transformations and full lifecycle management. SAP originally planned general availability for H1 2026; at the time of this review SAP had not confirmed that it shipped, so treat it as roadmap. Meanwhile, BDC's September 2026 release added data product governance: producers attach terms of use, consumers accept them, and a data steward approves each access request, leaving a permanent access agreement. Versioning remains the principle to design for, so downstream consumers know they are using a stable, governed asset that won't break unexpectedly.

Business context and quality embedded

A data product is not just a collection of tables; it is a business object that carries metadata about its purpose, owner, refresh frequency, data quality rules, lineage, and relationship to other products. When published to Databricks or Snowflake, this context travels alongside the data, allowing downstream teams to understand what they are working with and whether it is appropriate for their use case. Quality metrics and SLA definitions are part of the product definition, not an afterthought.

Versioning and lineage preservation

Data products support versioning, so breaking changes are managed explicitly. If a new version of a customer data product changes the schema or adds required fields, existing consumers are not immediately affected; they can upgrade to the new version on their schedule. Lineage is tracked end-to-end: from SAP source systems, through Datasphere modeling, to published products, and into external platforms where they are consumed. This creates audit trails and impact analysis that are essential for regulated industries.

Governance without extraction

Because data products rely on zero-copy sharing, the decision about who may consume a product is made once, in BDC, rather than by replicating data and re-creating access rules on every platform. Each consuming platform still applies its own controls to what it receives — Unity Catalog in Databricks, Snowflake's governance in Snowflake — so the operating model needs owners on both sides of every share, not just in Datasphere.

What a capacity unit pays for

CUs are a value-priced currency: each capacity service consumes them at its own rate. Datasphere compute and storage, the data lake, BW Bridge, data integration, and the catalog draw on the pool alongside SAC, SAP Databricks, BW private cloud systems, and HANA Cloud, while BDC Connect is charged on inter-region data transfer and processing requests. This eliminates the artificial boundaries that existed when products were licensed separately, allowing teams to use each product according to actual need rather than pre-allocated license counts.

Minimums and entry points

SAP applies minimum capacities when it provisions the BDC core service and has been lowering them to allow smaller, more modular starts. Per-CU prices and minimums are deal- and region-specific and change over time, so use SAP's Business Data Cloud Capacity Unit Estimator rather than rules of thumb. One packaging fact matters for every plan: since January 1, 2026, SAP Analytics Cloud and SAP Datasphere can no longer be bought or renewed as separate BTP services (BTPEA, CPEA, or pay-as-you-go) — new capacity comes through BDC, while existing contracts run to the end of their term.

Estimating CU requirements

Estimate along the services you will actually run: data volume and storage tier, Datasphere compute, SAC usage, BW private cloud sizing, SAP Databricks workloads, and any cross-region BDC Connect traffic. Then validate against real consumption: during 2026 SAP extended BDC's capacity-unit monitoring with historical views by space and object storage, and since September 2026 object-store requests are metered separately for control-plane, read, and write operations. SAP provides sizing tools and consulting services to help estimate.

Comparison with legacy per-product licensing

Under the old model, a customer would buy separate licenses for SAC users, Datasphere capacity, BW concurrent sessions, and Databricks standard or premium tiers. A 10-user SAC deployment might cost X, a small Datasphere instance Y, and BW licensing Z, with no ability to trade capacity between products. BDC flattens this into one consumption pool: if SAC is underutilized one quarter and Datasphere modeling is intensive, the same capacity can be applied where it is needed. Whether that flexibility lowers total cost depends on utilization: idle capacity is still paid for, so savings come from active FinOps rather than from the licensing model itself.

SQL endpoint access

Datasphere exposes a SQL endpoint that allows direct querying from any SQL-capable tool: Python/R scripts, Jupyter notebooks, traditional BI tools like Tableau or Looker, or custom applications. Queries run against the semantic models in Datasphere, not raw tables, so business definitions and calculations are consistent regardless of what tool connects. Access is governed by the same policies as SAC or Databricks access; a user or service account either has permission to query a data product or does not.

Python client libraries

Data scientists can consume BDC data through Python SDKs that abstract the complexity of connecting to Datasphere. Libraries handle authentication, query building, and result formatting, allowing notebooks and scripts to read data products as DataFrames without writing low-level SQL or managing credentials. This is particularly useful for teams that develop in Jupyter alongside Databricks or SageMaker but want to augment external data with SAP information.

REST APIs for programmatic access

Services and applications that cannot use SQL can access BDC data through REST APIs. Data products and metrics are exposed as queryable endpoints, allowing applications to fetch specific subsets of data or trigger exports. API-based access is also governed; tokens have expiration and scope limits aligned with underlying data product permissions.

ODBC/JDBC drivers for legacy tool integration

Organizations with existing BI tools, custom applications, or legacy systems can connect through standard database drivers. The Datasphere semantic layer appears as a JDBC data source or ODBC-compliant database, minimizing tool changes while providing governed access to BDC data. This is essential for coexistence scenarios where new BDC deployments must interoperate with existing analytics infrastructures.

Provisioning and system formations

BDC is provisioned and managed through SAP for Me, SAP's administrative portal. Teams request a new BDC landscape with a specific CU allocation, and SAP provisions the underlying infrastructure (Datasphere instance, SAC analytics, BW/4HANA system if needed) and links the components into a formation. Updates to the SaaS services are applied by SAP, so there is no upgrade sequencing to coordinate across them; only BW private cloud systems keep their own maintenance schedule.

Monitoring and capacity management

BDC's capacity monitoring shows consumption across the services in a formation — since mid-2026 with history by space and object storage — so administrators can reassign capacity or request more CUs before a service runs short. Legacy environments required separate monitoring tools for each product and manual interventions when one product hit limits while others had excess capacity.

Security and compliance is unified

Infrastructure security, encryption, and compliance operations for the SaaS services are SAP's responsibility. Identity, authorizations, and audit review still have to be designed across SAC, Datasphere, and SAP Databricks — and on every partner platform you share into — before SOX, GDPR, or other regulatory reporting becomes simpler.

Scaling without disruption

Adding CUs is a contract upsize on a single BDC subscription rather than a set of product-by-product license changes, and the pool can then be assigned to whichever service needs it. If a data refresh job begins to exceed its window, or analytics query load increases, the conversation is about capacity, not about which product license to buy.

Industry-specific data products

Partners are developing pre-built data products for manufacturing (predictive maintenance, supply chain optimization), retail (customer 360, inventory analytics), financial services (risk modeling, fraud detection), and healthcare (patient outcomes, resource utilization). The intent is that organizations install governed analytics content alongside SAP's own intelligent packages rather than building custom models and ETL.

Intelligent applications on BDC

ISVs are building applications that use BDC as a data foundation. An HR analytics application, for example, would connect to BDC to read employee, compensation, and organizational data, then layer domain-specific logic (turnover prediction, engagement scoring, skills gap analysis) on top. The underlying data governance comes from BDC; the ISV focuses on domain logic and user experience.

Connectors and extensibility

Partners are also extending BDC's integration capabilities. A custom connector for a specialized data source (IoT platforms, blockchain, proprietary enterprise systems) can be built once and reused across customers — SAP's open data ecosystem already includes partner integrations such as Confluent for streaming data into BDC. This creates a virtuous cycle: more connectors → more data sources can be integrated → more use cases become viable → more ISVs enter the market.

Manufacturing: Predictive maintenance via Databricks

A large industrial manufacturer has equipment sensor data (IoT), maintenance records (SAP PM), and work order history in SAP ERP. The plant engineering team needed to predict equipment failures before they occur to reduce downtime. Using BDC, they published SAP maintenance and operational data as zero-copy products into Databricks. ML engineers built models using sensor data + SAP history without replicating or building custom pipelines. The models score equipment health daily and alert maintenance teams, with one source of maintenance data truth across the enterprise.

Retail: Customer 360 via Snowflake Data Cloud

A multi-channel retailer had customer order data in SAP, CRM interactions in Salesforce, loyalty program data in a separate system, and web analytics in Google Analytics. No unified view of the customer existed. Using BDC, they unified all sources in Datasphere and published a customer master data product to Snowflake Data Cloud with zero-copy sharing. Marketing, operations, and ecommerce teams now query a single customer view in Snowflake for personalization, retention campaigns, and inventory allocation. Single source of truth; no nightly batch syncs; governed access across teams.

Financial services: Risk modeling via BigQuery

A regional bank needed to combine SAP loan origination data with external market data (interest rates, credit indices) for enterprise risk assessment. Using BDC and BigQuery integration, they published SAP lending data as zero-copy products that BigQuery can query. External market data lives in BigQuery natively. ML models in Vertex AI combine both sources for portfolio risk scoring and stress testing. Data governance is managed in Datasphere; query and model governance in BigQuery. The payoff is faster risk reporting cycles and better audit trails for regulatory reporting.

Technology/SaaS: Data mesh foundation

A technology company with multiple product lines needed a decentralized data platform where each business unit could publish governed data products while maintaining central standards. Using BDC, they created a data mesh architecture: each unit models their domain data in Datasphere, publishes them as custom data products (today through Datasphere and BDC sharing; Data Product Studio is intended to become the main workspace), and other units consume via BDC or external platforms. A central governance team maintains quality standards and lineage, and scales to support many product teams instead of becoming the bottleneck.

Palantir Foundry integration

SAP and Palantir announced a partnership at SAP Sapphire 2025 to support joint customers' cloud migration and modernization, with connectivity between Palantir Foundry and AIP and BDC so customers can build one harmonized data foundation. A typical use case: supply chain teams that need SAP procurement and logistics data combined with external supplier risk, port status, and carrier information inside Palantir's operational applications.

Adobe Experience Platform connections

Adobe and SAP announced at SAP Sapphire 2025 that they were co-developing an intelligent application on BDC that combines Adobe Experience Platform marketing data with SAP supply chain and financial data, so demand signals and operational planning stay aligned. The architectural point is governed two-way context between marketing and operations instead of custom ETL and reconciliation jobs.

Moody's analytics and risk intelligence

Moody's first solution on BDC enriches SAP accounts-receivable data with Moody's probability-of-default data to sharpen cash-flow forecasts and collection priorities, and in 2026 Moody's integrated its probability-of-default data estate into BDC. At SAP Connect 2026, SAP also announced that Moody's supplier-risk monitoring will be embedded in SAP Ariba Supplier Lifecycle and Performance, with general availability planned for Q4 2026.

Thomson Reuters trade and tariff intelligence

Thomson Reuters announced an intelligent application on BDC to help customers navigate global trade and tariff changes, modeling total landed costs across alternative scenarios to optimize trade routes. It is a good example of external regulatory and market intelligence used next to SAP transactional data rather than in a separate silo.

Accenture ADVANCE

Accenture and SAP launched ADVANCE in May 2025: preconfigured, industry-tailored packages built on SAP Business Suite — which brings together SAP applications, data, and AI — for growth companies with annual revenue of up to US$5 billion, with Business Data Cloud as the data foundation those customers prepare for. It is a reminder that BDC increasingly arrives as part of a broader cloud program rather than as a standalone analytics purchase.

Data mesh and internal data marketplaces

Organizations are using BDC to enable data mesh patterns where business units act as data producers publishing curated products, and other units act as consumers. The BDC governance layer tracks ownership, quality, lineage, and usage, while capacity-unit economics encourage data reuse (reducing the cost of duplication). Some organizations are building internal data marketplaces where teams are charged back for consumption, creating financial incentives to publish high-quality, well-governed products rather than maintaining isolated datasets.

BDC-first for new analytics programs

Organizations building net-new analytics programs (new company acquisitions, new business units, new markets) should start directly on BDC. Building on a legacy foundation and then migrating adds cost and delays value. BDC-first designs avoid technical debt and obsolete architecture decisions from day one.

Phased migration from BW and legacy stacks

Large organizations with billions of rows in BW, thousands of users, and complex governance cannot migrate everything at once. Phased approaches typically start with: (1) pilot: one business unit or data domain (e.g., supply chain) moves to BDC while others stay on BW. (2) Coexistence: BDC and BW run in parallel, with federated governance and shared master data. (3) Scaling: successful domains expand their BDC footprint while remaining domains are gradually sunset. This typically takes 2-3 years for large enterprises.

SAC modernization within BDC

SAC as a standalone product is still viable for teams that do not need the BDC ecosystem benefits. However, SAC inside BDC gains automatic data governance, zero-copy integration with external platforms, and a clearer upgrade path to AI-assisted features. New SAC deployments should presume BDC as the data foundation.

Datasphere as semantic layer, BDC as platform

This is the key conceptual clarity for architects: Datasphere is the semantic modeling and governed data foundation technology; Business Data Cloud is the strategic platform package that bundles Datasphere with SAC, BW/4HANA, Databricks, and third-party connectors. Datasphere can be deployed standalone for smaller teams or simpler use cases. BDC is the right choice when organizations need integrated governance, cost transparency, and federated access across multiple platforms and teams.

An open lakehouse and more partner connections

With Dremio (acquisition completed July 2026), BDC gains native Apache Iceberg tables, an Apache Polaris–based catalog, and a federated SQL engine that can query lakehouse catalogs and databases such as SQL Server, MongoDB, Oracle, and Postgres without moving data; general availability is planned for Q1 2027. On the partner side, BDC Connect for Microsoft Fabric is in public preview with general availability still pending, and Amazon Athena is planned for H1 2027.

Data product governance and tooling

Governance arrived first: since September 2026, producers can attach terms and conditions to data products, consumers must accept them, and a data steward approves each request, leaving a permanent access agreement (low-risk products can be auto-approved). Data Product Studio, the planned workspace for building custom data products, has not yet been confirmed as generally available, and SAP plans to let developers create and use BDC data products directly inside Joule Studio (general availability planned for Q1 2027).

Deeper AI and generative AI integration

At Sapphire 2026 SAP previewed Joule Agents for BDC that search for and generate data products, build planning and analytical models from a description, answer natural-language questions, and generate SAC stories — offered then as a private preview. At TechEd 2026 SAP added BDC Ontology Manager, which curates domain-specific views of SAP Knowledge Graph for agents (beta planned for November 2026), and announced customer-specific Knowledge Graph context for Joule (general availability planned for Q1 2027).

More curated data products and intelligent packages

SAP keeps extending the curated data products and intelligent packages that come with BDC, organized by line of business and increasingly by industry — for example People Intelligence, Revenue Intelligence, and Retail Intelligence (initially in controlled availability for early adopters). Organizations can activate these with less customization than building domain models from scratch, but they still need to check fit against their own process variants.

Simplified migrations from BW and legacy analytics

For BW, the path SAP documents is to lift existing systems into the private cloud edition inside BDC — SAP BW NetWeaver with maintenance to the end of 2030, SAP BW/4HANA with maintenance to 2040 — and then expose BW data as data products with the Data Product Generator. For planning and consolidation, SAP's new Enterprise Financial Consolidation solution, built with BDC components, is positioned as a path for BPC and SAP Financial Consolidation customers (early adopter availability planned for Q1 2027).

Managed SaaS foundation

Business Data Cloud is positioned as a managed SaaS foundation rather than a do-everything data abstraction. Provisioning, system formations, and cockpit access are part of the operating story.

Data products and intelligent applications

Curated data products and intelligent applications are central to the value story. That means the conversation is about reusable business context, not only about where data lands. Data Product Studio — announced with general availability planned for H1 2026 but not yet confirmed as shipped — is meant to become the central workspace for creating and managing custom data products.

AI-ready by design

Current SAP messaging connects Business Data Cloud directly to SAP Knowledge Graph, Joule agents, SAP AI Core, and SAP Databricks-driven MLOps. That makes AI architecture part of the foundation discussion, not a detached add-on.

Administration is a real design concern

Provisioning in SAP for Me, activating data packages, installing intelligent applications, and monitoring landscape connectivity are all explicit admin tasks. Strategy without an operating model is not enough here.