Which is Faster HANA or Oracle 12C?

ByPrimary Researcher

Executive Summary

  • SAP proposes that HANA has advantages in performance versus all other databases with a database that runs 100,000 times faster than any other.
  • We cover if HANA is really faster than Oracle.

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. 

Introduction

HANA is a constant source of discussion on SAP projects. The claims by SAP are enormous, but how many are true? SAP proposes that HANA has advantages in performance versus all other databases, with a database that runs 100,000 times faster than any other. The confusion on HANA vs. Oracle performance is due to the commingling of hardware speed and database design. SAP’s strategy for using HANA to lock out other database vendors (as claimed by Teradata). We cover SAP’s conflict of interest in not certifying Oracle 12c for S/4HANA. You will learn about the debate, the truth on HANA vs. Oracle from an independent source, and the multiple dimensions of SAP claims.

Our References for This Article

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

*Note: This article was originally written in April of 2016, and it refers to some articles by SAP earlier than this. However, the article has been updated as of February 2020, and it is applicable several years later. 

The History of HANA

SAP has promoted HANA and has run far faster than any alternative database, which means HANA vs. Oracle.

This has been the logic used for why SAP would not port new applications, like S/4 (SAP’s new ERP system), to Oracle. (as Oracle has the largest market share of supporting SAP applications, although SAP also is targeting IBM and SQL Server)

This contention has few independent parties even investigating this issue.

A Recipe for Confusion on HANA vs. Oracle: The Commingling of Hardware Speed and Database Design

One of the confusing aspects of HANA vs. Oracle is that two different topics are commingled and communicated as if they are one topic.

  • One is the hardware issue, as SAP HANA requires moving the active database into memory.
  • A second aspect is the database design, which is the column-based database.

SAP discusses these two topics as if they are the same subject.

One could say that SAP has done a poor job of explaining the distinction. I don’t think SAP is trying to be clear in this area and is primarily hoping customers are confused.

  • The less clear SAP’s customers are on where the potential benefits come from, the more the advantage swings to SAP when negotiating.
  • The more ability it has to market SAP HANA vs. Oracle as a differentiated offering.
  • The more it can position SAP HANA as worthy of a severe price premium.

Something that goes undiscussed by SAP is how SAP HANA is both a technology strategy and a targeted strategy to push Oracle out of SAP accounts.

Take the Queen: SAP’s Strategy for Locking Out Other Vendors

This is an extension of a strategy that SAP has used to affect decades significantly but with a slight twist. SAP kept other applications out of its customers by using the ERP system as a queen on the chessboard.

We refer to this as the “take the queen” software strategy.

By declaring that all other SAP applications would integrate better with the queen, SAP’s customers could have lower-risk implementations. This was false — and a primary reason was that SAP’s applications had been far higher risk than the applications they competed against. 

The Result of the “Take the Queen” Sales Strategy

This strategy has been enormously successful, even after most vendors have come close to SAP’s integration with their adapters. Only the ERP system is “fully integrated.” The modules run off the same database, all other SAP applications are connected through adapters, and many SAP-acquired applications have worse adapters than non-SAP applications.

ERP systems’ account control features are covered in the article ERP Systems as a Trojan Horse, and ERP Became an Out of Control Octopus.

SAP does not just sell a company an ERP system. The ERP system is just the wedge that breaks into the account. Like an octopus, SAP keeps hammering on different areas that must be made “SAP standard.” The development language used in the other applications must also be SAP. Now, SAP has been pushed into the database layer. Oracle, the primary vendor SAP is trying to push out of SAP accounts with HANA, functions similarly. 

Using Control of the Application Layer to Push into the Database Layer

One-time horizontal competition — i.e., competition at the application layer. HANA is a twist on this block-out strategy but takes it to the database layer. This is why SAP is so firmly positioning HANA vs. Oracle. It prevents Oracle (and other databases) from competing with S/4 by not certifying Oracle’s database even though there is no reason that Oracle, IBM, and SQL Server cannot fully support S/4HANA. Further, recall that none of the databases in the mix is open source — even though open source databases like PostgreSQL or MariaDB could easily support SAP. This is a battle between monopolistic high overhead and controlling software vendors.

As soon as Oracle resources want to cry foul, remember that Oracle also restricts certified databases for its applications, even more so than SAP.

Code Pushdown and Stored Procedures

SAP’s main argument for why S/4HANA is restricted to HANA is that SAP has pushed some S/4HANA code into HANA and is not doing so for Oracle or other databases. The logic of the stored procedures placed into HANA is a cover because SAP uses S/4HANA’s exclusive certification to drive HANA sales, which we cover in the article SAP’s Arguments on Code Pushdown.

Let us be clear on this topic.

SAP does not care if performance increases for customers. SAP introduced HANA and says what it does about HANA for one reason: to increase its sales and to push Oracle out of accounts. SAP consultants at SAP consulting firms that repeat HANA talking points don’t know if they are true and usually don’t care. They make statements to increase billing hours.

Finally, the general database knowledge inside SAP and the consulting firms of SAP consulting firms is relatively poor. At Brightwork, we ignore what SAP resources say about HANA because it never matches the data points we receive from SAP customers. We have extensively researched the private benchmarking information we access or the evidence and history around HANA’s performance.

The Real Opportunity with HANA vs. Oracle?

It has been proposed that the real chance with HANA is for the company to place ERP and all other SAP applications on HANA. Then, the analytics engine can sit right on the same hardware. And now, no integration or transformation is necessary, and analytics reports are from the application tables.

SAP’s Idea of All Data Sitting on HANA

After over five years of breathless conferences about the brave new world of analytics, the latest Big Data, and overall analysts’ obsession (which has led to far fewer benefits than initially proposed), SAP has proposed this will be all made better by having all company data sitting on HANA. How convenient. However, will we now transform all of the hardware to be optimized for analytics?

  • Also, what about non-SAP applications? They won’t sit on HANA, so they do have to be integrated and transformed.
  • Will SAP now argue that those applications are legacy because they don’t sit on the “strategic platform” for the company?

Secondly, using HANA is expensive. This is a topic we cover in the article How to Understand the Pricing of HANA and S/4HANA. HANA is quite a bit more expensive than Oracle, which is already very expensive. It falls into the exorbitant category if one follows Oracle’s “advice” and activates the higher-end functionality.

HANA is Not Expensive…Hasso?

Hasso Plattner has routinely argued that SAP HANA is not expensive.

Typically, Hasso Plattner will use the example of compression available in column-based databases to reduce the footprint. Hasso has so frequently talked about compression because HANA is priced per GB, which is strange for a database as most commercial databases are priced per CPU. If Hasso or the SAP account rep can make the database sound like it will be smaller than it is, SAP can get more sales.

However, if you talk to SAP account executives, they will tell you that SAP HANA is expensive. Furthermore, they will inform you that HANA is very hard to position for this reason; once the price tag comes back, the customer balks. We have routinely priced HANA for customers, and there is simply no getting around the fact that HANA is the most expensive database among the competing options.

We cover HANA pricing in the article How to Understand S/4HANA and HANA Pricing.

It is a simple thing for Hasso Plattner to propose in interviews how SAP HANA could be not too expensive in some hypothetical sense. But all other sources point to HANA being quite expensive. And you will not be buying HANA from Hasso but an SAP account executive.

Hasso Plattner’s Constant Inaccuracy

Something essential to consider is that Hasso’s accuracy historically is relatively poor, and I don’t see analysts or traditional IT media outlets recording this inaccuracy or commenting upon it.

I have performed a detailed analysis of Hasso’s statements on HANA, and when Hasso says something, he usually is wrong.

Hasso considers himself a professor and a highly technical visionary. However, his accuracy puts him close to a salesperson. As we cover in the article Thomas Edison, Elizabeth Holmes, and Hasso Plattner and How Much Should Hasso Plattner Be Cut Slack for Lying?

As we cover in a few paragraphs, SAP will never allow fair competition against Oracle or other databases because SAP knows it will lose. SAP is both the gunfighter in this scenario and the entity supervising the gunfight, as it is the certifying entity. SAP also has the power to block any database provider from publishing any benchmark under the partnership agreement. 

The Fastest Database in the West (HANA vs. Oracle)?

Evidence is building that HANA is not the speed champion that SAP says it is. One of the primary performance weaknesses of HANA is very rarely addressed. As a column-based database, HANA is not the correct database design for non-analytic applications. SAP has said it is, but this is from the computer science perspective, which is invalid.

Although SAP obscures that HANA cannot be 100% column-based or column-oriented in design.

As I pointed out in the article Where HANA Gets, it’s Speed, for inserts, deletes, or updates — which a transaction processing system does all the time, the column-based table is slower than the row-based.

Row-oriented databases are known as relational databases, which are row-based databases.

The Great Database Speed Debate

John Soat is a writer who works for Oracle and, like Hasso, is not an independent source on this topic. However, John’s article in Forbes makes some good points about HANA vs. Oracle. One that stuck out was SAP’s demurring on releasing HANA performance benchmarks for transaction processing.

..SAP has not published a single benchmark result for any of its transaction processing applications running on HANA. Why Not?

And I would say it is pretty apparent why not. And that is for transaction processing systems like ERP systems. These benchmarks won’t be particularly fast.

Vinnie Mirchandani, who was an independent source of the SAP HANA/Oracle 12C debate at the time of publication of SAP Nation 2.0, in his book SAP Nation 2.0, reinforces John Soat’s point on benchmarks.

It has not helped matters that SAP has been opaque about HANA benchmarks. For two decades, its SD benchmark, which measures SAP customer order lines processed in its Sales and Distribution (SD) module, has been the gold standard for measuring new hardware and software infrastructure. It has not released those metrics using a HANA database.

Misdirection from John Appleby

Is it possible that SAP performed the benchmarking but was poor, so it merely stopped reporting the result?

John Appleby, the Global Head of HANA at Bluefin Consulting a well known HANA advocate and someone who has provided an enormous amount of false information about HANA, has this to say about the topic — which is also documented in SAP Nation 2.0.

“The answer for the SAP Business Suite is simple right now: you have to scale-up. This advice might change in the future, but even an 8-socket 6TB system will fit 95% of SAP customers, and the biggest Business Suite installations in the world can fit in a SGI 32-socket with 24TB — and that is before considering Simple Finance or Data Aging, both of which decrease memory footprint dramatically.”

I can’t tell if this directly responds to the lack of transparency on transaction benchmarks, but if it is, it is an inadequate response. It looks to me that John Appleby is changing the topic in his answer.

We tracked John Appleby’s accuracy and displayed the article The Appleby Accuracy Checker: A Study into John Appleby’s Accuracy on HANA. In 2013, Appleby was aggressively and falsely promoting HANA to get his company ready to sell to Mindtree, as we covered in the article Appleby’s False HANA Statements and the Mindtree Acquisitions.

The Appleby (Formerly Known as the Hasso) Pivot

The question concerns the performance of a transaction processing system on HANA vs. Oracle. John Appleby quickly discusses how much companies should only buy more hardware and not worry about it. What is John Appleby talking about here?

He states that “for the SAP Business Suite.” He then declares the answer for this suite.

The only part of the SAP Business Suite that was ready for HANA (at the time of this quotation) was S/4 Finance. There is a lot of debate about how implementable S/4 Finance was at this time.

Secondly, as I stated, the rest of the suite, now called SAP HANA Enterprise Management, was not available for purchase at this time. John Appleby phrases his response to the future tense as if it is the present tense.

Is it, in fact, critical to scale up for something that does not yet exist?

Is Oracle Monkeying with the S/4 Certification?

John Soat also points out that while Oracle performed very well on one particular benchmark, SAP will not certify the result as SAP states that Oracle manipulated the test.

Now I was not at the trial, so I am in no position to say what Oracle did or did not do. Oracle has its story, and SAP has theirs. John Soat has a good explanation of each side’s position in his article.

Also, Stephan Kohler, an Oracle performance database consultant, said the following on this topic.

SAP already answered why they do not accept the benchmark results (you also find this in the mentioned article – Copy & Paste: “Oracle manipulated its BW-EML benchmark by using a custom setup involving database functions known as triggers and materialized views that can lead to hard-to-spot data inconsistencies and aren’t supported in real-world production environments.”). The reason was the use of triggers and materialized views, which are supposed to be not supported. However if SAP would have checked their own SAPnotes – you can see that it is clearly supported and also used in SAP ECO Space. SAPnote #105047: “Materialized Views – Use permitted.

For more information, see SAP Note 741478.” SAPnote #105047: “Trigger – Use permitted as part of the SAP standard system (for example, BW trigger /BI0/05* in accordance with SAP Note 449891, incremental conversion ICNV). Use of Logon Trigger permitted in accordance with SAP Note 712777. Implicit use as part of Oracle features permitted (for example, online reorganisation, materialized views, GridControl/Enterprise Manager). Use in connection with materialized views in an SAP BW system is permitted as long as no flat cubes are available as an alternative. There is no SAP Integration and SAP does not offer support for this.” Flat cubes are available in Beta since Q1/2016 – so nothing relevant to the Oracle benchmark from 2015.

And this leads to the next topic, which is a big one.

SAP’s Conflict of Interest in Not Certifying Oracle 12c

SAP now competes with all of the hardware vendors, placing SAP in a conflict of interest when certifying databases; this is a conflict of interest that, before its investment into HANA, it did not have. What was once a straightforward process is now rife with political intrigue, where one now has to parse the statements by SAP and Oracle to see who is telling the truth.

How can SAP certify Oracle, that is, give them a fair hearing if, by certifying Oracle, SAP cut into their market share for HANA?

The Mode Switching of Oracle 12c, a New Wrinkle in HANA vs. Oracle

Oracle 12c can switch between “modes,” displaying either in memory rows or columns. That is a serious advantage. IBM BLU has a similar ability. However, there is not much evidence that there is a significant need for a database that does both OLTP and OLAP — and it may not be feasible to design one that does each type of database processing equally well. The database trend is the opposite, with specialized database designs such as NoSQL and indexing databases flourishing.

However, getting back to the HANA versus Oracle 12c discussion:

  • Oracle’s flexible design should beat SAP HANA in performance for all but pure analytic applications. 
  • The logic presented by SAP that the entire database should be columnar never made sense because few tables are used in analytics. Therefore, does it make sense to use analytics-optimized tables (the columnar design) for every application table?
  • There is a debate as to how mature Oracle’s in-memory database is. SAP lists 7,000 SAP HANA customers. However, most of these customers are known to either not use the software (i.e., it is shelf-ware) or test systems, not live systems. As a consequence, SAP HANA skills are still quite hard to find.

Furthermore, Oracle’s in-memory modal switch adds to the price of Oracle 12c, both in license and maintenance.

SAP’s Rigged Benchmarks

SAP has had ample opportunity to prove its claims of superiority around HANA but has never done so. SAP has never allowed a comparative benchmark in transaction processing, as is covered in the article The Hidden Issue with the SD HANA Benchmark. And because HANA performed so poorly in the transaction process benchmark, it created a new reference that attempts to cover up this fact. But their reference is designed around analytics, which is covered in the article The Four Hidden Issues with SAP’s BW-EML Benchmark. This overall topic has come to a head, as numerous companies have complained about HANA’s transaction processing performance, which raises the question of how well HANA can support an ERP system, as is covered in the article HANA as a Mismatch for S/4HANA and ERP.

Go to top

Conclusion

With Oracle 12c, Oracle 12c can switch between row-based and column-based tables and switch for the same table, which is a new capability.

As far as I can tell, almost all of the SAP marketing documentation on HANA has preceded this development. If I were heading up HANA marketing at SAP, I would not want to address Oracle 12c because I would not have the correct answer. This is because Oracle 12c undermines the effort expended on SAP to get SAP customers to think that SAP HANA technology is unique to SAP to position SAP HANA as unique and better.

The new capabilities of Oracle 12c undermine some SAP contentions that have been proposed over the years. SAP has not addressed Oracle 12c, and most of the material created on SAP HANA was developed before Oracle 12c was released. IBM and MS SQL Server have similar column store capabilities. Not because there was a big reason to develop them but because SAP, through its enormous marketing, focused on this type of database functionality.

First, SAP now does not have a good reason- or should I say a good idea if it puts its customers’ interests first- to only port new SAP applications (like S/4) to SAP HANA.

Dictating the Database to the Customers?

The previous argument that only SAP could provide a fast enough database is most likely untrue. It was always a weak argument because regardless of the reason. No application vendor should be dictating the data layer to its customers. However, that is repeatedly what SAP has said it wants to do.

SAP still believes in running the new system in the cloud and on premise, but it will be only SAP S/4HANA with which we can achieve this in one software version going forward. This will reduce the TCO and speed up the so much needed step into the future. Every single application area like data entry, standard reporting, analytics and predictions, the digital boardroom or the multi-channel customer interaction, to name a few, becomes a world class component  in its own right. This alone is a reason to consider an earlier migration to SAP S/4HANA. – Hasso Plattner

SAP’s Interest in Sending the IT Industry Back in Time

At the Computer History Museum in Mountain View, an exhibit explains that, at one time, the software was proprietary to the hardware vendor. At that point, the software was not an “industry,” A program released by IBM could only run on IBM hardware. The software was not charged separately, so there was no competition at the software level.

The software industry we know today only came into its own after it was decoupled from the hardware. This was only done by the US’s threat to enforce anti-trust legislation against the proprietary software model and hardware vendors. HANA, as a coupling between the applications and database layer — controlled by a single vendor, takes us back in time.

This creates what amounts to a proprietary application/database combination.

  • SAP’s argument that only column-based databases have a future is also untrue.
  • Finally, unsurprisingly, to those who know the database vendors and their history, the idea that only SAP can develop a high-performance database that meets HANA’s speed capabilities is untrue.

SAP’s argument has not been that they are equal to every other database vendor. With HANA, they are superior to every other database vendor. That, of course, includes HANA vs. Oracle or anyone else, for that matter.

SAP certainly can and will keep selling HANA vs. Oracle. However, the exclusivity argument that SAP has been proposing is no longer a possible position to believe.