ABAP Internal Tables: Standard vs Sorted vs Hashed

An internal table is ABAP's in-memory collection type, but its table category determines how rows are organized and how key access behaves. A standard table has a primary index and a non-unique primary key; a sorted table also has an index but keeps rows ordered by its primary key; a hashed table has no primary table index and requires a unique hash key. This is not merely syntax style: the category affects insertion cost, uniqueness rules, index access, range processing, and lookup behavior. SAP's current ABAP documentation also allows secondary sorted or hashed keys on internal tables, so the design is no longer limited to one access path.

Choose the table category from the dominant access pattern, not from habit. Use a standard table when sequential processing or index access dominates and key lookups are limited or can be supported by a secondary key. Use a sorted table when you need ordered iteration, partial-key/range access, or frequent key searches while still retaining index behavior. Use a hashed table when almost every access is by the complete unique key and order is irrelevant. For very small tables, the simplest declaration is often sufficient; for large hot tables, the access pattern matters.

Internal tables sit between database retrieval and application logic. Open SQL should reduce the database result set first; internal tables then support grouping, enrichment, validation, mapping, and output preparation in ABAP memory. Table keys interact with READ TABLE, table expressions, LOOP ... USING KEY, FILTER, INSERT, MODIFY, DELETE, and constructor expressions. They also affect performance discussions about nested loops, binary search, and secondary keys. Internal-table design therefore belongs in the same review as database access rather than being treated as a purely local coding detail.

A pricing utility loads 200,000 condition rows and repeatedly looks up one row by a complete business key. Keeping them in a standard table and issuing READ TABLE WITH KEY without an optimized key forces repeated linear searches. Replacing the collection with a hashed table keyed by the exact lookup fields makes the intent explicit and gives efficient key access. A different report that must print the same rows in key order and frequently process key ranges may be better served by a sorted table. The correct category changes with the read pattern, even when the row structure is identical.

The standard/sorted/hashed distinction is current ABAP behavior in S/4HANA and ABAP Cloud as well as classic systems. HANA does not make poor in-memory ABAP access patterns free. Modern ABAP adds table expressions and secondary keys, but those features still depend on the declared table category and key. For cloud-ready code, the same language semantics apply; the main difference is which application APIs can supply the data.

ABAP developers own the table category and key design. Performance reviewers should challenge large frequently accessed tables when the declared category does not match the lookup pattern. Functional teams normally do not own this decision, although they define the uniqueness and grouping rules represented by the key.

SE38/ADT help reproduce small benchmarks, while SAT is the right tool when internal-table processing is materially expensive in a real program. The ABAP SQL performance topic explains why database filtering should happen before rows are loaded into memory, and secondary-key design deserves its own review for large tables.