Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BDC foundation services, and why you never query them directly

As of 2026-08-14

Foundation Services is the layer of SAP Business Data Cloud that manages SAP-managed data products. It discovers what data products the connected SAP applications expose, provides the pipelines that replicate their data into the platform's own data lake object store in read-only form, and manages those files so they stay storage- and access-efficient. You do not query it. To use a data product it manages, you install that product into SAP Datasphere or into SAP Databricks and consume it from there.

What the layer is responsible for

Three responsibilities, narrower than the name suggests.

Discovery: it enumerates the data products available across the connected SAP data sources using the Open Resource Discovery protocol rather than a hand-maintained inventory, which is what makes a delivered catalogue behave as a catalogue instead of a list somebody keeps current.

Replication: it provides the pipelines that connect to the SAP applications and replicate their data into the SAP HANA Cloud data lake object store, in read-only form.

File management: it keeps the resulting data lake files storage- and access-efficient — unglamorous, and the reason the layer exists as managed infrastructure rather than as something a project configures.

Delivery to consumers runs on the Delta Sharing protocol, the same open mechanism the platform speaks to external consumers, so the internal and external paths are not two technologies with two failure modes.

Why you install a product rather than query the layer

Users do not access Foundation Services data directly. The required data product is installed into SAP Datasphere or into SAP Databricks, and consumption happens through whichever the workload belongs in.

That indirection is the design, not a limitation. It keeps one governance contract over the data regardless of which runtime reads it: semantic types, lineage and access rules live in the catalogue, and installing a product into a runtime brings it under that contract rather than creating a second copy with its own rules.

It also answers a support question that comes up early. When a delivered product misbehaves, the first diagnostic is not whether the pipeline is broken but which install is being read, and into which runtime — the same product can be installed into more than one.

The object-store split most teams miss

Foundation Services uses a dedicated object store, and that object store is only for SAP-managed data products. Custom data products — the ones a project builds — use the SAP Datasphere object store instead.

Small architectural fact, large practical consequence. Delivered content and custom content sit in different storage managed by different parts of the platform, which is why a delivered product updates without a project touching it and a custom one does not. It is also why the maintenance asymmetry between them is real rather than rhetorical: when a source upgrade changes an underlying table, the managed side is SAP's problem and the custom side is yours.

For anyone drawing the architecture, the correction is that there is not one lake holding everything. There is a managed store for delivered products and a tenant store for custom ones, both surfacing through the same catalogue.

What Foundation Services is not

It is not the layer that connects external platforms. Bringing in a Snowflake warehouse, an Iceberg lake, a partner Delta share or an externally hosted Databricks workspace is BDC Connect's job; Foundation Services faces inward, at the SAP applications.

It is not the semantic layer either. It replicates and manages files; the modelling, the analytic models, the currency conversion and the access rules live above it.

And it is not something you size a tenant around. Capacity units cover the compute, memory, storage allotment and throughput a tenant consumes across six competing workload types, and the relationship between the managed object store and that allotment is not published as a sizing rule. Treat it as infrastructure you inherit rather than a line you tune.

What this means in delivery

Separate the two catalogues in your own documentation from day one: what is SAP-managed and installed, and what is custom and owned by the project. Those populations have different upgrade behaviour, different ownership and different failure modes, and a single undifferentiated inventory hides all three.

Record which runtime each delivered product was installed into, and why. The choice between the semantic layer and the lakehouse for a given product is a workload decision, and it is nearly always made once, quickly, and never written down.

And resist describing the layer to a client as a feature. Nobody buys Foundation Services; they buy the data products it delivers. Its practical value in a conversation is diagnostic — it tells you where to look when a delivered product behaves unexpectedly, and which half of the estate you actually control.

What we cannot assert

SAP does not publish the replication cadence, the storage allowance or the capacity treatment of the Foundation Services object store, so we state no sizing rule for it. We also state no price, because the layer is not sold separately.

Frequently asked

What are Foundation Services in SAP Business Data Cloud?

The layer responsible for managing SAP-managed data products: discovering what the connected SAP sources expose, providing the pipelines that replicate their data into the platform's data lake object store in read-only form, and keeping those files storage- and access-efficient. Delivery to consumers runs on the Delta Sharing protocol.

Can I query Foundation Services directly?

No. You install the data product you need into SAP Datasphere or SAP Databricks and consume it there. That indirection is what keeps a single governance contract over the data whichever runtime reads it, rather than producing a second copy with its own access rules.

Where do custom data products live?

In the SAP Datasphere object store, not the Foundation Services one, which is reserved for SAP-managed products. That split is why delivered content updates without the project touching it while a custom model breaks silently when a source upgrade changes the table beneath it.

Is Foundation Services the same as BDC Connect?

No. Foundation Services faces inward at the SAP applications and manages SAP-managed data products. BDC Connect faces outward, federating or ingesting external platforms — Snowflake, Iceberg lakes, partner Delta shares, externally hosted Databricks workspaces — and exposing them as first-class catalogue objects.

What this page is built on

Read next