Concept card

SAP Business Data Cloud (BDC)

As of 2026-10-10

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is SAP Business Data Cloud (BDC)?

SAP Business Data Cloud, BDC, is SAP's current flagship analytics platform, and the thing to understand first is that it is a packaging decision as much as a technical one.

What is SAP business data cloud?

SAP Business Data Cloud (BDC), launched in 2025, is a single offering that bundles SAP Datasphere, SAP Analytics Cloud, an embedded Databricks platform and Joule under one governance catalogue, and delivers ready-made SAP data products and insight applications on top. It does not replace Datasphere — it contains it — and it is SAP's stated target for analytics landscapes migrating away from BW.

SAP business data cloud?

SAP Business Data Cloud is SAP's 2025 analytics and data platform offering: a managed bundle of SAP Datasphere, SAP Analytics Cloud, an embedded Databricks environment and Joule, governed by one catalogue and fed by SAP-delivered data products. It is the target landscape SAP names for BW customers facing the 2027/2030 maintenance horizon, and the platform under which Datasphere and SAC are now sold.

What is SAP BDC?

SAP BDC is SAP Business Data Cloud, launched in 2025: a single offering that bundles SAP Datasphere, SAP Analytics Cloud, an embedded Databricks platform and Joule under one governance catalogue, and delivers ready-made SAP data products and insight applications on top. It does not replace Datasphere — it contains it — and it is SAP's stated target for analytics landscapes migrating away from BW.

SAP Business Data Cloud, BDC, is SAP's current flagship analytics platform, and the thing to understand first is that it is a packaging decision as much as a technical one. It brings together SAP Datasphere as the semantic layer, a Databricks-managed lakehouse as the open-format storage tier, Joule agents as the AI-consumption surface, the SAP Knowledge Graph as the semantic-AI substrate connecting business entities across the estate, and a shared Catalog-plus-DAC governance plane spanning all of it. None of the individual pieces are new — Datasphere and Joule existed before BDC — what is new is that they now share one governance contract, one catalog, and one billing relationship, rather than being four separately licensed, separately governed products a customer has to wire together on their own.

Why it matters strategically

The customer BDC is built for has a specific, common shape: seventy to eighty percent of their analytics-relevant data sits inside the SAP estate, and the remaining twenty to thirty percent lives in adjacent systems — Salesforce, Workday, a Snowflake or Databricks warehouse the data team already runs, partner data shared through Delta. Before BDC, that customer faced a binary choice with no good middle ground: stay fully inside SAP and lose access to modern lakehouse tooling and machine-learning workflows, or move to an open-stack platform and spend an eighteen-month project rebuilding SAP's business semantics from scratch, typically getting a meaningful share of that semantic modelling wrong because it was never SAP's own team doing it. BDC's pitch resolves that trade-off directly: keep SAP's business semantics native, because Datasphere plus delivered S/4 content ships with the models pre-built; gain lakehouse and machine-learning capability native, because Databricks now runs inside BDC's billing and governance boundary rather than as a bolt-on integration project.

How the five pieces fit together

The Catalog is the piece that makes the other four behave as one stack rather than four products on a shared invoice — it is the unified metadata layer carrying semantic types, lineage, Data Products, and DAC rules across both the Datasphere and the Databricks sides, and without it BDC really would just be a bundle. Datasphere continues to do what it always did — Analytic Models, hierarchies, currency conversion, push-down execution against HANA Cloud — but now resolves its catalog from BDC scope rather than a standalone tenant. The Databricks-managed lakehouse provides Delta-format storage governed through Unity Catalog, reachable through Spark notebooks, MLflow, or DBSQL, pre-provisioned and billed through SAP rather than negotiated as a separate Databricks contract. Joule agents consume Datasphere Analytic Models for business context and can write back through guarded actions, with every DAC rule defined at the Catalog level applying automatically to whatever Joule surfaces in an answer. The Knowledge Graph sits underneath as the connective layer linking Customer, Material, Order, and other core business entities across the estate, exposed to both Joule and Datasphere as queryable context rather than requiring each consuming tool to rebuild that entity graph on its own.

Decision framing: when BDC is the right call

The trade-off a consultant needs to walk a client through honestly is cost-and-lock-in versus speed-and-coherence. Choosing BDC over an assemble-it-yourself architecture of standalone Datasphere plus standalone Databricks plus custom governance buys faster time-to-value — the semantic and governance wiring between the pieces ships pre-built rather than as bespoke integration work a systems integrator would otherwise bill for — at the cost of committing to SAP's packaging, pricing, and roadmap pace for that wiring, instead of choosing best-of-breed components and integrating them independently. For a customer whose analytics estate really is SAP-majority, that trade usually favours BDC; for a customer whose data footprint is genuinely balanced or open-stack-majority, standalone Datasphere federating into a lakehouse the customer already governs may be the better-fitting, less locked-in architecture, and it is worth modelling both paths explicitly before recommending BDC as the default answer.

Pitfalls and anti-patterns

The most common mistake is positioning BDC to a client as Datasphere with extra features — it undersells the governance unification that is the actual differentiator, and it sets the wrong expectation about migration effort, since moving an existing standalone-Databricks estate into BDC's governance boundary is a real project, not a toggle. A second pitfall is assuming BDC removes the need for a Databricks specialist on the team because SAP now manages it — the lakehouse still needs someone who understands Spark, Delta, and Unity Catalog day to day; BDC changes who bills for the infrastructure, not who needs to operate the workloads running on it. A third anti-pattern is treating the Knowledge Graph and Catalog as optional pieces to configure later — because they are what makes BDC more than a bundle, deferring them simply reproduces the pre-BDC fragmentation problem inside a BDC contract, with the added cost of the platform itself sitting on top.

Where BDC sits inside the SAP Business AI Platform, September 2026

Since Sapphire 2026 (2026-05-12/13), SAP markets BDC not as a standalone analytics product but as the data foundation of the broader SAP Business AI Platform, the umbrella that now unifies BTP, BDC and SAP Business AI under one governed environment. Concretely, that means every governed Data Product BDC's Catalog publishes is also the substance the generative AI hub's orchestration service grounds against when a Joule agent or a custom AI Core application needs document- or data-grounding rather than parametric memory alone — BDC's Catalog and DAC rules are not a separate governance system sitting beside Business AI, they are the governance system Business AI reads.

Two concrete, dated developments change what a BDC engagement should scope for in September 2026. First, SAP-RPT-1.6 (and 1.6-large) superseded SAP-RPT-1.5 as the current tabular-foundation-model generation on the generative AI hub, alongside a new Tabular Orchestration workflow and an RPT Playground API (up to 1,000 requests/hour) — any BDC data product with the right shape (structured, tabular, containing patterns a customer wants predicted rather than just reported) can now be handed to RPT directly through the hub, without a separate ML pipeline. Second, TabPFN-3.5-Plus (from SAP's July 2026 Prior Labs acquisition) went GA inside SAP AI Core on 2026-09-15, with a limited-time 50% promotional rate through end of September 2026 — a genuinely new, in-context-learning alternative to RPT for a BDC data product a client wants predictions from quickly, with no separate training step. Neither of these is a BDC feature per se; both consume BDC data products as their input, which is exactly the pitch that BDC's Catalog is the piece a pure lakehouse vendor cannot sell a client — it is now also the piece the client's AI Core spend depends on being clean and governed in the first place.

What the contract market asked for, 27 September – 6 October 2026

Seven of the ten missions listed for 1–2 October were in Germany, with one each in Switzerland, the US and Romania: the German-speaking market was where BDC was asked for most, usually as a named product in the title (“Data Architect & Engineer SAP Business Data Cloud”, “Senior Developer, SAP Analytics & Business Data Cloud”).
BDC rarely appeared alone: it was paired with BW/4HANA in one German title, with SAC in another, and with Enterprise Performance Management in the Swiss one. For a practitioner this confirms that BDC work is being sold as a bridge from an existing BW and SAC estate, not as a greenfield platform.
The roles skewed senior and technical: data architect and engineer, senior developer, senior consultant. A US mission asked for a Datasphere architect and a Romanian one for an analytics data engineer across BW, SAC and Datasphere, so Datasphere skills stayed a co-requirement wherever BDC was named.
One German mission combined S/4HANA analytics with AI in its title, which fits the card’s argument that the Catalog and data products, not the lakehouse alone, are the part clients are staffing for.

SAP Connect 2026 (5–7 October 2026)

SAP Connect did not announce new SAP Datasphere, SAP Analytics Cloud or BDC Connect features in the sources reviewed for this card, nor any change to BDC pricing; BDC appears as the foundation under other announcements. Four are relevant. First, SAP Reltio in SAP Business Data Cloud, based on the acquired Reltio technology, is generally available now (innovation news guide): it resolves fragmented records about customers, suppliers, products, locations and other entities across SAP and non-SAP systems into trusted, multi-domain golden records with relationships and hierarchies, as a "system of context" for applications and AI agents; SAP states it is complementary to SAP Master Data Governance, which keeps governance and process control at the SAP application source. Second, SAP Enterprise Financial Consolidation is built with BDC components and uses SAP-curated data products for its consolidation and disclosure assistants; early adopter care is planned for Q1 2027 (C042). Third, the Spend Connect keynote demoed Spend Intelligence with SAP Business Data Cloud (21:13), with no availability statement. Fourth, new SAP-managed integration services for SAP Cloud ERP Private build on the existing BDC integration.

For architects, the positioning sentence from the press release is the one to quote: BDC and SAP Knowledge Graph "ground those agents in trusted business data and context". The decision framing of this card does not change; add entity resolution (SAP Reltio) to the list of BDC capabilities to evaluate when agents need one view of a customer or supplier across systems.

Update of 10 October 2026

8 Oct 2026 - Joule Work reads from BDC. SAP says Joule Work, the new AI user interface now starting customer rollout (all customers 'later this month', no formal GA date), draws all its data from Business Data Cloud, which unifies SAP and non-SAP sources. Practical reading: data-product quality and governance in BDC become the entry condition for Joule Work value; the productivity figures SAP quotes are vendor-reported.
9 Oct 2026 - custom data products need a lifecycle. An SAP Community guide covers the Data Sharing Cockpit in Datasphere / BDC: statuses and allowed transitions, semantic versioning, artifact updates and safe deletion. Treat each custom data product as a versioned contract with an owner and a deprecation path, not as a one-off publication.
9 Oct 2026 - PaPM consumes data products. SAP PaPM Cloud Universal Model adds a 'BDC Data Product' connection type that reads harmonised BDC data products through a targeted HANA schema, so profitability and performance models can use them without custom integration.

Why it matters

Without the Catalog, BDC collapses to two separately-governed products in one wrapper — it is the integrative piece, not Datasphere or Databricks individually.
The Databricks lakehouse is pre-provisioned and SAP-billed inside BDC, so the customer never carries a second, separate Databricks contract — a real commercial simplification to quote.
The sales argument rests on an actual number: a typical SAP customer already has 70-80% of analytics-relevant data in SAP, so SAP-semantics-out-of-box plus cross-tool governance is the differentiator, not raw lakehouse capability.

Key points

Five components: Catalog (integrative) + Datasphere + Databricks lakehouse + Joule + Knowledge Graph.
GA as of 2026-05: all five components integrated. SAP Knowledge Graph was announced at SAP TechEd (Oct 2024) and made available via Datasphere and Joule from Q1 2025; the HANA Cloud knowledge graph engine went GA in Q1 2025.
Pricing: 128 CU minimum (vs 64 standalone); €100-180k/yr entry FY26.
Decision rule: BDC for > 5 TB + ML/notebook + want unified governance; standalone for < 5 TB + no ML.
Hot/cold partition: HANA Cloud for sub-second queries (SAC > 10×/day); Delta for cold/historical/ML.
Cross-domain joins → Datasphere Analytic Models. ML feature engineering → Databricks notebooks.
BDC Catalog spans both sides — single DAC rule reaches every consumer.
BW → BDC migration is the €4B+ market: ~4,000 BW MEE customers (Analytics Legends estimate, Q1 2026).
SAP Connect (6 October 2026): SAP Reltio in SAP Business Data Cloud is generally available now — entity resolution and golden records across SAP and non-SAP systems, complementary to SAP Master Data Governance; no new Datasphere, SAC or BDC Connect feature was announced at Connect in the sources reviewed.
Joule Work (rollout from Oct 2026) draws all its data from BDC: data-product governance is the gating factor (SAP-announced).

Common pitfalls

Pitching BDC as 'Datasphere with extra features' — Signal: A proposal describes BDC purely in terms of new Datasphere functionality, with no mention of the Catalog's cross-engine governance role. Fix: Lead with the Catalog and DAC unification across Datasphere and Databricks as the actual differentiator, and set migration-effort expectations accordingly — moving an existing standalone-Databricks estate into BDC's governance boundary is a real project, not a toggle.
Assuming BDC removes the need for a Databricks specialist — Signal: A staffing plan drops Spark/Delta/Unity Catalog expertise from the team because 'SAP now manages Databricks'. Fix: Clarify that BDC changes who bills for the infrastructure, not who needs to operate the workloads running on it — the lakehouse still needs someone fluent in Spark, Delta, and Unity Catalog day to day.
Treating the Knowledge Graph and Catalog as optional pieces to configure later — Signal: A delivery plan defers Catalog and Knowledge Graph setup to a 'phase 2', treating Datasphere and Databricks provisioning as the real phase 1 deliverable. Fix: Sequence Catalog and Knowledge Graph configuration into phase 1 — deferring them reproduces the pre-BDC fragmentation problem inside a BDC contract, now with the platform's own cost sitting on top.
Quoting the 128-CU entry floor as sufficient for a Tier-1 workload — Signal: A proposal prices a Tier-1 engagement at the 128-CU minimum without a workload-by-workload sizing breakdown, then discovers mid-project that peak-hour SAC and Joule usage exceeds the provisioned pool. Fix: Treat 128 CU as the entry price of admission, not a sizing answer — build the quote from the customer's actual peak workload mix before committing to a number a finance stakeholder will hold the team to.

Decision framework

Decision framework
Decision	Option A	Choose A when	Option B	Choose B when
BDC versus assembling standalone Datasphere + standalone Databricks + custom governance	Adopt BDC	The customer's analytics estate is SAP-majority (roughly 70-80% SAP-native data) and faster time-to-value matters more than avoiding SAP's packaging and roadmap pace for the governance wiring.	Assemble standalone components	The customer's data footprint is genuinely balanced or open-stack-majority, and the customer already governs a lakehouse it wants to keep operating independently of SAP's contract terms.
Where to define Data Access Control rules in a BDC estate	Define the rule once at the BDC Catalog level	The rule must apply identically regardless of whether the data product is queried from Datasphere, Databricks notebooks, SAC, or Joule.	Define separate rules per consuming tool	Only ever as a temporary stopgap while a Catalog-level rule is being migrated in — as a first design choice it reproduces the pre-Catalog fragmentation problem BDC exists to solve.

How SAP compares

How SAP compares
Capability	SAP	Snowflake	Databricks	Microsoft Fabric
Unifying governance layer across a multi-engine data stack	BDC Catalog — one metadata layer spanning Datasphere (HANA Cloud) and the managed Databricks lakehouse, with DAC rules and lineage shared across both.	Snowflake's own catalog and RBAC govern Snowflake-native objects; a BDC-shared data product appears there as an ordinary table, governed by BDC's DAC on the SAP side and Snowflake's own RBAC on the consuming side — two rule sets, not one.	Unity Catalog governs Databricks-native objects; inside BDC's managed Databricks it operates under the BDC Catalog's umbrella, but a customer-run standalone Databricks estate outside BDC keeps Unity Catalog as its only governance layer.	Microsoft Purview and OneLake governance apply within the Fabric estate; a BDC data product mirrored into OneLake is governed on the Fabric side by Purview, not by BDC's Catalog.
Minimum entry-level tenant sizing	BDC tenant floor: 128 Capacity Units (vs. 64 CU for a standalone Datasphere tenant), reflecting the wider simultaneous workload mix (replication, live analytics, planning, Joule, Knowledge Graph).	Snowflake sizing is warehouse-based (credits per compute-second); no equivalent fixed CU floor, cost scales with actual query volume rather than a tenant minimum.	Databricks-side sizing inside BDC is DBU-based and billed through SAP; a standalone Databricks workspace outside BDC has no BDC-style tenant floor either.	Microsoft Fabric sizing uses F-SKU capacity units, billed separately from any BDC Capacity Units — an additive, not bundled, cost line for a customer running both.

Facts worth quoting

BDC unifies Datasphere (semantic layer), a Databricks-managed lakehouse, Joule agents, the SAP Knowledge Graph, and a shared Catalog-plus-DAC governance plane into one governed, one-billed stack, rather than four separately licensed products.
The customer profile BDC targets typically has 70-80% of analytics-relevant data already inside the SAP estate and 20-30% in adjacent systems (Salesforce, Workday, Snowflake/Databricks, partner Delta shares).
Databricks runs pre-provisioned and SAP-billed inside BDC's governance boundary — customers do not negotiate or run a separate standalone Databricks contract.

Sources

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.