SAP nearline storage (NLS) vs. HANA memory: a cost breakdown

The CFO opens the meeting with a question that is not in the deck. How much of what we just paid for HANA is data we have not queried this quarter?

The architecture team has the answer; they just have never been asked to present it. The honest number, pulled from the access logs, is north of seventy percent.

Which means the bill on the table is, for the most part, the price of keeping records warm enough to be queried twice a year, on a platform built for sub-second access to live ones.

This conversation is the one no SAP architecture deck includes, because the answer makes the previous architecture decision look expensive in retrospect. But it is the conversation that pays for the next three years of SAP cost optimization.

Step One — The Wrong Assumption

Storage is cheap; just put it all in HANA.

"We standardized on HANA. We don't want to manage a separate tier."

— Standard architecture rationale, post-S/4 migration teams

The assumption traces back to a simpler era when SAP storage meant disk and the difference between hot and cold was a few cents per gigabyte. HANA changed the math entirely. In-memory storage carries a price per gigabyte that reflects DRAM, license entitlement, and the redundancy required to keep an operational database running. Treating that tier as a generic store for cold history is not a small inefficiency — it is the single most expensive form of data retention an enterprise can engineer.

Step Two — The Partial Signal

The HANA growth chart goes up, and the wrong fix gets ordered.

The partial signal arrives as the HANA monthly growth report. The chart shows a smooth upward trend, broken only by occasional step-functions when a major business event posted unusually high transaction volume. Operations responds by adding capacity. Capacity is added. The chart resumes its trend.

What the chart is not telling anyone is the access age of the records driving the growth. Nearly all of the new memory the system is consuming is being assigned to records that will not be queried again. The platform is doing exactly what it was designed to do — keep loaded data in memory — and the workload is sending it data that should never have been loaded in the first place.

Step Three — The Failed Fix

Scaling HANA capacity without changing data placement.

The failed fix is the standard capacity-management playbook: forecast growth, add nodes, repeat. The fix is failed because the cost driver is not the capacity of the platform; it is the absence of a tier underneath it. Without a defined cold tier, every record that ages out of operational relevance still lives in operational memory. Without retention rules that move it, the average age of the dataset rises every year, and the percentage of HANA spend allocated to data nobody queries climbs with it.

The harder the platform team works at capacity management without a placement strategy, the more expensive the dataset becomes per actual query served.

Fig. 1 — Without a cold tier, HANA memory becomes the de-facto retention layer — at the price-per-gigabyte of the most expensive tier in the platform.

Step Four — The Real Failure

The actual failure is the absence of a defined cold tier.

The real failure is structural. SAP's reference architecture has always included a nearline tier — formalized for BW and BW/4HANA as the NLS interface — precisely because in-memory storage was never intended to be a retention medium.[1] Programs that treat NLS as optional treat the most expensive tier in the platform as the catch-all, and they pay for that decision in proportion to data growth, every year. Programs that treat NLS as required size HANA to the operational footprint and let the cold tier carry the history, with read-back available through standard interfaces when the audit or the reporting requires it.

The economics of the two architectures diverge linearly with data age. By year three of operation, the gap is large enough that the NLS-tiered program is paying a fraction of what the unredistributed one is paying for the same business outcome.

Step Five — The Definition

Now the definition lands.

Nearline storage (NLS) is the SAP-defined tier for cold, queryable retention of business data outside of HANA memory — with continued read access through the SAP standard interfaces and full integration with SAP ILM retention policy.

The key word in the definition is queryable. NLS is not offline backup; it is a live, addressable tier the SAP system can read from without restoring. That property is what lets the platform team move data out of memory without losing the read path the business depends on.

What Solix Enforces

An NLS tier that integrates with SAP ILM and keeps the SAP read path intact.

What Solix runs here is the SAP-certified nearline stack: ILM-governed retention, BC-ILM-NLS certification for the SAP read interface, and storage economics deliberately tuned for cold queryable retention rather than hot operational access. The platform team gets a defined cold tier, the business keeps the standard SAP read path, and the HANA footprint is sized to operational reality rather than to history.

Three things to do this week

• Pull access logs by record age for your top 10 tables. Sort by access age, not by row count. The records that have not been read in 18+ months are your candidate cold tier. In most SAP shops this is 60–80% of the volume.
• Price your current HANA footprint at the access-frequency split. Take the percentage of records that have not been queried in 12 months, multiply by your effective HANA cost per gigabyte, and the result is the recurring spend that NLS is built to absorb. Show it to the CFO before someone else does.
• Pilot NLS on one archive object before extending it. Pick one high-volume archive object (FI_DOCUMNT is the standard first move), run it through ILM retention, and verify read-back from a standard transaction. The pilot answers the platform team's only real question about NLS: does the SAP read path stay intact? It does.

References

• SAP Help Portal — Nearline Storage for SAP BW and SAP BW/4HANA. SAP-defined nearline tier for BW and BW/4HANA, with read-back through standard interfaces.
• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. ILM is what binds retention policy to the data that moves to NLS.
• Gartner press — Gartner Forecasts Worldwide Data Management Software Spending. Gartner's data-management forecast tracks the cost-tier optimization spend that NLS represents.
• Forrester — Forrester Wave: Data Management for Analytics. Forrester's analysis of in-memory economics underlines the cost gap between hot and cold tiers.
• IDC press — IDC Worldwide Global DataSphere Forecast. IDC's global datasphere forecast establishes the growth curve that makes a single-tier model untenable.