Did SAP Simply Reinvent the Wheel with HANA?

Executive Summary

  • SAP made many claims about HANA, but upon analysis, what SAP actually did with HANA is reinvent the wheel.
  • SAP made these claims in order to push customers into replacing Oracle with HANA.
  • We cover SAP proposals ranging from code pushdown to in-memory computing to the fictitious backstory for HANA.

Introduction to HANA as a Derivative Product

Innovation has been a critical selling point of HANA. You will learn how the claims around HANA’s innovation checks out.

Understanding SAP’s History with HANA

When SAP first introduced HANA, which was begun with enormous fanfare the idea was that SAP had created a whole new database. In fact, in as recent as the Q4 2017 analyst call, Bill McDermott stated the following:

“Back in 2010, we set bold ambitions for SAP. We focused on our customers to be a truly global business software market leader. We set out to reinvent the database industry.

Forrester has now defined the new market for translitical data platforms, and of course, they ranked SAP HANA as the clear number one. We led the market with intelligent ERP, built on an in-memory architecture.”

In this article, we will analyze how much of what SAP created with HANA is new and how much is simply copied from other database vendors and then claimed as innovation.

Important Information About HANA

We have performed extensive detailed analysis of HANA. The more we look, the less we can find that is unique or innovative.

Let us review some of the major points of inconsistencies with the innovation story around HANA.

The Performance of HANA

SAP has vociferously proposed that HANA is faster than any other database. However, they have provided no evidence that this is true. We performed the necessary research into this topic and concluded that SAP’s claims of superiority versus the competing offerings of Oracle, IBM and Microsoft are untrue. We have explained this in the article What is the Actual Performance of S/4HANA? 

The Column Oriented Design of HANA

SAP has proposed that they essentially invented column-oriented databases. Column-Oriented databases go back as far as row oriented (often referred to as relational), and SAP acquired Sybase in 2010 before HANA was introduced. And Sybase already had IQ, now SAP IQ, that is was a column-oriented database.

Furthermore, SAP made other acquisitions very silently, to give the impression that they “invented” the technologies that underpin HANA. At the same time, SAP’s marketing documentation was intended to give prospects the impression that SAP had invented a new category of databases. Notice Bill McDermott’s statement around “reinventing the database industry.”

That is reinventing it with a database design that had been around for decades? Furthermore, this comment was not made in 2011 or 2013 when HANA had yet to be challenged. This comment was made in 2018 after plenty of time has passed to verify the marketing statements about HANA with both real implementations, benchmarking and the HANA technical documentation.

SAP has a long history of faking innovation. Faking innovation is a major strategy in both software and patent drug industries which covers for a process whereby innovations are taken from the public domain (or from competitors) and repackaged as something developed internally. 

Calling All New HANA Development “Innovations”

SAP has claimed that because HANA is being actively developed, that each development is innovation.

Yet, the items that HANA is developing already exist in other databases. The definition of innovation is that the item needs to be new. Not new to the software vendor, but new to the world.

While not discussed, the innovation should also be beneficial. Areas where SAP has done things that are new, such as reducing aggregates, have not been demonstrated to be beneficial. Reducing database size is really an issue if a company is somehow constrained in the size of their databases, but with the very low cost of modern storage, this is not the case.

SAP has proposed through surrogates like John Appleby of Bluefin Solutions that hard disks “take up a lot of space,” and that companies cannot afford the storage space to locate disks – which is either absurd or insulting depending upon your perspective. One has to question the innovation of any company that has a spokesman like John Appleby (which we cover in the article Why John Appleby Was so Wrong About His HANA Predictions), Vishal Sikka or Hasso Plattner that are repeatedly found in hindsight to have knowingly released false information into the marketplace. It is normally the case that truly innovative entities do not find it necessary to lie about their innovations.

The Code PushDown of HANA (Innovation or Innovative Terminology?)

A stored procedure is the established term for when the code is moved from the application layer to the database layer, normally for performance reasons. However, SAP decided to come up with a new term, code pushdown. 


Well as our colleague points out.

“But by using the code pushdown term and not “stored procedures + DB views”, they not only have an innovative term for real “stored procedures” but also obscure that classic ABAP views are extremely far behind REAL Views that exist for decades and that this is one reason why the database is kept so stupid in classical “ERP on AnyDB”.”

This is why analyzing the terminology that SAP uses is so important. SAP uses specialized and often inaccurate terminology in order to to lie to customers. This is found the way that SAP called HANA “in memory,” which we cover in the next section. When a false term is used, it is just the starting point. It can be considered the sound of a gate opening for what will be a torrent of false information.

SAP’s presented logic for code pushdown is performance, but when SAP had no database to sell, they were in favor of performing processing in the application layer. The code pushdown is what has served as justification for SAP to keep S/4HANA exclusive to HANA. That is curious, an ERP system, which has relatively low-performance requirements must have the code pushed down to the HANA database, but other applications that SAP offers, that SAP has less account control over, still work on AnyDB.

Here the obvious factor in the determination of which applications are exclusive to HANA and which does not have to do with leverage, not the technical requirements.

The CDSs of HANA

Core Data Services are a type of code pushdown that is a database view. SAP has introduced CDSs as something new, when in fact they are copying the idea of the dictionaries that have been available in AnyDB databases for decades.

SAP has stated that AnyDB can also “use” CDSs, but the question is why they would want to do so. SAP is giving the impression that what is really just catching up with other database vendors, it is actually coming up with something new that does not already exist for AnyDB database. Here again, SAP’s innovation claims do not pass the smell test.

Caching of Queries

In the document Boost Performance for CDS Views in SAP HANA, SAP states that it needs to cache queries for performance.

It further states:

“Keep CDS views simple (in particular serviceQuality A and B = #BASIC views)
In transactional processing, only use simple CDS views accessed via CDS key
Expose only required fields define associations to reach additional fields when requested”

This is odd. For an in-memory zero latency database like HANA, why would these limitations need to be put into place?

“Perform expensive operations (e.g. calculated fields) after data reduction (filtering, aggregation)
Avoid joins and filters on calculated fields
Test performance of CDS views. Test with reasonable (= realistic) test data”

This speaks to the need to limit the consumption of computing resources. Again, it should not apply to HANA.

“Stay tuned on caching possibilities of SAP HANA and Fiori apps.”

Caching for Both HANA and Fiori?

Caching for both HANA and Fiori? Impossible! A foundational proposal of SAP since HANA was first introduced was that there should be no caching.

Everything, literally everything is supposed to be in memory. Caching makes no sense with the presented HANA design. The people working at SAP on HANA and who presented this at TechEd 2017 clearly do not understand Hasso’s vision.

According to Hasso Plattner, HANA is and forever will zero latency. But the techniques that are described in the actual HANA technical documentation show a much more complicated picture with SAP performing caching in several locations.

Not only can HANA not provide zero latency (surprise, surprise), but testing even optimized demo boxes shows that Fiori running on HANA underperforms open source databases and server technologies like MySQL and Apache as explained in the article Why is the Fiori Cloud so Slow?

Furthermore, the hardware specs that SAP has for HANA are extremely large. The column-oriented store combined with the large quantities of RAM is supposed to be so incredible, that these types of techniques should not be necessary. But HANA underperforms other databases even though it has far more hardware. The Oracle benchmark shows that HANA was only able to come close to Oracle 12c performance with far more hardware. This is, of course, a benchmark produced by Oracle. However, other private benchmarks that have been made available to Brightwork show the same thing.

Everything In Memory and In-Memory Computing?

When HANA was first introduced, SAP stated that the entirety of the database would have to be loaded into memory. However, the technical documentation on HANA shows clearly that only some tables are loaded into memory. Neither the large tables nor the column-oriented tables are immediately loaded into memory. This is peculiar, as it was supposed to be the relationship between column-oriented and tables and high-speed memory that were to provide HANA with its analytical advantage. However, either way, HANA uses memory optimization….surprise, just as all of the other database vendors that SAP is copying its solution from. As we covered in the article How to Understand Why In-Memory Computing is a Myth, all databases have their tables placed into memory.

However, a database is much more than whether a larger percentage of the tables are placed into memory or whether it uses a column store for more of the tables. This is, by the way, another detail that has come to light as time has passed. Originally, SAP stated the entire database was a column store (which would not have made any sense by the way), then it is determined that many of the tables in HANA are in fact rows.

Here again, one thing is stated about how HANA works, implying that all other database vendors are backward for using memory optimization, and then once the technical details are read, HANA just does the same thing other databases do. This gets back to the central point that almost nothing that a salesperson or HANA marketing literature says about HANA can be trusted.

The Obvious Conclusion

Increasingly it simply appears that purchased some database products, and then reverse engineered existing databases, while putting an extra emphasis on placing more of the database in memory.

Innovation or Copying while Throwing in Confusing Terminology?

When discussing this topic with several other people investigating HANA, the following insight was given to us.

They recreate the wheel as an octagon because anyWheel is round and then sell you a cycloid molded road to drive smoothly – but only on their roads.

What is Truly New in HANA?

It seems like a lot of this is just recreating the wheel, but with the blue SAP bow on top.

This is how Hasso Plattner, SAP and SAP partners would like to present the genesis of HANA. Not as a series of technologies that SAP purchased more than year before HANA’s development, not based upon databases that had been developed more than a decade before HANA, but as divine inspiration by Hasso and his brilliant PhDs. Hasso has repeatedly been referred to as a genius. A genius who “discovered” something that he directed SAP to purchase, and then after purchasing, immediately invented. This false storyline is laid out very carefully in the book The In Memory Revolution. 

HANA, The Only Database With a Purpose Built Fictitious Backstory

In the article Did Hasso Plattner and His Ph.D. Students Invent HANA?, we uncovered (with some helpful hints from someone who reached out to us) that unlike what was stated by SAP and Hasso Plattner. And unlike what has been repeated ad nauseam by compliant IT media entities and SAP consulting partners, the underlying technology for HANA was purchased not invented by SAP. Furthermore, Hasso Plattner and his Ph.D. students added nothing to these technologies except developing rather impractical ideas such as a database having no aggregates.

SAP did not innovate with HANA. Their primary contribution was to promote the idea of dual-purpose databases, that is a database that can equally well perform transaction process and perform analytics. Yet there is no evidence that this strategy is worthwhile. While doing this SAP has both massively overstated the benefits to such a design while at the same time glossing over all of the downsides to such a design, one of which being higher overhead. Furthermore, as we covered in the article HANA as a Mismatch for S/4HANA and ERP, it is clear that SAP has not mastered the ability to perform both OLTP and OLAP equally well from a single database.

Through four books, which are littered with falsehoods, and serve more as marketing collateral for HANA than “books” in the traditional sense “written” by Hasso Plattner was meant to storm the consciousness of prospects with how amazing HANA would be. It is one of the first books written that describes the invention of something that had already been invented. 

Ding Ding Ding!

SAP receives our Golden Pinocchio Award for first purchasing the technologies that underpin HANA, then reverse engineering other databases and calling it innovation. HANA should be considered a case study in innovation fakery. Why is this not publicly known? Due to the partnership agreements that SAP maintains with other vendors, this has prevented SAP for being called out for its innovation fakery by vendors that know but are censored due to their partnership agreement with SAP. The only entity that could cover this story would have to have complete independence from SAP, which also rules out IT media entities that cover SAP. 


HANA is consistent with what is becoming an established history with SAP of exaggerating its innovations and making it appear that ideas and techniques that it took from other places were developed inside of SAP. HANA does not run 100,000 times faster than all competitive offerings (Bill McDermott). It is not an innovative database.

The primary thing that is innovative about HANA is that SAP tells customers that it is innovative. Once you look under the hood what you have is a far less mature database than other offerings, and a desire of SAP to push competitors out if “its” accounts by using a falsified storyline about how innovative HANA is to customers that are soft targets. That is the less database knowledge prospects have; the more SAP can gain traction in those accounts by propagating very large disruptions to their customers while greatly increasing the TCO of the databases used by them.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.