BDC Sizing & Capacity
As of 2026-08-16
Sizing BDC = enough capacity for the workload without paying for unused headroom; in a consumption model (M032) wrong-sizing is expensive both ways (under = slow/SLA-miss/distrust, over = permanent bill fat). Workload-driven, not seat-driven: three classes scale on different axes — scheduled pipelines (batchable), interactive queries/stories (concurrency/latency), Databricks eng/ML (spiky, M034); one number for all three is the classic error. T-shirt estimate first, then right-size on real telemetry (M045) after 4-6 weeks — don't treat the initial guess as final. Design for elasticity (scale up for month-end close, down after) not standing peak capacity. Storage sizing follows the history tiering (M071) — size hot+warm working set, not the 12-year archive. Honest: sizing is an estimate refined by reality + a right-sizing checkpoint, not false-precision. Controls bill + UX simultaneously.
What you will learn
- Separate BDC's three workload classes — scheduled pipelines, interactive queries, Databricks ML — and size each on its own axis instead of one blended number
- Build a conservative T-shirt sizing plan with a defined right-sizing checkpoint on real telemetry (M045)
- Design capacity for elasticity around peak windows (month/quarter-end close) instead of paying for standing peak capacity year-round
- Frame storage sizing around the hot+warm working set (M071) and defend a sizing recommendation to a platform owner without false precision
Module overview
Sizing a BDC environment is the discipline of provisioning enough capacity to meet the workload without paying for headroom nobody uses — and in a consumption-priced platform (companion module M032), getting it wrong is expensive in both directions. Under-size and queries crawl, pipelines miss SLAs, and users lose trust; over-size and the bill carries permanent fat. The senior approach is evidence-based right-sizing that starts conservative and refines on real telemetry, not a one-shot guess.
Workload-driven, not seat-driven. The old SAC/BW sizing question was "how many users?" The BDC question is "what workloads, at what concurrency, at what data volume?" Three workload classes drive capacity: scheduled pipelines (predictable, batchable), interactive queries/stories (concurrency-sensitive, latency-bound), and Databricks engineering/ML (spiky, compute-heavy — companion module M034). Each scales on a different axis; sizing one number for all three is the classic error.
Prerequisites
- Intermediate hands-on experience on SAP analytics projects
- Review core concepts first: C012, C015, C010
Outcomes
- Separate BDC's three workload classes and size each on its own scaling axis
- Build a conservative T-shirt sizing plan with an explicit right-sizing checkpoint
- Explain the core architecture and decision points for BDC Sizing & Capacity
- Apply a repeatable implementation pattern in a 15-minute lab format
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.