SAP HANA Reviews

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. 

We use this solution for our CRM, and for our ERP, inventory, and supply chain management. It's basically used to run the majority of the company. We are customers of SAP HANA and I'm an account executive. 

SAP is great for what it does. There are likely better solutions out there but I'm not aware of them. It's a solution for big companies and in that sense it makes management of the databases much easier for higher-level people to know what's going on. 

The user interface and CRM need to be more user-friendly, it's abnormally painful. I'm a frontline user of the CRM, and it requires lots of clicks that are unnecessary. Less is more on the internet and quite often I'm clicking five, six, seven times to get where I need, and that's not effective. When an item in a certain category is not done properly, it can either lock up a system or not complete the process. We see it on a daily basis and we have to figure out a workaround to solve it. It's a technical issue that SAP's had since the beginning, and it hasn't yet been solved. With SAP everything has to be categorized. If it's not, it causes system issues and then you have to decipher the issue to try and undo it. It's an algorithm argument flaw. In the near future, I'd like to see better user interfaces and better connectors between modules.

I've been using this solution for about eight years. 

The solution is rock stable now. We have an SAP team and five or six people fixing day-to-day issues with up to 30 people working on it all the time. There is an additional team that implements new functionalities. 

It can scale infinitely. We have 12,000 users internationally and we use the product extensively. 

I have previously used Salesforce and I don't like it. It runs like a 1980s webpage in the current era.

The initial setup was painful and required a lot of work. Systems would go down all the time because there were initial errors with the SAP system. but once it was up and stabilized, things were good. It still has flaws but it's a good solution as a whole. They've implemented extra modules from SAP. If you don't implement it properly you'll feel the pain. It probably took around six months to solve all the issues because SAP is so big and so integrated and so integral, it can take a while to fix the problems. You can limp along until things are solved and find workarounds, but it takes a lot of effort. SAP helped us with the implementation. 

SAP is expensive but it's a good solution for what it does. You're going to get a $20 answer, for a $20 product. For all the functionality it offers, the cost is worth it.

It's important to plan and then plan again before implementing. If you don't plan properly, you will fail. The solution requires planning the implementation, making sure your company is the right size for the product. If you're an SMB, this might not be the right product for you. It might cost you more than you think. If you're enterprise size, you should look at getting into SAP, because it is the right solution. It's a solid product despite some minor issues - if SAP were to fix them it would raise the level of the solution. 

As a user, I rate the solution eight out of 10. 

We are end users of SAP HANA and I'm assistant vice president of our company. 

The solution's in-memory computing and the efficient response time are very good features. It's a good solution. 

Because SAP HANA is completely in-memory, it requires the use of bigger systems which have a higher amount of RAM. If the system does go down then coming back up is difficult and can take 30 to 40 minutes. It's a big drawback of the solution and one they ought to solve because the multiple downtimes are a problem.

I've been using this solution for six years. 

The solution is scalable so if you want to increase your node capabilities, it's very easy to scale out. You just have to add the node and it gets started.

The technical support people are very competent.

The initial setup is straightforward and there were no problems with deployment. 

I recommend this solution but running SAP HANA requires deep pockets - it's costly.

I rate this solution eight out of 10. 

We always make use of the latest version. 

We like that SAP HANA is a new technology. We also like that the product is both vertically and horizontally scalable, allowing us to do around 86 percent compression of documentation from 50 to seven terabytes.

In light of the hosting cost, we find this to be very interesting. We also like the warm and cold data in respect of the solution's technology. There is a real team involved. The customer can initially utilize SAP ECC on the HANA interface and then go on S/4HANA. From this point on, doing upgrades will be very easy and smooth and the risk management will be extremely light.

Since only some accommodation exists, there is a need to enquire of SAP about which environment would be good. While I know the HANA database on the Azure environment comprises a good solution, for example, it does not easily accommodate SAP. HANA is a new technology which only dates back to 2004 and we must give it adequate time before assessing its room for improvement. This is in contrast to DB2, which has been  around for 40 years or more years. Perhaps the flow will be improved. As of now, the technology is too new to properly comment on.   

The documentation is not an issue and, if anything, a surfeit of it is made available. This is actually one of SAP's stronger points.

Capabilities are also not at issue at present. When it comes to how EAP connects with SAP we are looking at a revolutionary paradigm. For now, we could not ask for there to be more features. This area is wonderful. We find the solution to be very helpful, safe, good and secure. Only with the passage of time will we be afforded a proper understanding of where the technology can be improved. 

This said, it would be nice to know when SAP plans to stop its maintenance of a previous version of SAP ECC ERP because, at this point, anyone utilizing SAP will have no choice but to go on S/4HANA Database. This will be contingent on when SAP will stop doing maintenance for the ECC version 6.0. 

We saw this with the 4.6 version ECC. Once SAP stopped its maintenance those with SAP were forced to go on the new version. 

We have been using SAP HANA for a couple of years. 

The solution is secure and stable. 

As the solution allows for document compression, I would consider it scalable. 

We have had occasion to make use of technical support, although its level varies according to the locale of SAP's global presence. 

While I was not personally involved in the installation, my engineers were. 

My deployment and maintenance team comprises around seven people, although I could not tell you which percentage of this is made up of managers, administrators and engineers. 

A monthly or yearly license must be purchased, although its utility will be based on the cost-benefit analysis that is reached by the individual customer. 

The solution is cloud based

I would recommend S/4HANA to other users. 

I rate SAP HANA as a nine out of ten. 

We are solution providers. We are a supply chain organization and we deploy and supply chain solutions for our customers.

We have a host of solutions and for each of our customers based on their environments. We customize their platform and deploy it.

SAP HANA is one of our database endpoints.

It's easy to use, and the Hana Studio is pretty good.

The main issue that we are facing is with the connectors. The JDBC connectors are very slow. We have been trying to connect with our SAP HANA database to our customers.

It's a simple Java driver and there is no proper documentation available anywhere with clear steps. We have to rely on several documents which creates confusion.

The initial setup could be simplified.

Also, we don't have to option to pull up the data from the object structure in SAP HANA. We can only pull up certain objects. It doesn't provide you with a comprehensive list.

There are limitations in connection with SAP HANA. There has to be a better or easier way to connect the databases with other platforms, maybe using Java code or other types of code. It would be very good to have the documentation on how to connect.

I would like to have flexible connecting mechanisms for connection with Java or different types of solutions to SAP HANA on cloud or non-cloud solutions.

They could come up with something similar to the SAP HANA Studio type of modeling.

I would also like to see the capabilities to extend the API. If they had specific APIs, it would be easy for us to connect.

My company has been using SAP HANA for ten years.

We are using the latest version.

It's a stable solution.

It's a scalable solution. Because it's an on-premise infrastructure and SAP this is the best support for most of our customers, scalability is taken care of.

We are an SAP house. We have more than 1,000 people who use this solution.

I have not interacted with the technical support. Other teams may have, but my involvement is more with the integration. 

The initial setup was a bit complex. We were told to download it from the marketplace, but when we tried, it didn't work. We may have been doing something wrong, but we did not have a clear understanding of how it should be done. We also had difficulties with the trial version, it was not working.

There are two options:

1. Download SAP HANA then import it
2. Go to the marketplace and download the connector

For testing purposes, if they could provide us with clear documentation, it would be very helpful.

Licensing is on a yearly basis.

We are using the paid version. We pay $200 on a monthly basis.

I am not an expert in HANA. I build the enterprise bus that integrates with SAP HANA as well as other systems. We have built our own integrated platforms.

The recommendation of this solution would depend on the use case and the requirements, and the price will be considered.

I would rate SAP HANA an eight out of ten.

We use it for database virtualization.

The main feature is that the processes are very flexible, they are able to be adapted to the business and their departments. The solution is very good and has covered all functional areas needed in this type of solution.

There could be better management for faster updates, last year there were some changes in India to the e-invoicing feature. During that time, there was a couple of updates that we had to wait until the release happened before we could do the implementation, this was a time we had to wait. They are pretty good at releasing updates but that time it was not the fastest.

I have been using the solution for a few months.

I have found the solution to be stable, it is very robust.

There is the ability to scale the solution by increasing capacity with no problem, it is very flexible. We have almost 34,000 users using the solution.

We had some issue with support in the past because they did not have enough availability. However, they have improved and now they are okay. 

Since we have been using the solution before we did not have any issues with the install. There were not any major complex operations. However, there were some challenges but we had the full documentation with us and it was not a problem. 

The price of the solution could be reduced, it is expensive. If they wanted to go into other industries and sectors the cost is on the higher side. They cannot go into each and every sector. If the cost was more reasonable, then it would be easy for them to enter more markets. This would be a disruptor in the industry because it would be used more often than other solutions, which would be good for the company.

I do recommend this solution but at the same time, it is expensive. The cost will not be able to be afforded by everyone such as medium and small scale businesses.

I rate SAP HANA an eight out of ten.

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.