SAP HANA False Claims

How an SAP HANA Sidecar Becomes a High Overhead Item

Executive Summary

  • SAP created a concept of an SAP HANA sidecar, which was designed to get customers to implement uncompetitive or immature solutions.
  • The benefit of the free SAP HANA sidecar is one example of this.


The SAP HANA sidecar was presented as an essential step to using HANA very aggressively in 2013, and less so since then. In this article, you will learn SAP’s logic behind a sidecar, and whether the logic actually holds up.

See our references for this article and related articles at this link.

What is an SAP HANA Sidecar?

An SAP HANA sidecar is where HANA is run as an offline system. The offline nature of the SAP HANA sidecar is critical to understanding the overall concept, as the idea being that HANA is first tested offline before being brought online.

Here you can see a standard graphic that shows a HANA sidecar design.

Using the “sidecar,” the data is replicated to HANA. This is to be a precursor to replacing the current database, called AnyDB, to reflect it being Oracle or IBM, etc.. with HANA.

Why this database is being replaced in the first place is an interesting question as Oracle, HANA and MS are continually updating their databases. And there is no evidence presented by SAP that HANA outperforms other databases even in analytics, as we cover in the article What is HANA’s Actual Performance and Articles that Exaggerate HANA’s Benefits. But SAP continues to use uses false compatibility claims to push customers to HANA. They do this even when there is no evidence for HANA outperforming the database it is replacing.

Here is a typical quotation from SAP on this topic that tries to ease companies into moving towards HANA, without providing evidence that moving to HANA makes sense.

“Customers can add new analytics capabilities immediately without disruption to their existing landscape. Any investment today will be valid for SAP Business Suite powered by SAP HANA.”

The logic often presented by SAP is that if SAP offers an item, that it naturally should move moved to.

Benefits of the SAP HANA Sidecar?

And here is another promoting the benefits of this design.

“The way the current SAP systems work is, the data is transferred from database to application layer and calculations are performed in application layer. Here you have significant latency between disk to memory transfer and then calculations in application layer. HANA database on the other hand is optimized for mass parallel processing and performs calculations in the database layer and only submits a result set to the application.” – HANA Discussion Thread

There are several essential questions to ask regarding this comment.

  • Is This True?: This idea of using a stored procedure for processing has been proposed for quite some time. However, the main reason that SAP promotes this concept is so they can reduce the compatibility of their applications with other database vendors, which is databases other than HANA.
  • Superior Performance?: As explained in the article, What is the Actual Performance of HANA?, there is no evidence that HANA outperforms other comparable databases. The evidence appears to point in the opposite direction. And these comparable databases can achieve this performance without stored procedures.

What is the Overhead of the SAP HANA Sidecar?

One of the greatly underemphasized points is that this replication of data between the active system and the sidecar is quite a bit of overhead. This is, of course, minimized by those who propose using the SAP HANA sidecar. To explain this overhead, we will review the requirements of the sidecar.

Here are a few of the requirements to achieve data replication for a HANA sidecar.

  1. “Data must be loaded from the current database to the HANA database using any of the existing replication scenarios (DXC, Data Services, SLT) or ABAP custom code.
  2. If you require real-time loading into HANA sidecar, you will still need SLT or have custom code that loads to HANA via secondary database connection every time a change is triggered
  3. Custom ABAP programs are needed to be able to connect to the HANA database and retrieve/insert/update data
  4. To fully optimize the performance of HANA as a sidecar, all custom ABAP code must be optimized to run SQLSCRIPT to fully utilize the HANA calculation (refer to part_2 blog for more details)
  5. HANA only runs on SUSE LINUX SP11, so if your current hardware/os does not include SUSE LINUX you will need get hardware specifically for HANA” – HANA Discussion Thread

The Project Duration of HANA as a Sidecar

A typical HANA implementation will take between 1 year and 1.5 years to finally migrate. This means that the customer has to run the sidecar this period and absorb the cost of doing so. This is a longer duration than is pitching by SAP account executives, and it is one reason why HANA’s TCO is so high.


SAP sidecars can be viewed as a sales strategy to push immature applications into prospects and customers by taking the solution “offline.” The idea being presented by SAP is that the sidecar allows the customer to incorporate “innovation” into companies. However, the overall presentation is a problem. One major reason is that the buyer beings investing from when they buy the sidecar software, and this can easily lead to “sunk cost” decision making where the customer continues to invest in a solution. That is, the sidecar can very easily become “project quicksand.” And this is, of course, the objective of those that present sidecars.