Concept card

SAP BW/4HANA aDSO Types (Standard, Write-Optimised, Direct-Update)

As of 2026-07-23

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

What is SAP BW/4HANA aDSO Types (Standard, Write-Optimised, Direct-Update)?

Choosing the wrong aDSO type is the most common BW/4HANA modelling mistake — a 500M-row Standard aDSO with daily activation is slow and costly where Write-Optimised staging feeding a Standard layer would be fast and cheap.

What it is

The Advanced DataStore Object (aDSO) is the single physical InfoProvider in SAP BW/4HANA — the modern replacement for the BW 7.x DSO, InfoCube, and PSA proliferation. Every aDSO is one HANA-side table; what makes it behave like a DSO, a cube, or a staging area is the type setting chosen at creation. Three operating types matter in practice, and choosing the wrong one is the most common BW/4HANA modelling mistake a junior consultant makes.

The three types. Standard aDSO is the default workhorse: it carries an inbound queue (new and changed records), an active table (the current correct state, deduplicated by key), and a change log (the delta history for downstream propagation). It supports activation, before/after-image deltas, and rollback. This is what 80% of business-layer modelling needs. Write-optimised aDSO has only the inbound queue — no activation, no change log, no key uniqueness check; records are appended as they arrive. It is the staging-area pattern: load fast, transform downstream. Direct-update aDSO has only an active table writable via the planning API; it is the planning-application persistence layer, written by SAC Planning or IBP, not by ETL.

Why it matters

Standard aDSO (activation, deltas, rollback) covers 80% of business-layer modelling needs; Write-Optimised is purely a staging pattern with no activation or key checks.
Direct-Update aDSO exists only for planning persistence written by SAC Planning or IBP — modelling that as Standard breaks the write-back loop entirely.
The performance complaint that 'no amount of HANA tuning will fix' almost always traces back to using Standard where Write-Optimised belonged.

Key points

Standard aDSO — inbound queue + active table + change log; activation, before/after deltas, rollback; business-layer default (80% of use cases).
Write-Optimised aDSO — inbound queue only; no activation, no change log, no key uniqueness; staging area / PSA replacement.
Direct-Update aDSO — active table only, writable via planning API; SAC Planning / IBP persistence; not for ETL.
Wrong-type cost — Standard for staging = slow + expensive activation; Standard for planning = breaks write-back; pick at design, painful to refactor later.
One physical HANA table per aDSO — type is metadata configuration, not separate object kinds; field structure and partition strategy still chosen per object.
SAP BW/4HANA aDSO Types (Standard, Write-Optimised, Direct-Update) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

Terms used on this page

aDSO: Advanced DataStore Object — the unified InfoProvider class in BW/4HANA replacing BW 7.x DSO/InfoCube/PSA; one HANA table per object, with behaviour configured via type.
Inbound queue: The staging buffer of new and changed records before activation; persists raw load output; the only physical layer present in a Write-Optimised aDSO.
Activation: The Standard-aDSO operation that consolidates inbound-queue records into the active table by key, computes deltas, and writes the change log; the expensive step in BW/4HANA loading.
Change log: The before/after-image history table inside a Standard aDSO; the source for downstream delta propagation; what makes BW's delta chain work.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks.

Open in the app →

Guides that answer with this page

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