In-memory and columnar

Every SAP S/4HANA system runs on SAP HANA. For a platform team, that is not just a product name on an architecture slide: it changes how the system is sized, how it behaves under load, how backups work and what "the database is slow" actually means. This course gives you the operating model. This first lesson covers the idea everything else rests on: SAP HANA keeps its working data in memory and stores most business tables by column.

Row storage versus column storage

A traditional database stores a table row by row: all the fields of one sales order item sit next to each other, then the next item, and so on. That is efficient when you read or write whole records one at a time. A column store keeps all the values of one column together instead: every plant, then every material, then every quantity. When a report asks "total quantity by plant for the year", the database reads only the two columns it needs and skips the rest.

Column storage compresses very well. SAP HANA keeps a sorted dictionary of the distinct values in a column and stores each row as a small integer that points into it. A column such as plant, with only a handful of values (1710 and 1720 at Contoso), shrinks dramatically. Compression is what makes it affordable to hold large databases in memory, and it is also why the compression rate, and therefore the memory needed, depends heavily on the data itself.

Main storage, delta storage and the delta merge

Highly compressed, sorted data is fast to read but expensive to change. SAP HANA solves this by splitting each column table into a read-optimized main storage and a write-optimized delta storage. New and changed records go into the delta; reads combine both. Periodically a delta merge folds the delta into a new main storage and recompresses it. By default SAP HANA decides when to merge on its own, through a background process called mergedog that looks at delta size, available memory and time since the last merge.

Platform teams notice merges in two ways. Merges cost CPU and, for a short time, extra memory, so very large loads (such as Contoso's Wave 2 data loads for company code 1910) can show merge activity spikes. And an alert that a table's delta has grown past a threshold is a sign that merges are not keeping up and deserves a look before it becomes a memory problem.

Why SAP S/4HANA could simplify its data model

Older SAP ERP systems on disk-based databases stored the same information several times: line items, plus totals tables, plus secondary index tables kept only to make reports fast. Because SAP HANA can aggregate line items on the fly, SAP S/4HANA removed many of those redundant structures. The best-known example is the universal journal (table ACDOCA), which holds financial and controlling line items together; inventory movements were similarly consolidated in a single material document table. Many old totals and index tables survive only as compatibility views so that existing reports still read them.