Konzeptkarte

BDC Capacity Units

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, 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?

Untätige Joule-Agenten verbrauchen 5–10 % des gesamten CU-Budgets eines Tenants allein durch das Abfragen der Verfügbarkeit – der am wenigsten offensichtliche Posten in einem BDC-Kapazitätsplan, und die Einstiegsschwelle von 128 CU deckt ohnehin selten eine reale Tier-1-Last.

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 das 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

Ein Tier-1-Muster bemisst sich 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: 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.
Joule-Leerlauf-Abfrage-Overhead: 5–10 % des Pools unabhängig von der Nutzung.
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.
BDC Capacity Units ist erst dann beherrscht, wenn es eine konkret benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Werkzeug demonstrieren.

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 polling overhead: Joule-Agenten im Leerlaufzustand, die 5–10 % des gesamten CU-Pools verbrauchen, unabhängig vom Konversationsaufkommen.
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 →