Concept card

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

As of 2026-10-06

Edited by Cédric Mary, 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.

Adso types in BW4HANA?

Short answer above

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.

The choice matters operationally because activation cost, storage footprint, and delta-propagation behaviour all depend on type. A 500-million-row Standard aDSO with daily full activation is slow and expensive; the same data in a Write-Optimised staging aDSO with downstream Standard aDSO for the business layer is fast and cheap. Conversely, modelling a planning persistence as Standard breaks SAC's write-back loop.

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.
Activation cost is proportional to delta batch size, key width and change-log fan-out — not to total row count; that is why 'add more HANA' rarely fixes a wrongly-typed InfoProvider.
During a BW/4HANA conversion, InfoCubes have no one-to-one successor: a pure reporting InfoCube converts to Standard; one secretly doing staging duty should be split into Write-Optimised + Standard.
A correctly-typed Standard aDSO's active table is also the cheapest object to publish as a BDC data product or Knowledge-Graph grounding source — the type choice outlives the BW/4HANA system itself.

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.
Active table: The deduplicated, current-state table inside a Standard or Direct-Update aDSO, keyed by the object's business key — the record set queries actually read.
Delta batch: The set of new or changed records processed in a single activation run; its size, not the InfoProvider's total row count, drives activation cost.
Planning API: The write interface SAC Planning and IBP use to post directly into a Direct-Update aDSO's active table, bypassing the standard load-and-activate ETL path entirely.
Type mapping (BW/4HANA conversion): The per-object decision, made during a BW 7.x to BW/4HANA conversion, of which aDSO type a legacy DSO or InfoCube becomes; InfoCubes have no automatic one-to-one successor.

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 · the facts worth quoting.

Open in the app →

Guides that answer with this page

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