HANA's in-memory architecture is its superpower and its cost problem in one. Everything hot lives in RAM — blazing fast, eye-wateringly expensive per gigabyte. But most business data isn't hot: last year's invoices, archived line items, historical snapshots. You need it queryable, you don't need it in microseconds. Native Storage Extension (NSE) is HANA's answer: a built-in warm tier that keeps less-frequently-accessed data on disk while it stays fully visible to SQL.
Hot, warm, cold: the tiering idea
Data temperature is about access patterns, not age alone:
Hot — accessed constantly, latency-sensitive. Lives in memory, in HANA's column store. This is your current-year transactional data.
Warm — queried regularly but not constantly; seconds are fine, microseconds unnecessary. This is NSE's territory: stored on disk in a page-based format, loaded into memory on demand and cached.
Cold — rarely touched, kept for compliance. Lives in cheaper storage or archiving solutions outside HANA's active management.
The win: you stop paying RAM prices for data that's merely available rather than hot. Memory footprint shrinks, TCO drops, and the total data you can keep online grows.
Key takeaway: NSE is HANA's built-in warm tier — disk-based storage for infrequently accessed data that stays fully queryable through normal SQL, cutting memory costs without archiving anything away.
How NSE works
NSE stores data in pages on disk rather than in HANA's in-memory columnar structures. When a query touches NSE data, the needed pages are loaded into a buffer cache in memory; frequently re-accessed pages stay cached, so repeated queries stay fast. From the application's perspective, nothing changes — same tables, same SQL, same CDS views. The storage location is transparent.
You control placement at the table or partition level. The classic pattern: partition by time, keep recent partitions hot in memory, and mark older partitions as NSE warm. A sales table partitioned by year keeps 2025–2026 in RAM and pushes 2020–2024 to warm storage — one table, two temperatures, zero application changes.
Setting it up: the practical moves
Enabling NSE is a configuration plus a data-management decision:
1. Enable the NSE advisor data collection — HANA can analyze your access patterns and recommend which tables/partitions are warm candidates. Don't guess; measure.
2. Partition large tables by a temperature key (usually date) if they aren't already.
3. Move cold partitions to NSE with an ALTER TABLE ... USING NSE style operation on the chosen partitions.
4. Monitor the buffer cache hit ratio — if warm queries constantly miss the cache, either the data is hotter than you thought or the cache needs sizing.
The advisor step matters most. Teams that tier by gut feeling either move hot data to warm (and get complaints about slow reports) or leave everything hot (and get complaints about the hardware bill). Access statistics turn it into an evidence-based decision.
What changes for developers
Mostly: nothing, and that's the selling point. SQL doesn't care where the pages live. CDS views don't care. ABAP doesn't care. But two things deserve attention:
Query patterns matter more. A warm-table full scan that pages gigabytes off disk will feel it. Queries that were "fast enough" on hot data may need their filters tightened or an index rethought once the table goes warm. Review your heaviest queries against newly-warmed tables.
Load behavior. The first touch of cold pages costs a disk read; subsequent touches hit the cache. If a monthly report always starts slow and then speeds up, that's the buffer cache warming — expected, not a bug.
Backup and recovery. NSE pages live in HANA's data volumes, so they're captured by normal HANA backups — no separate warm-tier backup strategy needed. Recovery restores pages to disk; the buffer cache simply re-warms on first access. One sizing note: your data volumes need to accommodate the warm data, so factor NSE into disk capacity planning, not just memory.
NSE vs. the alternatives
NSE isn't the only way to get data out of RAM. Dynamic tiering (the older extended-storage option) is being superseded by NSE — if you're planning new tiering, NSE is the direction. Data archiving physically removes data from the database; it's cheaper still, but the data is no longer queryable in place. NSE sits between: cheaper than RAM, still fully online.
The decision rule: if the business still queries it with normal SQL and expects normal (not instant) response times, NSE. If nobody may ever query it again and compliance just needs it retained, archive it.
Done right, NSE is invisible infrastructure economics — same queries, same apps, smaller memory bill. The only visible change should be on the invoice.