Why Did SAP Pivot the Explanation of HANA In Memory?

ByPrimary Researcher

Executive Summary

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

Video Introduction: Why Did SAP Pivot the Explanation of HANA In Memory?

Text Introduction (Skip if You Watched the Video)

SAP first introduced the idea that HANA would load all data 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 started to change the description of how its HANA database worked, to the point where it sounded much more similar to how other databases optimized their memory. We covered this in the article Is SAP’s Warm Data Tiering for HANA New? You will learn why SAP pivoted on how all of the data in HANA’s database was loaded into memory.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

A Hypothesis Put Forward By Ahmed Azmi

Give me any database system and I can boost its performance by 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 merely brings HANA’s explanation back into line with reality.SAP clearly explained that HANA used memory optimization and did not load all data into memory in HANA’s technical documentation.

Oracle’s View on HANA In Memory

While the article you are reading was initially published in June of 2019, in August of 2019, Oracle released 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.

Go to top

Conclusion

SAP has two explanations for its products. One is the sales and marketing explanation. This explanation not only exaggerates the description 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.