Performance Cost of Nested CDS View Stacks

A nested CDS view stack is a chain where a consumption or projection view selects from a composite view, which itself selects from one or more basic views built on database tables. Each layer can add associations, calculated fields, unions, or filters. At activation and runtime the ABAP CDS compiler attempts to collapse the entire stack into a single SQL statement handed to the database, so that filtering and joins happen as close to the table as possible. The one structural fact that explains most confusion here: this collapsing only happens when every layer in the stack is pushdown-compatible. The moment one layer contains something the optimizer cannot push through, that layer becomes a materialization boundary. Everything below it runs first and in full; everything above it then operates on the already-materialized result set, with none of its filters reaching the underlying table. A stack that looks identical in the editor can behave completely differently in the generated SQL depending on what one layer, three levels down, happens to contain.

Layering is the right tool when it enforces genuine reuse: a basic view is the single source of truth for a table, a composite view adds business logic used by several consumers, and a projection view exposes only what one service needs. This is standard RAP architecture and is meant to be nested two or three levels deep. It is the wrong tool when layers exist purely for folder tidiness with no actual reuse behind them, when an analytical aggregation view is stacked directly on top of a highly associative transactional view for convenience, or when a table function or AMDP is buried in the middle of a stack just because it was easier to write logic procedurally than in CDS expressions. In those cases the extra layer buys nothing architecturally and costs a materialization boundary at runtime.

Below the stack sit CDS view entities built directly on database tables, sometimes table functions backed by AMDP. Above the stack sit projection views exposed through a service definition and service binding, consumed by OData and Fiori Elements, or embedded in a RAP business object as the underlying entity. The nested stack occupies the space between raw table access and the exposed service, replacing what used to be hand-written joins in ABAP reports or views built directly on the database with a declarative, reusable layer. It does not replace the database optimizer; it feeds it. What it supersedes is the older pattern of one flat, monolithic view doing everything, in favour of basic, composite, and consumption views each with a defined responsibility, at the cost of needing to actively manage what happens to the generated SQL at each boundary.

A basic view selects sales order item data directly from the line item table. A composite view consumes it, adds an association to the business partner master and a calculated net value field, and applies a currency conversion annotation to convert that value to a reporting currency. A projection view on top exposes a filtered subset for a Fiori list report, with a where clause on delivery status and an access control applied through DCL. Tracing the generated SQL for this stack shows the currency conversion forcing the composite layer to materialize before the projection layer's status filter can be evaluated, because the conversion function operates row by row and cannot be pushed below itself. The fix is to filter on delivery status inside the basic or composite view, before the conversion happens, rather than relying on the projection layer's where clause to do it after the fact. The same list report, same fields, same annotations, runs an order of magnitude slower with the filter left in the wrong layer, and nothing in the CDS editor warns about it.

Layering basic, composite, and consumption CDS views is the recommended, clean-core-compatible way to extend S/4HANA: custom logic lives in custom views that consume standard SAP-delivered views without modifying them. That guidance does not relax the performance discipline; a clean-core-compliant stack can still be a slow one if filters sit in the wrong layer. What is discouraged now is stacking views many layers deep purely as a design habit, or wrapping AMDP logic inside layers that are then reused by several unrelated consumers, each inheriting the same materialization cost. An upgrade can also change how much of a given stack the compiler manages to flatten, since SAP's own delivered views change between releases; a stack that ran flat before an upgrade can pick up a new optimization boundary from a changed SAP base view and needs retesting, not just functional regression testing.

The developer builds the stack and is responsible for checking the generated SQL, not just functional correctness. The architect owns the layering decision: how many levels, what goes in DCL versus behavior logic, where AMDP is permitted. Handover for any CDS entity feeding a high-traffic list report should include an explain plan or SQL trace captured at realistic volume, not just a passing unit test.

Read cds-associations-versus-joins to understand what the join actually costs before adding another association to a stack. Read cds-table-functions-and-amdp for the specific mechanics of why AMDP blocks pushdown. Read cds-annotations-and-where-they-take-effect for how currency and unit conversion annotations interact with filtering. Read cds-access-controls-and-dcl to see how layered authorization checks compound cost across a stack, and analytical-cds-views for the specific risks of nesting aggregation on top of transactional associations.