Loading learning content...
In 2010, SAP introduced a database that would fundamentally reshape enterprise computing. SAP HANA (High-performance ANalytic Appliance) wasn't just another database—it was a declaration that the era of disk-based enterprise systems was ending.
HANA represented decades of database research culminating in a production system capable of running critical enterprise workloads entirely in memory. Its design influenced an entire generation of database systems and demonstrated that in-memory computing could scale to enterprise requirements.
This page examines HANA in depth: its architectural innovations, hybrid row-column engine, and the design decisions that made it the foundation for SAP's entire enterprise software portfolio.
By the end of this page, you will understand: HANA's architectural philosophy and key innovations, how the hybrid row-column engine works, the role of HANA in SAP's enterprise ecosystem, advanced features like multi-tiered storage and native HANA development, and when HANA is the right choice for your workload.
The Problem SAP Faced
By the mid-2000s, SAP's enterprise customers were hitting performance walls. SAP ERP systems—running on traditional databases like Oracle, DB2, or SQL Server—struggled with:
SAP's vision was radical: eliminate the architectural separation between transactional and analytical processing by making everything fast enough to run in real-time.
The Research Foundation
HANA drew on decades of academic research:
| Year | Version/Event | Key Development |
|---|---|---|
| 2010 | Initial Release | In-memory, column-oriented database for analytics |
| 2012 | HANA 1.0 SP5 | Added row store for OLTP, enabling hybrid workloads |
| 2013 | Suite on HANA | SAP Business Suite certified to run on HANA |
| 2015 | S/4HANA Launch | Complete SAP ERP rebuilt native on HANA |
| 2016 | HANA 2.0 | Multi-tenant, advanced analytics, warm data tiering |
| 2018 | HANA Cockpit | Enhanced administration and monitoring |
| 2020 | HANA Cloud | Cloud-native managed HANA service |
| 2023 | HANA Cloud QRC | Quarterly release cycle, enhanced vector/AI features |
SAP made a multi-billion dollar strategic bet on in-memory technology. Rather than continuing to support multiple traditional databases, SAP rebuilt its entire product line on HANA. S/4HANA, SAP's current ERP platform, runs ONLY on HANA—a platform-level commitment unprecedented in enterprise software.
HANA's architecture is designed from the ground up for in-memory operation while supporting durability, high availability, and enterprise-grade reliability.
Core Architectural Components
SAP HANA Architecture Overview ┌─────────────────────────────────────────────────────────────────────────┐│ INDEX SERVER ││ ┌─────────────────────────────────────────────────────────────────┐ ││ │ SQL/MDX Processor │ ││ │ • Query parsing, optimization, execution planning │ ││ │ • Join engine, aggregation engine │ ││ └─────────────────────────────────────────────────────────────────┘ ││ │ ││ ┌─────────────────────────┼─────────────────────────┐ ││ ▼ ▼ ▼ ││ ┌──────────────┐ ┌─────────────────────────┐ ┌─────────────────┐ ││ │ ROW STORE │ │ COLUMN STORE │ │ TEXT SEARCH │ ││ │ │ │ │ │ (TREX indexer)│ ││ │ • OLTP │ │ • Analytics (OLAP) │ │ • Full-text │ ││ │ • Transact. │ │ • Aggregations │ │ • Fuzzy search │ ││ │ • Row format │ │ • Compression │ │ • Text mining │ ││ └──────────────┘ └─────────────────────────┘ └─────────────────┘ ││ │ ││ ┌─────────────────────────────────────────────────────────────────┐ ││ │ PERSISTENCE LAYER │ ││ │ • Savepoints, Logging, Recovery │ ││ │ • Log volumes, Data volumes │ ││ └─────────────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼┌──────────────┐ ┌──────────────────────┐ ┌─────────────┐│ NAME SERVER │ │ XS ENGINE │ │ PREPROCESSOR││ (Distributed │ │ (Web application │ │ SERVER ││ catalog) │ │ server) │ │ (ETL, CALC) │└──────────────┘ └──────────────────────┘ └─────────────┘Key Components Explained
1. Index Server
The core database engine containing:
2. Row Store
Optimized for transactional workloads:
3. Column Store
The heart of HANA's analytical power:
4. Extended Application Services (XS)
Built-in web application server enabling "Native HANA development"—applications running directly on the database without middleware layers.
HANA's defining innovation is its hybrid engine that seamlessly combines row and column storage, enabling both OLTP and OLAP on the same data without ETL or replication.
Why Hybrid Matters
Traditional architectures force a choice:
Enterprises needed both. The conventional solution—replicate data to separate OLTP and OLAP systems—meant:
HANA's hybrid approach eliminates this dichotomy.
HANA Column Store Delta-Merge Architecture WRITE PATH:┌─────────────────────────────────────────────────────────────────┐│ INSERT/UPDATE arrives ││ │ ││ ▼ ││ ┌───────────────────────────────────────────┐ ││ │ L1 DELTA (Row-Oriented) │ ││ │ • Unsorted, uncompressed │ ││ │ • Optimized for single-row inserts │ ││ │ • Small buffer (MBs) │ ││ └───────────────────────────────────────────┘ ││ │ (background merge when threshold) ││ ▼ ││ ┌───────────────────────────────────────────┐ ││ │ L2 DELTA (Column-Oriented) │ ││ │ • Sorted dictionary, basic compression │ ││ │ • Larger buffer (10s-100s MB) │ ││ └───────────────────────────────────────────┘ ││ │ (MERGE operation when threshold) ││ ▼ ││ ┌───────────────────────────────────────────┐ ││ │ MAIN STORE │ ││ │ • Fully compressed, optimized for reads │ ││ │ • Read-optimized columnar layout │ ││ │ • Global dictionary, heavy compression │ ││ └───────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘ READ PATH:Query reads from BOTH Main Store AND Delta StoresResults are merged transparentlyLatest version always visibleThe Delta Merge Process
L1 Delta (Row Delta): Incoming writes go to a small, row-oriented buffer optimized for single-row operations. This provides fast insert performance without touching the compressed main store.
L2 Delta (Sorted Dictionary): When L1 fills, data is converted to columnar format with basic compression and sorted by dictionary values. This provides good query performance while still accepting updates.
Main Store Merge: Background processes periodically merge L2 delta into the main store, applying full compression optimizations. This is the "delta merge" operation that database administrators monitor and tune.
Why This Design Works
Delta merge operations can cause temporary performance variations. For high-throughput systems, HANA administrators configure merge thresholds, scheduling, and parallelism. Auto-merge handles most cases, but understanding the mechanism helps diagnose performance patterns.
Compression in HANA isn't just about saving space—it's a performance feature. Smaller data means more fits in cache, more fits in memory, and faster scans.
Compression Techniques
HANA automatically selects the optimal compression for each column based on data characteristics:
| Technique | How It Works | Best For | Typical Ratio |
|---|---|---|---|
| Dictionary Encoding | Replace values with integer codes referencing dictionary | String columns with repeated values | 5:1 to 20:1 |
| Run-Length Encoding (RLE) | Store (value, count) for consecutive identical values | Sorted columns, low cardinality | 10:1 to 100:1 |
| Cluster Encoding | Group similar values into clusters with shared prefix | Similar strings, hierarchical codes | 4:1 to 15:1 |
| Sparse Encoding | Store only non-default values with positions | Columns with many NULLs or defaults | 10:1 to 50:1 |
| Bit-Packed/Prefix Encoding | Use minimum bits for value range | Integer columns with limited range | 2:1 to 8:1 |
| Indirect Encoding | Secondary dictionary for large dictionaries | High-cardinality strings | 3:1 to 10:1 |
Dictionary Encoding in Detail
Dictionary encoding is HANA's cornerstone compression technique. Consider a column storing country names:
HANA Dictionary Encoding Example Original Column: CUSTOMER_COUNTRY (10 million rows)['United States', 'Germany', 'United States', 'France', 'Germany', 'United States', 'United Kingdom', 'Germany', ...] Dictionary (Sorted):0 → 'France' (1.2 million occurrences)1 → 'Germany' (2.5 million occurrences) 2 → 'United Kingdom' (1.8 million occurrences)3 → 'United States' (4.5 million occurrences) Encoded Column (attribute vector):[3, 1, 3, 0, 1, 3, 2, 1, ...] (2 bits per value = 0.25 bytes) Storage Analysis:━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Original: 10M rows × ~12 bytes avg = 120 MB Dictionary: 4 entries × ~15 bytes = 60 bytes Attribute Vector: 10M × 2 bits = 2.5 MB Compressed Total: ~2.5 MB Compression Ratio: ~48:1━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Query Execution Benefit:• Equality filter: Compare encoded integers (2 bits), not strings• GROUP BY: Already grouped by dictionary value• Aggregation: SIMD processes 128 values per operationCompression and Query Execution
HANA executes queries directly on compressed data wherever possible:
This "operate on compressed data" capability multiplies the benefit: smaller data AND faster processing.
Real SAP customer deployments typically see overall compression ratios of 3:1 to 10:1 compared to disk-based databases. Transaction data with many string columns might achieve 5:1, while highly structured data with repeated patterns can exceed 20:1. This compression enables datasets of 10-30 TB raw size to fit in 1-3 TB of RAM.
HANA's query engine leverages in-memory architecture to achieve performance that would be impossible with disk-based designs.
Query Execution Model
HANA uses a combination of execution strategies:
Join Processing
HANA implements multiple join algorithms optimized for in-memory execution:
Hash Join: Standard for equi-joins. Build hash table on smaller table, probe with larger table. Fully in-memory, no spilling concerns.
Merge Join: Effective when both sides are already sorted (common for column stores with sorted dictionaries).
Partition-Wise Join: When both tables are partitioned on join keys, each partition pair can be joined independently in parallel.
Bloom Filter Optimization: Before expensive join operations, Bloom filters prune non-matching rows, dramatically reducing join input size.
HANA Parallel Query Execution Query: SELECT region, SUM(amount) FROM sales WHERE year = 2023 GROUP BY region; ┌─────────────────────────────────────────────────────────────────┐│ SALES Table (100 million rows, 16 partitions) ││ ││ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ... ┌─────┐ ││ │ P1 │ │ P2 │ │ P3 │ │ P4 │ │ P16 │ ││ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ││ │ │ │ │ │ ││ ▼ ▼ ▼ ▼ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ PARALLEL SCAN + FILTER (16 threads) │ ││ │ WHERE year = 2023 (filter on encoded value) │ ││ └──────────────────────────────────────────────────────────┘ ││ │ │ │ │ │ ││ ▼ ▼ ▼ ▼ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ PARALLEL LOCAL AGGREGATION │ ││ │ SUM(amount) GROUP BY region (per partition) │ ││ └──────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ GLOBAL MERGE AGGREGATION │ ││ │ Combine partial results from partitions │ ││ └──────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ FINAL RESULT ││ (5 regions, aggregated) │└─────────────────────────────────────────────────────────────────┘ Execution Time: ~200ms (vs. minutes in disk-based systems)HANA's EXPLAIN PLAN output shows parallel execution patterns, partition pruning decisions, and join strategies. Learning to read HANA execution plans is essential for query optimization. Key indicators: parallelism degree, table access methods (column vs. row store), and join types.
Despite being an "in-memory" database, HANA provides full ACID durability through sophisticated persistence mechanisms.
Write-Ahead Logging (Redo Log)
Every transactional change is written to the redo log before being acknowledged. The log is on persistent storage (SSD or high-performance disk), ensuring durability even if the server loses power.
Savepoints
Periodically, HANA writes consistent snapshots of the entire database to persistent storage. These savepoints:
HANA Persistence Architecture MEMORY (In-Memory Database State)┌─────────────────────────────────────────────────────────────────┐│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Row Store │ │Column Store │ │ Catalog │ ◄── Live ││ │ Tables │ │ (Main+Δ) │ │ Metadata │ State ││ └─────────────┘ └─────────────┘ └─────────────┘ │└─────────────────────────────────────────────────────────────────┘ │ │ │ │ Transaction │ │ │ completes │ │ ▼ ▼ ▼┌─────────────────────────────────────────────────────────────────┐│ REDO LOG (on SSD/Disk) ││ ┌───────┬───────┬───────┬───────┬───────┬───────┬─────────┐ ││ │ LSN 1 │ LSN 2 │ LSN 3 │ LSN 4 │ LSN 5 │ LSN 6 │ ... │ ││ └───────┴───────┴───────┴───────┴───────┴───────┴─────────┘ ││ Every transaction writes here BEFORE acknowledgment ││ (synchronous write for durability) │└─────────────────────────────────────────────────────────────────┘ │ │ Periodic (every few minutes) ▼┌─────────────────────────────────────────────────────────────────┐│ SAVEPOINT ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Complete consistent snapshot of in-memory state │ ││ │ Written to DATA VOLUME (persistent storage) │ ││ │ Enables log truncation (old LSNs no longer needed) │ ││ └─────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘ RECOVERY PROCESS:1. Load most recent savepoint (fast—direct load)2. Replay redo log from savepoint LSN to current3. Database fully recovered, ready for connectionsRecovery Time Optimization
Recovery time is critical for availability. HANA optimizes recovery through:
High Availability
For mission-critical deployments, HANA supports:
Recovery time depends on database size and log volume since last savepoint. Large databases (multi-TB) may take 10-30 minutes to recover. For applications requiring sub-minute RTO, synchronous system replication with automatic failover is essential.
HANA's significance extends beyond its technical capabilities—it serves as the foundation for SAP's entire enterprise software portfolio.
S/4HANA: The Simplified ERP
S/4HANA is SAP's current-generation ERP, designed exclusively for HANA. The database's capabilities enabled dramatic simplifications:
| Component | Purpose | Key Capabilities |
|---|---|---|
| S/4HANA | Core ERP | Finance, supply chain, manufacturing, sales |
| BW/4HANA | Data warehousing | Enterprise analytics, OLAP cubes on HANA |
| SAP Analytics Cloud | Cloud BI | Dashboards, planning, predictive analytics |
| SAP Data Intelligence | Data integration | ETL, data pipelines, metadata management |
| SAP HANA Cloud | Database-as-a-Service | Managed HANA in hyperscaler clouds |
| SAP Business Technology Platform | PaaS | Custom app development on HANA stack |
Native HANA Development
HANA isn't just a database—it's an application platform. The XS (Extended Application Services) engine enables:
This "code-to-data" approach minimizes data movement by pushing computation to where data resides.
Modern HANA supports multiple data models: relational, document (JSON), graph, and spatial. This multi-model capability reduces the need for specialized databases. A single HANA instance can store transactional data relationally, documents as JSON, and relationship networks as graphs—all queryable via SQL.
HANA represents a significant investment. Understanding when it's the right choice—and when alternatives may be better—is essential for architects.
Cost Considerations
HANA's costs include:
However, total cost of ownership (TCO) should account for:
You now have a comprehensive understanding of SAP HANA: its genesis, architecture, hybrid engine design, compression technologies, query processing, persistence mechanisms, and role in the enterprise ecosystem. Next, we'll examine Redis—a fundamentally different in-memory database optimized for simplicity and extreme performance in specific use cases.