- 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 started 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.
See our references for this article and related articles at this link.
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 merely 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 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.
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.