A HANA Versus DB2 Case Study

ByPrimary Researcher

Executive Summary

  • SAP has made enormous claims around HANA, but data points from the field contradict these claims.
  • In this article, we cover one of these case studies versus DB2.

Introduction

We have been publishing individual case studies for HANA. In each case study, there is information in dramatic opposition to what is generally published on HANA.

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. 

Here are some direct quotes from someone who reached out to us.

DB2 Stability Versus HANA

We have had DB2 in our environment running SAP for over a decade. It has taken a lot of external damage (power outages, disk loss, hardware failure) and worked like it’s reputation as a tank.

DB2 is not fancy, and IBM has dropped the ball with marketing on this gem, but it just worked. You could sleep at night with it.

We converted our BW system to HANA, in in less than a month, it had 2 corruption bugs.

Data Loss Due to HANA

Sales will often discuss how quickly something can be done. However, what is often left out of the discussion is the repercussions of a change.

We lost an entire month’s worth of data because the corruption was not detected until we restarted the system. Support initially was horrible and even at points contentious with us. Took us 3 days for support to admit there was corruption, and that only happened when our sales rep (who did a great job) got involved. After that, support was great.

For a supposedly flagship product, this was the biggest disappointment and most painful experience of my entire career.

Well, that is quite a statement, but as we have covered in many articles at Brightwork, HANA can’t meet the sales and marketing claims around it. HANA is a flagship product, but it is still not a mature product.

Forced Conversion to S/4HANA?

We dodged a major bullet. We were able to successfully recover our lost data from our ECC system.

Now SAP is forcing customers to convert to S/4. I cringe at the thought of that given our experience. Digging through the SAP HANA known issues OSS notes, there’s tons of corruption and crashes documented. While I appreciate support’s transparency, it shows how immature this product is.

This is a serious issue as we cannot find a single live S/4HANA instance that we consider real. That is not a S/4HANA instance that a consulting company is only using to sell S/4HANA services, an offline test system, etc.. We think that S/4HANA should not even be considered for evaluation until 2022.

SAP’s Database Obsession

“Who buys a product because of the database? It’s the most unsexy part of the entire software stack. It’s just supposed to run and move data in and out AND KEEP IT SAFE.

When I go to Salesforce, or ServiceNow, or any other SaaS provider, do I really care what backend they are using? No, I just want it to work.

Selling points should be on the front end, the business logic.”

Yes, that is true. We covered how SAP overemphasizes HANA in the article How SAP HANA vs. TeraData and Tableau Market Backend Technology.

Issues with Aggregation and HANA

“Also, another selling point SAP gave us was that development would be much easier, because a lot of aggregation layers would be stripped out of the process. Guess what, if you go live on HANA from scratch, that may be true, but if you’re a legacy customer, the maintenance of these “Hanatized” objects is actually double the work.

And you know what that Hanatization actually does? It makes it impossible to run those objects on another database. What does that mean? It means vendor lock-in and impossible switching costs.”

Correct. SAP has been silent because HANA has inconsistency with BW, which is where most of the HANA implementations have been performed. BW was designed to work with a row-oriented database, as we cover in the article The Four Hidden Issues with SAP’s BW-EML Benchmark.

The Benefit of HANA Over Sybase?

“The other question is, why couldn’t SAP just give customers an incentive to run their stack on Sybase? That is a mature code base that is robust, Wall Street has run it for decades and it would have been another sleep at night technology I would have been fine with.

SAP could have offered HANA as a premium feature, like they did with BW accelerator or Livecache.”

SAP owns the IQ and ASE database from the Sybase acquisition. However, it deemphasizes the far more mature Sybase databases in favour of HANA. This is true even though IQ is a column-oriented design, which is very similar to HANA.

Go to top

Conclusion

This case study tells us an interesting story corroborated by other case studies and other research we have performed. As is the norm, the case study shows no connection to HANA’s sales and marketing claims.