Why Did SAP Pivot the Explanation of HANA In Memory?

Executive Summary

  • SAP has a very different explanation of how HANA’s memory management than when HANA was introduced.
  • We address why this pivot occurred.


SAP first introduced the idea that all data would be loaded into memory. We called out this as a myth in the article How to Understand the In-Memory Myth. This went on for years beginning in 2011 and extending out to 2018. Then SAP began to change the description of how its HANA database worked, to the point where it sounded like how other databases optimized their memory. We covered this in the article Is SAP’s Warm Data Tiering for HANA New?  

But one question is why this pivot changed.

A Hypothesis Put Forward By Ahmed Azmi

Give me any database system and I can boost its performance by an order of magnitude simply by upgrading the hardware. If you spend a million dollars on memory and processor acceleration, you can make any database faster. It’s just a matter of throwing more hardware (money) at it.

That’s why SAP had to claim that HANA stores everything in memory. They had to justify the nefarious cost of the hardware. Now, they are pivoting away from that because they realized that hardware-driven performance doesn’t work when the product is hosted on a multi-tenant, scale-out platform like Azure & GCP.

This could be an explanatory reason for the change. It also simply brings HANA’s explanation back into line with reality. The fact that HANA used memory optimization and did not load all data into memory was clearly explained in HANA’s technical documentation.

Oracle’s View on HANA In Memory

While the article you are reading was originally published in June of 2019, in August of 2019, Oracle published a document called Oracle for SAP Database Update.

In this document, Oracle made the following statement about HANA versus Oracle.

Oracle Database 12c comes with a Database In-Memory option, however it is not an in-memory database. Support-ers of the in-memory database approach believe that a database should not be stored on disk, but (completely) in memory, and that all data should be stored in columnar format. It is easy to see that for several reasons (among them data persistency and data manipulation via OLTP applications) a pure in-memory database in this sense is not possible. Therefore, components and features not compatible with the original concept have silently been added to in-memory databases such as HANA.

Here Oracle is calling out SAP for lying. Furthermore, we agree with this. SAP’s proposal about placing all data into memory was always based upon ignorance and ignorance on the part of primarily Hasso Plattner.

If SAP had followed Oracle’s design approach, companies would not have to perform extensive code remediation — as we covered in the article SAP’s Advice on S/4HANA Code Remediation.


SAP has two explanations for its products. One is the sales and marketing explanation. This explanation not only exaggerates the explanation of their products, but in many cases changes the fundamental features of how their products work. HANA’s supposed “in memory” explanation which persisted from 2011 to 2018 is just one example of this.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

S/4HANA Implementation Research

We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.

Select the description that best matches you.

Option #1: Do You Work in Sales for a Vendor?

See this link for an explanation to sales teams.

Option #2: Do You Work for an Investment Entity that Covers SAP?

See this link for an explanation for investment entities. 

Option #3: Are You a Buyer Evaluating S/4HANA?

For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers

Search our Other In Memory Computing Content