How Accurate Was John Appleby on HANA FAQ?
Executive Summary
- John Appleby made bold predictions on HANA.
- We review how accurate he was in his article on HANA FAQ.
Introduction
John Appleby’s article on the SAP HANA blog was titled The SAP HANA FAQ and was published on September 9, 2014. We analyze this article for accuracy.
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.
The Quotations
HANA Performance
SAP HANA is an in-memory database and application platform, which is for many operations 10-1000x faster than a regular database like Oracle on the same hardware. This allows simplification of design and operations, as well as real-time business applications. Customers can finally begin to reduce IT complexity by removing the need for separate and multiple Application Servers, Operational Data Stores, Datamarts and complex BI Tool implementations.
HANA loads more data into memory and uses a high hardware specification with lots of memory. However, HANA did not and still does not load all data into memory, as we covered in How to Understand the In Memory Myth.
HANA did not run 10 to 1000x faster than a “regular database like Oracle.” Since this article was written, Oracle added a column-oriented store which Bloor Research covered in the article How Accurate with Bloor Research on Oracle In Memory?
The data points we have indicate that HANA runs slower than Oracle, DB2, or most likely SQL Server. Such a claim made by Appleby here in 2014 is quite ridiculous as SAP had only been developing HANA (based upon TREX and P*Time, possibly some IP from Sybase and according to Teradata, their technology) for a few years. Such a claim of, on average, 500x faster is an enormously bold claim, although very small compared to Bill McDermott’s claims of a speed increase of 100,000 times as we covered in How Accurate Was SAP About HANA Being 100,000x Faster Than Any Other Technology in the World?
Appleby gets another Golden Pinocchio Award for this false claim regarding HANA’s performance. The award is shared with SAP because Appleby would only make this claim with the approval of SAP.
HANA does not reduce complexity, but because its high overhead increases complexity. HANA is the highest maintenance database in the RDBMS category that we cover.
HANA is a Reinvention of “the” Database?
“SAP HANA is a “reinvention” of the database, based on 30 years of technology improvements, research and development. It allows the build of applications that are not possible on traditional RDBMS, and the renewal of existing applications like the SAP Business Suite.”
HANA is not a reinvention of the database. HANA is simply a multi-model database that can use column-oriented tables. SAP and Appleby should know as SAP acquired Sybase, which had Sybase IQ, which was a column-oriented design for more than a decade before SAP buying Sybase in 2010. The column-oriented design goes back to the 1970s and was developed at the same time as the row-oriented database.
Why Was HANA Developed?
SAP co-founder and Chairman Hasso Plattner believed that if a database could be built with a zero response time, that business applications would be written fundamentally differently – and IT landscapes could be simplified. The research institution at the Hasso Plattner Institution in Potsdam theorized that with modern computers and software design, this would be very nearly possible.
It’s difficult to say if Hasso ever believed this. He said he did, and he might have.
He has repeatedly corroborated this, but if he did believe it, then Hasso had a significant lack of knowledge on the subject. Secondly, zero-latency cannot be stated without consideration for the load. Is it zero latency at infinite load?
Hasso has repeatedly stated that zero-latency databases mean that coding is cut in half, as he does in the following video.
This video was deleted from YouTube by SAP
It is never explained why coding is reduced simply because or if the database becomes zero latency.
Hasso wins our Golden Pinocchio Award for his statement regarding HANA being zero latency (it isn’t) and that a zero-latency will reduce coding by 1/2 (it won’t).
Only SAP Could Develop This?
“SAP makes business applications and since it was clear that none of the incumbent software vendors like Oracle would write such a database and application platform, they needed to build their own. In addition, this would be the springboard for a complete renewal and simplifying of SAP’s applications to take them through the next 20 years.”
Oracle and IBM, and many other database vendors have far more database knowledge than did SAP. SAP picked up Sybase in 2010, but it now appears it could not leverage the knowledge from Sybase employees too much of a degree.
It is also unclear why none of the incumbent software vendors could write such a database? They have more appropriate resources to do so than does and would be incentivized to do so. Later IBM added dual-mode capabilities to their database in Feb 2014, Oracle did so in July of 2013, and Microsoft did so in June of 2016. The problem is that there is little benefit to a database with this design.
Notice the timeline below.
HANA does not simplify applications. We covered the fact that HANA does not produce a simplified data model in the article How Accurate Was SAP About S/4HANA and a Simplified Data Model?
Furthermore, HANA increases complexity because of its overhead.
John Appleby gets a second Golden Pinocchio Award because no other database vendor could have created a database with a column store. As it had already been done when his article was published, and he would have known this.
Is HANA Just a Database?
No. When SAP went to build HANA, they realized that the next generation of business applications would require a much more integrated approach than in the past.
SAP HANA contains – out of the box – the building blocks for entire enterprise applications. HANA can take care of the requirements that would be served by many layers in other application platforms, including transactional databases, reporting databases, integration layers, search, predictive, and web. All of this is served up working out the box, with a single installation.
HANA is just a database. We covered this in the article How to Deflect That You Were Wrong About HANA.
HANA does not support the next generation of business applications. This is entirely hyperbole. We analyzed this claim, which Hasso Plattner has repeatedly made in the article Is SAP S/4 HANA a New Application Architecture?
Why are the applications now more integrated than in the past? This is also not explained.
HANA does not contain building blocks for entire enterprise applications. HANA takes care of no layers in other applications platforms, and secondly, HANA is not an application platform. Good evidence of this is that since Appleby’s article was written and 2019, the number of applications written for HANA has been tiny.
This is entirely false, and it is misleading and deceptive in at least four different dimensions.
Appleby wins his third Golden Pinocchio award with this proposal about how HANA will bring in a new age in applications because HANA is a development platform. With that, it becomes the all-time leader for Golden Pinocchios in a single article. At least at the time, this article was written.
Where Does SAP HANA Come From?
SAP built SAP HANA from the ground up, including research from the Hasso Plattner Institute in Potsdam, the acquisition of the IP from the p*Time database, the TREX search engine, BWA in-memory appliance and MaxDB relational database. It has been extended with intellectual property from the Business Objects and Sybase acquisitions with products like Sybase IQ and Business Objects Data Federator.
Whilst HANA has a legacy and some code from other products, the bulk of the database and platform has been written from the ground up.
This is true.
Here, Appleby observes the importance of two acquisitions that were de-emphasized in the future by SAP and in the book The In-Memory Revolution, where Hasso recounts the story of the origin of HANA.
We covered this history and the fake backstory created by SAP and Hasso for HANA in Did Hasso Plattner and His Ph.D. Students Invent HANA?
Furthermore, Appleby credits IP from Sybase and Business Objects, which is rarely done in later years.
It is unclear what the term “ground up” really means. If a database uses components from (we count six products listed by Appleby), it is difficult to propose that the product was created from “the ground up.”
What Makes SAP HANA Fundamentally Different?
SAP HANA is different by design. It stores all data in-memory, in columnar format, and compressed. Because HANA is so fast, sums, indexes, materialized views, and aggregates are not required, and this can reduce the database footprint by 95%. Everything is calculated on-demand, on the fly, in main memory. This makes it possible for companies to run OLTP and analytics applications on the same instance at the same time, and to allow for any type of real-time, ad hoc queries, and analyses.
On top of this SAP built solutions to all the problems of columnar databases, like concurrency (HANA uses MVCC) and row-level insert and update performance (HANA uses various mechanisms like a delta store).
No. HANA does not store all data memory. SAP repeatedly made this statement, and it later turned out to not be true and is contradicted by SAP’s documentation on HANA. We covered this in How to Understand the In-Memory Myth.
The footprint is not reduced by 95%. SAP has claimed as high as 97.5% smaller footprint, but both of these numbers are false. Case studies from HANA projects around the globe have reported roughly a 30% lower footprint. SAP will respond when they are challenged on this p0int that the customer needs to perform extensive archiving, which can be achieved with any non-HANA database to reduce the footprint and is just a response for being caught in a lie. Secondly, the compression of column-oriented databases is well known, and it is nowhere close to 95%
This is no doubt becoming a bit tedious, but we have to make the awards for consistency. Appleby receives his fourth Golden Pinnochio Award for his claim regarding HANA’s reduced footprint. The article How to Understand S/4HANA and HANA Pricinwe covered g how SAP has tricked companies into buying less HANA than they need by proposing the smaller footprint, which is relevant for HANA as it is priced per GB.
Various Database Items Are Unique to HANA?
If this wasn’t enough SAP added a bunch of engines inside HANA to provide virtual OLAP functionality, data virtualization, text analysis, search, geospatial, graph (will be available soon), and web. It supports open standards like REST, JSON, ODBO, MDX, ODBC, and JDBC. There is as much functionality in there as a whole Oracle or IBM software stack, in one database.
Most databases offer several items like this. This is not at all unique to HANA. SAP’s proposal has as much functionality in HANA as Oracle is particularly outrageous as Oracle has a massive amount of database functionality.
Yes, here we go again. Appleby receives his fifth Golden Pinocchio Award for stating the HANA has more functionality than Oracle and the whole Oracle software stack. The Oracle database is decades old, so the idea that HANA would have already surpassed it after roughly four years of development (at the time Appleby’s article was written) is genuinely absurd.
What Kinds of Use Cases Does SAP HANA Support?
The first HANA deployments were all analytical use cases like Datamarts and Data Warehouses because the benefits are there right out the box. EDWs like SAP BW runs like lightning with a simple database swap.
With a transactional application like Finance or Supply Chain, most things run a little better from a simple database swap (SAP claim 50% faster for their own core finance). The real benefits come when logic from the applications are optimized and pushed down to the database level, from the simplification of the apps (SAP is building a simplified version of their Business Suite), or from ancillary benefits like real-time operational reporting, real-time supply chain management or real-time offer management.
Best of all, unlike the other database systems in the market, HANA supports all applications on the same instance of data at the same time. No more copying, transforming, and re-organizing data all over the enterprise to meet the needs of different applications. HANA perfectly serves the needs of all applications with one “system of record” instance.
SAP have provided a Use Case Repository that catalogues the various use cases for HANA.
It is true that HANA more naturally works with data warehouses, but there is another reason for this. HANA is a database that is optimized for analytics. However, BW does not run any faster than competing databases. Again, SAP has no technological superiority, so there is no reason for it to run faster.
Secondly, not all applications or even all SAP applications will run on one instance of data. Each application will continue to have its database instance. This concept has been a pipe dream of SAP and its proponents since HANA was introduced. And there is zero evidence that anything like this has occurred on HANA customers.
What SAP Applications Run on SAP HANA?
SAP CEO Bill McDermott said “HANA is attached to everything we have”.
Almost all the major SAP Applications now run on the SAP HANA platform. This includes the SAP Business Suite (ERP, CRM, PLM, SCM) and the SAP BW Data Warehouse.
The BI Suite including BusinessObjects Enterprise, Data Services, and SAP Lumira are all designed to run on the HANA platform.
There are a set of Applications Powered by SAP HANA including SAP Accelerated Trade Promotion Planning, SAP Collection Insight, SAP Convergent Pricing Simulation, SAP Customer Engagement Intelligence, SAP Demand Signal Management, SAP Assurance, and Compliance Software, SAP Liquidity Risk Management, SAP Operational Process Intelligence, and SAP Tax Declaration Framework for Brazil.
In addition, SAP runs much of its cloud portfolio on HANA, including the HANA Cloud Platform and SAP Business ByDesign. The Ariba and SuccessFactors apps are in the process of migration.
This shows how inaccurate Bill McDermott’s statements are. In 2014 HANA supported BW. S/4HANA was not introduced until Feb of 2015. HANA was certainly being prepared to support other applications, and it now supports more applications in 2019. However, the phrasing of “HANA is attached” is odd and deceptive and is essentially a way for McDermott to exaggerated what HANA supported. Attached is not a term used in IT. An item either supports another item, or it doesn’t.
Now on to Appleby’s statements.
- CRM and PLM were dead applications in 2014, so there is not enough coverage of either application in 2014 to verify this claim.
- SCM or APO (sometimes SAP refers to ECC as SCM) support would have been minimal. As an APO consultant, I never heard of an APO module being ported to HANA, although DP would be the natural choice as DP is nearly identical to the BW in the Data Workbench. And it is certainly possible a few DP instances were ported to HANA, but it was scarce.
We can’t verify each item that is part of the applications listed, but the applications listed were very rarely implemented with HANA. In later years after Appleby’s article was written, companies reached out to use on Trade Promotion Planning, where SAP argued that HANA was mandatory.
HANA could have been brought up in the HANA Cloud Platform (now SAP Cloud), but it rarely has been. ByDesign was eventually ported to HANA. But the port made no sense and was primarily for PR purposes. ByDesign is purchased by the SMB market, which cannot afford HANA. Today there are almost no users on ByDesign with HANA. Ariba is still not ported to HANA even in 2019, and SuccessFactors may or may not be partially ported. SAP is playing word games on this topic, as we covered in Did SAP Move SuccessFactors to HANA?
The Golden Pinocchio Awards are coming fast and furious at this point in the article. Appleby receives his sixth Pinocchio for his false statements that some SAP applications were already ported to HANA in 2014. These statements are genuinely entirely false.
What’s the Business Case for SAP HANA?
“We’ve built business cases for HANA deployments of all sizes and whilst they vary, there at a few common themes:
TCO Reduction. In many cases HANA has a lower TCO. It reduces hardware renewal costs, frees up valuable enterprise storage and mainframes, and requires much less maintenance
Complexity to simplicity. HANA simplifies landscapes by using the same copy of data for multiple applications. Our implementations have shown that adding additional applications to a HANA dataset are very fast and easy, delivering business benefits quickly.
Differentiation. HANA’s performance, advanced analytics (Predictive, Geospatial, Text analytics) and simplicity often mean a business process can be changed to be differentiating compared to competitors. Customer scenarios like loyalty management, personalized recommendations, and anything where speed or advanced analytics capabilities are differentiating are all candidates.
Risk Mitigation. Many customers know that in-memory technologies are changing the world and so want to put an application like SAP BW on HANA or LOB Datamarts as a first step, so they can react quickly for future business demands.”
Interestingly, Appleby does not show the cases that he “built” but shows the conclusions. We analyzed his TCO “case” in the article How Accurate Was John Appleby on HANA TCO for Cloud vs. On-Premises? And it is a TCO that excludes all maintenance costs and consulting costs. So we think we will skip taking Appleby’s word for TCO without seeing the actual document. And as we know, Appleby cannot sit down long enough to create a TCO. We know that will never happen.
All of the topics related to Appleby’s false claims about HANA performance have already been discussed.
HANA not only does not mitigate risk, but it is also the riskiest implementation of any of the databases it completes with, easily exceeding the risk of far more mature and tested databases like DB2 or Oracle, or SQL Server.
In memory, technologies are not changing the world presently and are not changing the world today, as we covered in the article How to Understand the In-Memory Myth.
Is SAP HANA a Database, Platform, Appliance, or Cloud?
“SAP HANA was designed to be a truly modern database platform, and as a result, the answer is all of the above. A modern database should be a database, platform, and be available on-premise or in the cloud.
SAP has a large installed-base of on-premise ERP customers, and the HANA platform supports their needs, especially the need for an enterprise-class database. Many of those customers are looking for an on-premise database to replace the traditional RDBMS.
The demanding needs of an in-memory database mean that SAP elected to sell SAP HANA as an appliance, and it comes pre-packaged by the major hardware vendors as a result.
However the future of business is moving into the cloud, and SAP HANA is available as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) with HANA Cloud Platform and Managed Cloud as a Service (McaaS) with secured HANA Enterprise Cloud and via 3rd party cloud vendors. Customers can also choose a Hybrid deployment model that combines on-premise and cloud. More details on this are available here.”
HANA is a database and not any of the other things Appleby states that it is. This was an original SAP marketing proposal for most of HANA’s existence. But SAP finally moved away from this and renamed the HANA Cloud Platform to SAP Cloud and HANA Studio to SAP Studio.
As we have covered earlier in this article, DB2 and Oracle had already added column orientated capabilities by this time, and Appleby knew this. However, Appleby is pretending that these additions had still not occurred.
HANA is not available and was not available as any of the things Appleby stated. HANA was available to be brought up in SAP Cloud. But few people ever did this for anything but testing, and even in 2019, HANA has minimal usage in the cloud, and it is primarily an on-premises database.
How Does SAP HANA Compare to Oracle or IBM?
“SAP HANA was designed to be a replacement to Oracle or IBM databases, either for net new installations or for existing customers. In most cases it is possible to move off those databases easily, and gain reporting performance benefits out of the box. Then it is possible to adapt the software to contain functions that were not possible in the past.
All three of the major RDBMS vendors have released in-memory add-ins to their databases in the last year. All of them support taking an additional copy of data in an in-memory cache, or in IBM’s case columnar tables. All of them provide improved performance for custom data-marts. But make no mistake; caching data has been around for a long time, while an in-memory database platform to run transactions and analytics together in the same instance is a new innovation.
Traditional database caching solutions are similar to the GM and Ford response to hybrid cars – take their existing technology and bolt new technology to it. SAP HANA is more akin to Tesla, who rebuilt the car from the ground up based on a new paradigm.
And so HANA’s capabilities from a business application perspective are 3 years ahead in technology from what others have.”
HANA was designed to replace DB2 and Oracle on SAP customers. This is true.
Finally, Appleby admits what he had not admitted up to this point, that IBM and Oracle had added a column store capability to their applications, but then states that DB2 and Oracle are not in memory but are caching data. Each database vendor will say their approach is the better approach, but the problem is that SAP won’t back-up their claims. It seems quite intent on dodging IBM and Oracle and SQL Server by not publishing any HANA benchmarking for anything but BW and not allowing other vendors to publish benchmarking for BW against HANA. Therefore, neither Appleby nor SAP has anything to back-up their claims.
Then Appleby follows up by stating that IBM and Oracle mostly just pasted column stores onto their databases. There is no reason to believe this is true, and IBM and Oracle did a better job of merging column and row-oriented capabilities — not that we even think this was a necessary item to add.
Finally, Appleby again states that HANA is three years ahead when this was also not true. We covered how incorrect this was when Gartner wrote something similar in the article How Gartner Got HANA So Wrong.
How is HANA licensed?
“SAP tried to keep licensing simple with HANA.
HANA is available in the Cloud as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and as an application platform (AaaS), and it is possible to buy all those options now, on a monthly basis, from the SAP Website.
For on-premise customers, HANA is licensed in one of two major ways:
First, is as a proportion of your Software Application value (SAV), just like you can license other databases from SAP. This could be for your whole estate, or for a specific product like BPC.
Second, is by the unit, which is 64GB of RAM. There are a few editions of HANA, depending on your need, that bundle other software and allow more, or less, restrictive usage. The pricing is tiered, depending on the number of units you buy, and accretive.
In all cases, HANA licensing includes a lot of functionality that you would pay extra for in other databases. For example, Dev, Test, HA, DR licensing are always included. And if you buy HANA Enterprise, you have access to all functionality at no additional cost – including Predictive Libraries, Spatial, Graph, OLAP, Integration, and Web. HANA contains a huge amount of functionality that would require 20-30 different SKUs from Oracle.
For those customers who need the base functionality of HANA but not the bells and whistles, there is now a HANA Base Edition, on which you can add other functionality as required, at a lower cost point.”
Licensing for HANA is hugely complicated and deceptive, as we covered in the article How to Understand S/4HANA and HANA Pricing.
HANA has similarly opaque pricing to other SAP products, but its sizing makes it complicated to price.
HANA did offer various items like Geospatial capabilities, but other databases also come with additional items, and the extras that came with HANA were typically not used. They did not have very much value. The statement about requiring 20-30 different SKUs from Oracle is not true. Furthermore, customers have complained to us that several components are not included in the pricing of HANA, that customers find out after they have made their HANA purchase that they also must buy.
How Big can an SAP HANA Database Grow? Does it Scale?
“With current hardware, SAP HANA can scale up to 6TB for a single system and can scale out to 112TB in a cluster, or more. There is no hard technical limit to the size of a HANA cluster. Higher configurations are tested and certified at customer sites.
We are currently working with 24TB single systems with SAP that we expect to see this year.
At Bluefin, we regularly work with 2-10TB of memory in a single HANA DB, and this is where we find most business cases make sense. Remember that a 10TB HANA appliance can store a vast amount of data (as much as 50-100TB from a traditional RDBMS due to HANA’s data compression capabilities); this could represent all the credit card transactions for a top 10 bank for 10 years or more.
In addition, we find that customers look to be more intelligent about how they tier data with an in-memory appliance. Once the HANA database grows past 2TB, it makes a lot of sense to use a cold store like Sybase IQ for slow-changing data.”
Customers can’t afford to scale HANA because it is excessive in cost. Therefore its scalability is far less critical than Appleby states, although the database footprints Appleby is quoting are inconsistent with our customer examples. Appleby is talking about a costly database and memory combination. HANA is still very inefficient in addressing the massive memory footprints it works with.
The last part of the quote contradicts SAP’s position of loading everything but archival data into memory.
Is SAP HANA a Row- or Column-Oriented Database?
“SAP HANA stores data for processing primarily in columnar format. But unlike other columnar databases, HANA’s columnar store was designed from the beginning to be efficient for all database operations (reads, writes, updates). In practice, 99% of the database tables in SAP ERP are columnar tables, including transactional and master data tables.
HANA can also store data in row format, but this is primarily used to store configuration information and queues – only scenarios for which the column store is specifically not suited. With HANA, data is stored once, in its most granular form, and aggregated on request. There is no hybrid row/column store, no duplication or replication of data between row and column stores – HANA stores the data in the column store only.”
No, and that is ridiculous. HANA is a mix of row and column-oriented tables, with a far higher percentage of row-oriented tables than 1%. If this were not the case, HANA would not support the ERP system, something it continues to have a problem doing in any case, as we covered in HANA as a Mismatch for S/4HANA and ERP.
Does SAP HANA Require Indexes or Aggregates?
“Every column in SAP HANA is stored as an index, and therefore HANA has no need for separate primary indexes. Secondary indexes with multiple columns are possible and used for OLTP scenarios like the Business Suite. HANA will also self-generate helper indexes to ensure that multi-column joins are efficient.
It is almost never necessary to aggregate data in HANA in advance because HANA calculates so quickly. HANA processes at 3bn scans/sec/core and 20m aggregations/sec/core which means 360bn scans/sec and 2.5bn aggregations/sec on a typical 120-core appliance. As a result, it is much more efficient to calculate the information you require on-demand.”
Indexes drop if a database stores data in columns…..but many of HANA’s tables are rows based, therefore SAP would greatly miss out from having no indexes. Instead, SAP has chosen to recalculate indexes for rows. The idea of recalculating aggregates that don’t change is just a wasteful design. However, what Appleby is saying here is roughly true. The false part is that Appleby is presenting this fragile design as if it is revolutionary. We covered aggregates in the article Is Hasso Plattner and SAP Correct About Database Aggregates?
Is SAP HANA a Big Data Platform?
“Yes, although HANA is best suited to high-value data because it keeps data mostly in-memory. When Big Data is low value (e.g. weblogs), HANA is very well suited as the store for high-value aggregated information and applications. This could be an organization’s hot data, e.g., 4 months of financial information for quarterly reporting. Other sources could be used to store additional data; for example, SAP IQ could store 13 months of financial data for annual reporting (warm data) and Hadoop could store >10 years of financial data for seasonal and long term trend analysis (cool data). Large volumes of data in both IQ and Hadoop can be analyzed in combination with data in HANA, so it is possible to process the data in HANA into full-text Google-style indexes without storing all the detail in HANA.”
No, it isn’t, and we can’t recount a single customer using HANA as a Big Data platform. Secondly, let us consider how illogical Appleby’s statement is. Why would you keep all Big Data in memory? Of course, you would not. Thirdly, HANA is priced per GB and is the most expensive database that we believe exists. Given this, why would customers want to pile data into it?
After Appleby’s article was written, SAP tried to tell customers that (as they weren’t going to load Big Data into HANA) that they should connect to Hadoop using Vora (which was a commercial version of Spark, which was open source). However, Vora is now dead, as we cover in the article How Accurate is SAP on Vora?
The upshot is that in 2019, HANA still has no footprint in the Big Data space.
Is SAP HANA Enterprise Ready?
“Yes. From its inception, HANA was intended to be a mission-critical database.
SAP HANA always stores a copy of data on disk for persistence, so if the power goes out, it will load data back into memory when power is restored (generally on-demand, but this is configurable). It stores logs so a very low Recovery Point Objective is possible.
HANA also has inbuilt capabilities to replicate the data to standby systems, so in a cluster, you can have High Availability and in any configuration you can have a cluster for Disaster Recovery and Fault Tolerance for business continuity. Disaster Recovery can be configured at the storage-level (depending on vendor) and also at the database level, which is called system replication.
It’s worth noting that most customers implement either HA or DR for HANA. It is exceptionally easy to set up (DR takes just a few clicks) and most customers that invest in HANA find business continuity is important to them.
Since its inception, HANA has had constant changes and instability, but Appleby never lets any of this on in this or any other quotation. In 2019, with HANA making little progress toward meeting its design objectives, SAP fired a large contingent of its HANA development, as we covered in the article SAP’s Layoffs and a Brightwork Warning on HANA.
HANA lags competing databases in HA, something that IBM and Oracle have many years of development supporting.
What Happens if the Power Goes Out?
“SAP HANA is a completely ACID-compliant database which is designed to have a low Recovery Point Objective (RPO). HANA writes savepoints to disk at frequent intervals, which contain a snapshot of what is in memory. In-between savepoints, HANA saves a log of each database change to a fast flash disk.
If the power goes out, HANA loads the last savepoint and then plays the logs back, to ensure consistency.”
This is true, but all databases in this category have been ACID compliant for decades. On several other occasions, SAP has made it sound as if only HANA is an ACID compliant database. As we covered in the article How Accurate is SAP on Only HANA Being an ACID Database?
What Hardware Does SAP HANA Run On?
“HANA appliances must be certified and come either as pre-built appliances from your vendor of choice or as a custom build using your storage and networks “Tailored Datacenter Integration” or TDI.
SAP maintain a list of certified hardware platforms which currently includes Cisco, Dell, Fujitsu, Hitachi, HP, Huawei, IBM (Lenovo), NEC and SGI, and is being extended all the time. Note that this list only contains the new “Ivy Bridge” appliances and not the older “Westmere” appliances.
The exact hardware and storage configuration varies depending on a vendor. Some use servers and other use blades, some used a SAN storage network whilst IBM uses local storage with the GPFS distributed file system. In our experience, all these variants work very well.
In addition you can buy HANA in the cloud from Amazon, SAP and various other outsource partners like T-Systems or EMC. In this case, you can either pay a monthly subscription fee including license, or use an existing Enterprise license “Bring Your Own License”.”
This is true. Many hardware vendors created HANA appliances.
However, this fact contains a fascinating story because Cisco, Dell, Fujitsu, Hitachi, HP, Huawei, Lenovo, NEC, and SGI all invested in making HANA appliances, in significant part based upon the exaggerated claims made by SAP. None of these companies did their homework and were only focused on repeating inaccuracies from SAP. None of these vendors have seen many benefits from investing in their HANA appliances because HANA grew far more slowly than anticipated.
Huawei bets big on HANA and lost.
As for the comment about HANA on AWS, etc… HANA is still predominantly an on-premises database.
Conclusion
This article scores a 1.5 out of 10 for accuracy. The article is correct on some basics, but the article is highly misleading, and Appleby winning six Golden Pinocchio Awards is a record for any article we have ever critiqued.