CDS vs Open SQL vs AMDP: Choosing the Right ABAP Data Logic

Open SQL is embedded in ABAP and ideal for a program/service that needs a query close to its application logic. CDS entities are repository data models consumed by multiple programs, RAP/OData, analytics and authorization frameworks; annotations and associations give them semantics beyond SQL text. AMDP methods are ABAP class methods whose implementation runs as SQLScript in HANA, enabling procedural/database-specific operations and serving as implementations for CDS table functions. Each moves more logic toward the database but increases coupling/reuse complexity differently.

Use Open SQL for straightforward program-specific reads/writes and set-based calculations. Use CDS when data shape is a reusable business model, needs associations/text/authorization/analytics annotations, or is a RAP/service projection. Use AMDP when a proven calculation cannot be expressed adequately in Open SQL/CDS and benefits materially from HANA SQLScript—complex procedural set processing, specialized HANA functions or table-function logic. Do not use AMDP just to make code look 'HANA optimized'.

Open SQL can select from tables and CDS entities. CDS can layer on other CDS sources and expose services/analytics. CDS table functions delegate implementation to AMDP. HANA optimizer sees generated SQL from all these layers, but AMDP/table functions can create optimization boundaries and are HANA-specific. ABAP Unit/testing and authorization patterns differ: CDS DCL works with CDS access; AMDP logic may require explicit attention to semantics.

A report needs one aggregation with two joins: modern Open SQL is sufficient. Several apps need a consistent 'Sales Order Analytical Cube' with texts, units, measures and access control: CDS is the better reusable model. A specialized allocation algorithm requires procedural SQL over large datasets and cannot be expressed cleanly in CDS; after trace/prototype evidence, an AMDP/table function is justified. The team avoids moving ordinary SELECT logic into SQLScript.

CDS and modern Open SQL are primary S/4HANA/ABAP Cloud data access tools. AMDP remains available for HANA-specific pushdown in permitted environments, but ABAP Cloud/released API restrictions apply to consumed data objects. New clean-core development should prefer released CDS entities/APIs and use AMDP only within supported extension boundaries.

ABAP developers own Open SQL; data/RAP architects own reusable CDS models; HANA specialists may support AMDP/plan analysis. Functional owners define grain, joins and measures. Architecture review should justify HANA-specific coupling.

Code pushdown, CDS table functions/AMDP, nested CDS performance and modern Open SQL topics provide detailed follow-up. ST05/PlanViz prove runtime behavior.

Production review: For a proposed implementation record consumer count, semantic reuse need, query complexity, authorization/annotation needs, expected data volume and measured runtime. Prototype the simplest Open SQL/CDS solution before escalating to AMDP. Preserve a representative SQL/PlanViz baseline so future changes can prove the extra layer still adds value rather than becoming permanent technical complexity.

Additional validation: Service validation for CDS vs Open SQL vs AMDP: Choosing the Right ABAP Data Logic: capture the service or behavior artifact, protocol, binding, consumer, actual backend user, request URL or entity/action, authorization result and backend message. Test direct service calls as well as the Fiori consumer so UI behavior cannot mask a backend security or contract problem. Include one realistic multi-row or concurrent request in addition to single-record tests, and use current target-release RAP documentation when behavior-definition syntax or generated runtime behavior is involved.