Architecture
SAP HANA is an in-memory, column-oriented database that keeps data in RAM and processes transactions and analytics on the same data. Its architecture is what makes S/4HANA’s real-time capabilities and simplified data model possible.
By collapsing the old transactional/analytical split, HANA let SAP remove redundant aggregate and index tables, simplify the data model (e.
- HANA stores data primarily in memory (persisted to disk for durability) and, for most application data, in a column store.
- Column store: default for application/analytical data; fast scans, aggregation, compression.
- Row store: for a few technical/frequently-single-row-accessed tables.
- Watch out: Assuming HANA is just a faster disk DB, it is architecturally different.
The in-memory, columnar core
HANA stores data primarily in memory (persisted to disk for durability) and, for most application data, in a column store. In-memory access removes disk-I/O latency, and columnar storage makes scans and aggregations extremely fast and highly compressible, so analytics can run directly on live transactional data.
Row vs column store
- Column store: default for application/analytical data; fast scans, aggregation, compression.
- Row store: for a few technical/frequently-single-row-accessed tables.
Key architectural pieces
- Index server: the main engine (SQL, calculation, stores).
- Persistence layer: data volumes + log volumes for durability and recovery.
- Multitenant database containers (MDC): a system DB plus isolated tenant DBs.
Why it changed SAP
By collapsing the old transactional/analytical split, HANA let SAP remove redundant aggregate and index tables, simplify the data model (e.g. the universal journal), and deliver real-time analytics, the foundation of S/4HANA.
Common pitfalls
- Assuming HANA is just a faster disk DB, it is architecturally different.
- Ignoring memory sizing, data must fit in RAM.
- Overlooking persistence, in-memory still needs durable storage.