Konzeptkarte

BDC Capacity Units

Stand 27. September 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist BDC Capacity Units?

Die Einstiegsschwelle von 128 CU deckt selten eine reale Tier-1-Last: Sechs Workload-Typen teilen sich einen einzigen Pool von Capacity Units, dimensionieren Sie einen BDC-Tenant daher nach seiner Spitze, nicht nach seinem Durchschnitt.

Capacity Units sind die Abrechnungs- und Bemessungswährung von SAP Business Data Cloud — ein gebündeltes Maß aus Compute, Speicher, Storage-Zuteilung und Data-Flow-Ein-/Ausgabeoperationen pro Sekunde, verkauft in tenant-großen Blöcken statt pro Ressource bepreist. Eine Capacity Unit kauft in etwa das Äquivalent einer vCPU HANA-Cloud-Compute, rund vier Gigabyte HANA-Cloud-Speicher, eine bescheidene Storage-Zuteilung, bevor Überlauf-Preise greifen, und einen Anteil an Data-Flow-Durchsatz. Der kleinste Business-Data-Cloud-Tenant beginnt bei 128 Capacity Units, spürbar größer als die 64-Einheiten-Untergrenze eines eigenständigen Datasphere-Tenants, was den breiteren Workload-Mix widerspiegelt — Replikation, Live-Analytics, Planung, Joule, Knowledge Graph —, den ein Business-Data-Cloud-Tenant gleichzeitig tragen soll. Für einen Consultant, der ein Engagement bemisst, ist die Beherrschung von Capacity Units die Grenze zwischen einem Angebot mit vorhersehbarer monatlicher Rechnung und dem Ergebnis, das jeder Finance-Stakeholder fürchtet: eine außer Kontrolle geratene Rechnung, die erst nach dem Go-live entdeckt wird.

Warum es wichtig ist

Weil es sich um eine gebündelte Einheit handelt, wirkt sich eine Capacity Unit je nach Workload unterschiedlich aus. Ein speicherhungriges Planungsmodell mit geringem Durchsatz verbraucht Einheiten anders als ein replikationslastiger Integrations-Workload mit bescheidenem Speicherbedarf, und ein Tenant, der allein nach durchschnittlicher Auslastung bemessen wird, unterdimensioniert routinemäßig für den Workload-Mix, den er tatsächlich fährt. Das Bemessungsgespräch früh richtig zu führen verhindert, dass ein Kunde drei Monate nach Produktivstart entdeckt, dass Monatsabschluss-Abfragen am Freitagnachmittag hinter kapazitätserschöpften Hintergrund-Flows warten. Es zählt auch kommerziell: Capacity-Unit-Blöcke sind der Posten im Vertrag, den das Einkaufsteam eines Kunden am schärfsten prüft, und ein Consultant, der nicht erklären kann, warum eine bestimmte Blockgröße gewählt wurde, verliert Glaubwürdigkeit genau in dem Gespräch, in dem sie am dringendsten gebraucht wird.

Warum es zählt

Nach Bemessungsschätzungen von Analytics Legends (2026, keine SAP-Zahl) bemisst sich ein Tier-1-Muster auf 130–240 CU im Dauerbetrieb und 280–360 CU an der Spitze — mehr als das Doppelte der 128-CU-Untergrenze des Tenants, sodass die Untergrenze als ausreichend anzubieten eine Kapazitätskrise mitten im Projekt vorbereitet.
Speicher (~4 GB pro CU) ist der dominante Kostentreiber für In-Memory-Analytics, nicht Compute — ein Bemessungsgespräch, das sich an der vCPU-Zahl festmacht, bepreist die falsche Variable.
Sechs verschiedene Workload-Typen (SAC-Live-Abfragen, Replication Flows, Analytic-Model-Auswertung, Joule-Grounding, Knowledge-Graph-Traversierung, Databricks-Cluster-Hochfahren) konkurrieren um einen gemeinsamen CU-Pool, sodass eine Spitze in einem davon die übrigen aushungert.

Kernpunkte

1 CU = 1 vCPU + 4 GB HANA + Storage + IOPS.
BDC-Tenant-Minimum: 128 CU (Einstieg 100–180 Tsd. €/Jahr GJ26).
Tier-1-Bemessung (Schätzung Analytics Legends, 2026): 130–240 im Dauerbetrieb, 280–360 an der Spitze; Bereitstellung auf Spitze + 20 % Puffer.
Sechs Workload-Typen: Replikation · AM-Abfragen · SAC Live · Joule · Knowledge Graph · Databricks-Seite.
Die Joule-Grounding-Last wächst mit der Zahl aktiver Nutzer — bemessen Sie sie nach gemessener Nutzung im Tenant, nicht nach einer veröffentlichten Faustregel.
Durchschnitts-Bemessung = Antipattern (Spitze verdoppelt den Durchschnitt).
Chargeback: gleitender 30-Tage-Verbrauch pro Space aus dem Tenant Monitor.
Elastic-CU-Bursting in Preview Q2 2026, GA-Ziel H2 2026.

Begriffe auf dieser Seite

Capacity Unit (CU): Die Abrechnungsgrundeinheit von BDC: ~1 vCPU + 4 GB HANA Cloud + Storage + IOPS kombiniert.
Tenant CU pool: Gesamte vertraglich vereinbarte CU, geteilt über alle Workloads eines einzelnen BDC-Tenants.
Sizing at peak: Defensive Bereitstellung auf gemessene Spitzenlast + 20 % Puffer. Standard; durchschnittsbasierte Bemessung ist ein Antipattern.
Joule grounding load: Rechenleistung, die Joule-Agenten für das Grounding ihrer Antworten in Tenant-Daten verbrauchen; sie vervielfacht sich mit der Zahl aktiver Nutzer. SAP veröffentlicht keine feste Zahl zum Leerlaufverbrauch.
Per-Space chargeback: Zuordnungsmuster, das den gleitenden 30-Tage-Verbrauch auf Space-Ebene aus dem Tenant Monitor nutzt, um Kosten auf Geschäftsbereiche zu verteilen.
Tenant Monitor: Eingebautes BDC-Dashboard, das CU-Verbrauch, Abfrage-Workload und Replikations-Gesundheit pro Space anzeigt.
Elastic CU bursting: Preview Q2 2026 / GA-Ziel H2 2026 — vorübergehendes Überschreiten der vertraglichen CU zu einer Burst-Rate von 1,3–1,5×, vierteljährlich abgerechnet.
Surge billing: Zusatzgebühr, die anfällt, wenn der Tenant die Storage- oder IOPS-Zuteilung überschreitet. Replikations-Parallelität ist die häufigste Ursache.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.