Every ABAP developer hits the same wall: the logic you need is easy in SQL, awkward in ABAP. Recursive queries, complex window functions, set-based operations over millions of rows — you can do them in ABAP, but you end up pulling data to the app server and looping, which is the slowest possible place to do it. ABAP Managed Database Procedures (AMDP) let you write database procedures — in SQLScript — managed as ABAP repository objects.
The key word is managed. You're not creating stored procedures in the database by hand. You write an AMDP method in an ABAP class, and the ABAP system transports it, activates it, and manages its lifecycle like any other ABAP object.
When AMDP makes sense
Reach for AMDP when the database can do the job fundamentally better than the app server:
Set-based heavy lifting. Aggregations, ranking, running totals over large datasets. SQLScript's window functions and grouping do in one pass what ABAP loops do in a million iterations.
Things SQL does natively. Recursive CTEs for hierarchies, complex joins the CDS view editor can't express, graph or text-processing functions in HANA.
Performance-critical paths. When a CDS view gets you 90% of the way but the last 10% kills performance, an AMDP procedure can take over the hot part.
Don't reach for AMDP for plain CRUD or simple selects — CDS views and plain ABAP SQL cover those with better tooling, testability, and portability.
Key takeaway: AMDP = SQLScript procedures managed as ABAP objects. Use them for database-side heavy lifting (aggregations, hierarchies, window functions) — not for everyday selects, where CDS views are the better tool.
The anatomy of an AMDP method
An AMDP is a method of a global class, tagged with interface IF_AMDP_MARKER_HDB and implemented BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT. A minimal example computing running totals:
CLASS zcl_sales_analytics DEFINITION PUBLIC.
PUBLIC SECTION.
INTERFACES if_amdp_marker_hdb.
TYPES: BEGIN OF ty_result,
bukrs TYPE bukrs,
period TYPE char6,
amount TYPE dmbtr,
running TYPE dmbtr,
END OF ty_result,
tt_result TYPE STANDARD TABLE OF ty_result.
METHODS get_running_totals
IMPORTING VALUE(iv_bukrs) TYPE bukrs
EXPORTING VALUE(et_result) TYPE tt_result.
ENDCLASS.
CLASS zcl_sales_analytics IMPLEMENTATION.
METHOD get_running_totals BY DATABASE PROCEDURE
FOR HDB LANGUAGE SQLSCRIPT
OPTIONS READ-ONLY.
et_result = SELECT bukrs, period, amount,
SUM(amount) OVER (PARTITION BY bukrs
ORDER BY period) AS running
FROM zsales_data
WHERE bukrs = :iv_bukrs;
ENDMETHOD.
ENDCLASS.
Note the details: parameters use VALUE(), host variables are prefixed with :, and the result is assigned to the exporting table parameter. OPTIONS READ-ONLY declares the procedure won't modify data — include it whenever true, because the system can optimize accordingly.
Calling AMDP from ABAP
From the caller's side, an AMDP method looks like any other method:
DATA(lo_analytics) = NEW zcl_sales_analytics( ).
lo_analytics->get_running_totals(
EXPORTING iv_bukrs = '1000'
IMPORTING et_result = DATA(lt_result) ).
The caller doesn't know (or care) that the logic executed as SQLScript inside HANA. That encapsulation is the point: the database-specific code lives behind a clean ABAP interface, so the rest of your application stays portable and testable.
AMDP and CDS: better together
AMDPs shine brightest as the implementation behind CDS table functions — you define the CDS entity with its parameters and fields, and the AMDP method supplies the rows. The CDS layer gives you a typed, documented, reusable interface; the AMDP gives you full SQLScript power underneath. It's the standard pattern for logic that's too complex for a plain CDS view.
One practical rule: prefer a CDS view first, drop to AMDP-backed table functions only when the view can't express what you need. Views get better tooling (annotations, associations, extensibility); AMDPs get raw power. Choose per case, and document why the AMDP was necessary — future you will want to know.
Pitfalls to avoid
Portability. SQLScript is HANA-specific. If your code must run on other databases, AMDP is off the table — that's exactly what the FOR HDB clause declares.
Debugging. You can't step through SQLScript in the ABAP debugger the way you step through ABAP. Test the SQL logic independently (SQL console first, AMDP wrapper second), and keep procedures small enough to reason about.
Security. AMDPs run with the database user's authorizations. OPTIONS READ-ONLY is your friend; think twice before writing procedures that modify data, and never build dynamic SQL from untrusted input.
Used with discipline — database work in the database, behind a clean ABAP interface — AMDP turns "impossible in ABAP" logic into a method call.