SAP HANA Reviews

I am currently using the latest version. But before that, before I jumped into the version, I used the initial version of HANA, as well. This initial version of HANA was not that great, it had a lot of bugs. But the latest version is very good. It's excellent.

I'm afraid that HANA is not a relational database, it's a column-level database just like Sybase IQ. Sybase is also an activity product, an SAP product. SAP bought Sybase in May 2010. So normal Sybase is RDBMS. Sybase has one more variant called Sybase IQ. That is not RDBMS, that is a column-level database. Normal Sybase is a whole-level database. That's a column-level database. So SAP HANA is based on this column-level architecture.

One more thing. The success of HANA primarily depends on the RAM and the storage. HANA became a success because the cost of the solar devices has fallen down substantially. I don't know about British Pounds, but in Indian Rupees, earlier in 2007, 2008, when I was working for Microsoft, one terabyte of a SAN device, used to cost around 22.5 LAK. I would say I would have had a 100,000. I think that's the nature. So one SAN device was costing 22 LAKs. The same SAN device, in 2013 and 2014, was costing around three LAKs. So the SAN device cost reduced by more than 200%.

Also, in parallel, the RAM cost also decreased, and the technology and the fastness of RAM increased. This impacted the primary condition for RDB and RDBMSs like Oracle, Sybase, SQL Server, and the like, that they need to support the foreign key relationship, where I have a few tables. For example, if I have five to six tables, suppose the first table is employment information. The second table is employee career details or his project, something like that.

Now, instead of populating the tables with the same information, the primary condition of RDBMS was to have a foreign key relationship between these two tables and reduce the redundancy. That was a primary condition, but in HANA, thanks to the cheap storage and high-speed RAM, I may not even bother to do a redundancy of data. I can combine all the tables and make a huge table. And as an entire table, whatever its size, I can pin the table in the RAM so that my access of information is not from the hard disk, but is directly from the memory, which is much, much, much faster. That is the beauty of HANA.

I'm still researching the features of HANA. In terms of memory, data access and data pitching, HANA has scored a victory, no doubt about that. But when I compare the non HANA architecture with SAP, ERP, the SAP ERP comes in two levels. SAP ECC, which is a non HANA based product, and SAP S/4HANA, which is a HANA-based product. If I compare these two, there are almost around 5,000 to 6,000 tables, which were merged together in HANA,  making it a robust architecture.

In earlier SAP we used to have fragmented, small-scale architecture. HANA is a robust architecture where one table itself is a behemoth quantity of many, many columns and a lot of redundant data. So my interest in HANA would be how SAP is catering to the demand of reducing the redundancy of data, and at the same time pinning the entire critical tables into the memory so that access to the data is faster. I am researching those factors.

I have roughly five years of experience in SAP HANA, because I started working on SAP ECC, on logistics and other components. After that, HANA became famous only in the years 2013 and 2014. Then I started pursuing HANA very, very actively. Right now, my journey is continuing and after five to six years I have a good amount of knowledge and experience on HANA.

It is stable.

SAP HANA is vertically and horizontally scalable.

Our banking system uses HANA primarily for our financial transactions. There are our SAP financials running on HANA. This HANA SAP was on the Oracle database. We have migrated it. It's very, very complex and took almost one year for us to prepare the plan and migrate to HANA finance. There are around 700 to 800 users using the database and they're not facing any problem. It's fantastic.

I would say I'm satisfied with technical support, buy it can be improved also. Improved in  terms of data warehousing, because HANA was introduced for data warehousing and because SAP wanted to catch the OLTP market. Now they have introduced many things to attract the OLTP customers, especially in banking and telecom sectors. That's okay. You have to keep your business interests also. HANA's architecture is the foundation of the language of data, warehousing, and design. For any project or product, if it's based on data warehousing, I would say HANA is the language for that because what data warehousing wants is a data warehousing database.

Primarily, it's not an OLDP, it's OLAP, online analytics processing. And where the data is not changed, the data doesn't change as frequently as a OLTB database. For that kind of environment, I think HANA needs a lot of improvement in terms of making it more columnar. It has to incorporate up level design a little bit harder, as well. 

You know MySQL database? Not Microsoft, MySQL. Microsoft is not SQL. M-Y-S-Q-L, has been bought by Oracle. Oracle bought MySQL, it acquired the MySQL company. If you look into the database, by default, MySQL engine is InnoDB. InnoDB is the default engine on MySQL. But, MySQL also gives you the flexibility of choosing your own engine. I don't want to know InnoDB, I have a huge Microsoft Excel file with around 10,000 rows, but I don't want to use InnoDB because I have to pay for that. To save those costs, at the time of starting MySQL engine, I can choose my type of data. Instead of InnoDB, I can choose Excel also. SAP HANA should give that kind of flexibility to its customers, making it more reachable to small SMEs, small and medium enterprises.

Now it is simple, because thanks to the cloud approach, it is giving a lot of flexibility to the customer, but if it wants to attack, hit the right target, acquiring the very, very small scale customer, who has around max 50 terabytes data or 100 terabyte data, a small scale company, small companies, that market should also be captured by SAP, not only the big companies. As the English saying goes, small things count. You can't ignore small things.

The initial setup is pretty straightforward. The only thing was there were a lot of parameters which had to be taken into consideration and any parameter at installation will be paid. But one good thing about SAP HANA is even if you miss a single parameter, you cannot agree to it for the steps. The further steps will tell you that, "you have missed this step. You first complete it, then you can come here." That kind of interlinking is there. So yes, SAP installation is pretty straightforward, and very easy and smooth.

I would recommend SAP HANA. No doubt I would definitely recommend it. But the thing is, if I adopt SAP HANA, my total cost of ownership in terms of having a functional consultant, as well as a HANA admin, would increase. I should first find a balance and analyze the data, "Do I really want to have HANA? What benefit will I have if I have HANA at my premises? And if I want to cut cost but also get the benefits of HANA, will the cloud option of HANA cater to my needs?" All those questions.

That is the company analysis I should do: what do they do differently? But many companies will be driven by the business needs, but at the same time some companies will also be driven by factors like the existing relationship with other vendors, like Oracle or SQL Server, and the kind of discounts they get when they buy that product. All those things will be there as driving factors. To answer your question, I would definitely recommend SAP HANA to anyone.

High availability and disaster recovery are very poor in HANA. High availability is measured on the barometer of RPO and RTO. RPO stands for recovery point objective, RTO stands for recovery time objective. The graph in which these two factors will be measured is from the five nines, the seven nines, or the three nines, that kind of factor. But it is a factor of my high availability. 99.9% of my database is available or 99.99999999%, giving a chance of 0.0001% for some kind of availability failure is because of natural disaster or some kind of electrical failures or something like that. So those are the factors you have to see for high availability.

My SAP HANA, technically, can withstand those calamities and recover itself from that disaster. That is called high availability. That high availability is there, but it is very, very, very minimal. If you're talking about high availability of HANA in actual high availability markets compared to Oracle and other RDBMS, HANA is a small child. If you remember when Microsoft SQL Server came into the RDBS market back in the year 1997, when they introduced the SQL 97, then they introduced the SQL 2000, SQL 2005. At that time, they introduced the high availability called Windows Cluster log shipping, mirroring the application.

At that time, in 2007 and 2008, Oracle introduced RAC, Real Application Clusters. Compared to the features of real application clusters, the Microsoft product was a small child. And Microsoft took that as a challenge and they improved and they improved. And in 2012 they introduced something called Always On. Always On is an improved version of high availability in SQL Server. HANA has to do that kind of stuff. HANA's high availability is immature.

On a scale of one to ten, I would rate SAP HANA an eight.

We primarily use SAP HANA for machine learning and deep learning.

The solution is very stable.

The solution can scale well.

We've had good experiences with technical support.

The performance is excellent.

We use SAP HANA in our projects but it's very expensive for our projects. We need a relational database in-memory that can handle these issues.

The solution is very expensive for us.

It's hard for us to find test users and sometimes we need them to connect to SAP from Iran, however, this is an issue due to the sanctions against the country.

We've been using the solution for more than six years.

We've found the solution to be very, very stable, especially when you compare it to other solutions.

The solution can scale quite well. If a company needs to expand it so that it fits their growing needs, they can do so easily. 

The technical support on offer is very good. We're quite satisfied with their level of service.

We tried GQ database but it's not a stable database. Sometimes the results weren't correct. SAP HANA is much more stable, which is why we use it, even though it's expensive. 

The solution is very pricey. We're looking into other options because of this.

We're looking at Oracle products as an option right now. We're also looking at MAT-V, a CPU-based database it's very fast, however, we do occasionally face issues with it.

We are a customer. We don't have a professional relationship with SAP.

SAP HANA is not just a memory database, it's a big platform. It's a very, very safe database. It's a very safe database and the performance is very, very good for an in-memory database. For example, sometimes we use Oracle databases 18C or 19C. The data is in the memory, however, when data is running, it's very slow, due to the fact that all data is in the memory and you need to and go to write disk. 

Sometimes when the data is very large, we might scale up our approach, and, in the scale-up approach, sometimes it is slow in HANA. That said, the scale-up approach is very, very good. SAP has got one problem. When you start the database, all data from the tool's memory takes a very long time. We've found that IBM's non-volatile memory is better than internal memory.  New users just need to be aware of that.

I'd rate the solution nine out of ten. The solution, overall, has fantastic performance, however, the cost makes it really hard for us to keep using it.

This is an in-memory database. It's designed to leverage the use of new generation, multi-threaded CPU architecture. We are service providers.

This is a very feature-rich solution with excellent performance. It's capable of integrating with most applications on the market. The stand-out feature of SAP HANA is that all data resides in memory. Processing is significantly faster, and the need and size of databases drop because there is no need to create and maintain tables that hold historical data.

As with all electrical products, this is an expensive solution and we'd like to see licensing costs reduced. 

We've been using this solution for 10 years. 

The solution is stable. 

The technical support is very knowledgeable and provide good service. 

The initial setup doesn't take more than a few hours. The on-premise version can be installed on public cloud and SAP now have their own version on private cloud. Installation is just a matter of preparing the operating system that has certain prerequisites, patches, and networking requirements that need to fill parameters.

The hardware to run a HANA database requires extremely big servers, makes this an expensive solution. 

There aren't many options available and this is a good product. I rate SAP HANA eight out of 10. 

We use SAP HANA for Master Data Governance.

The solution needs to work on its performance and make it faster.

I have been working with the solution for four years.

I am satisfied with the tool’s stability.

I would rate the solution’s scalability an eight out of ten. Our company has four users for the solution.

The solution’s tech support is good.

Positive

The setup is straightforward. The deployment took around six months to complete.

The tool’s subscription is yearly.

I would rate the overall solution a nine out of ten. You can use the solution if it meets your requirements.

The solution is mainly for in-memory computing and past data processing, both columns or databases. It's a very good database.

The solution offers very good in-memory computing.

We can save data very easily.

It is easy to set up. The implementation process is quite straightforward for us. 

The solution is stable.

There are limitations on tables. There is a two billion record limitation on a table. We'd like it if there could be more. If a table passes two billion records, SAP goes down.

The pricing is expensive. 

I've dealt with the solution since 2012. It's been about ten years or so. We've used it for around a decade now. 

It's very stable. We've been using it for almost ten years and haven't had any issues. There are no bugs or glitches. It doesn't crash or freeze. 

The solution is very straightforward and simple. It's not overly complex or difficult. 

It's quite a costly product. It is expensive. I'd rate it four out of five in terms of the level of expense. 

I'd rate the solution ten out of ten. It's one of the best databases in the world. 

We use this solution in conjunction with other prompted solutions primarily for real-time analytics.

The pricing on this product could be reduced, and the installation process could be more straightforward.

We have been using the solution as integrators for about five years.

The solution is stable.

I do not have any experience with customer service and support.

The initial setup is not straightforward. It took us between seven and 15 days for deployment. We have over ten people using this solution in our organization.

I am not sure about the licensing costs for this solution, but the feedback I have received is that it is expensive.

I rate this solution an eight out of ten. It is a good product, but it is expensive.

We use SAP HANA as the source of SAP or SAP S/4HANA. We don't have a BW system in between, so we assess data from SAP HANA DB, and we use HANA data models in the HANA database and consume those into SAP.

The feature I found most valuable in SAP HANA is modeling. I also like that the solution has good integration and you can integrate it with any system, even third-party systems.

Ease of use could be improved in SAP HANA. I like SAP because SAP solutions can be used by anyone, which means even laymen can start working on SAP tools, but in SAP HANA modeling, you'll need to know some other technologies and sequel scripting, and you need a separate skillset, so if you don't have the skillset, you won't be able to work on SAP HANA. Making SAP HANA low-code would make it even better.

I've been using SAP HANA for two years.

SAP HANA is a stable solution.

SAP HANA is a scalable solution.

I find the technical support for SAP HANA pretty good because if you have any issues, the team responds to you very quickly.

The initial setup for SAP HANA was straightforward. I don't have information on how long it took to deploy the solution because I wasn't in charge of the deployment.

I have no information on SAP HANA licensing costs.

More than three hundred people use SAP HANA within my organization.

At the moment, there's no plan to increase usage for SAP HANA.

My company does system patching every quarter, so there's no issue with maintaining the solution.

I would recommend SAP HANA to others who want to start using it.

My rating for the solution is eight out of ten.

SAP HANA's best features are its programmability and extensibility - you can size and shape the software however you need.

I've been using SAP HANA for four years.

SAP HANA is very stable.

SAP HANA is very scalable.

The initial setup was very, very complex, tedious, and costly and required someone with great expertise to complete it. The deployment took two years.

We used an external team.

I would recommend SAP HANA to others and rate it eight out of ten.

I have customers who work with SAP, and I carried out performance research for them, comparing the different parameters of SAP HANA. The solution is generally used for data warehousing. 

I think the in-memory database is excellent as it boosts performance. 

The product lacks some flexibility in its settings and configurations.

The solution is stable. 

The product is quite scalable.

I don't think the initial setup is too complex. Obviously it's not easy because SAP HANA is a complex system, so it's somewhere in the middle.

Licensing costs are quite expensive for the Ukraine but there is a range of different purchasing models so it's flexible in that sense. For a small enterprise, the costs might seem unreasonably high.

I rate this solution eight out of 10. 

The dashboard is great.

It's user-friendly so long as you use it frequently.

The product is stable.

You can scale the solution.

Technical support has been good.

Some production features are lacking. For example, we cannot see any dashboards in the production department. The generation of reports needs to be better. We have sales reports and yet no production reports.

It's a complex initial setup.

It can be an expensive solution.

I've used the solution for six years.

The stability is very, very good. There are no bugs or glitches. It doesn't crash or freeze. 

The scalability is very good. It's very capable.

I've used technical support in the past. They are good.

I did not use a different solution. I use what my company uses in order to get reports.

The initial setup is difficult and complex. It's very complex compared to SQL, for example.

The initial deployment took 15 days, however, nowadays, it takes one or two days. Mostly, I can complete it in one day.

I'm a business consultant. I do implementations for various parts of my customers' organizations.

The licensing is typically chared yearly. It was rather expensive.

We deploy the solution mostly on-premises and sometimes on the cloud. When we use the cloud, we usually use the AWS cloud. 

I'd warn new users that it might be difficult the initial time they use it if they are changing their ERP, however,t it'll be very helpful in the future if they're using it frequently.

I'd rate the entire product an eight out of ten. There are other well-known ERPs, such as Salesforce, and companies expect to have the same features. However, not everything may be on SAP, and that's something they need to work on.