Compared to Oracle, the licensing could be better.
SAP HANA is not strong like Oracle when it comes to finance. They are only strong with the logistic business project.
Download the SAP HANA Buyer's Guide including reviews and more. Updated: November 2022
SAP HANA, also known as SAP High-performance Analytics Appliance, is a multi-model database that stores data in its memory, allowing users to avoid disk storage. The product combines its robust database with services for creating applications. SAP HANA is faster than other database management systems (DBMS) because it stores data in column-based tables in main memory and brings online analytical processing (OLAP) and online transaction processing (OLTP) together.
The column-oriented in-memory database design allows users to run high-speed transactions alongside advanced analytics, all in a single system. This provides companies with the ability to process very large amounts of data with low latency and query data in an instant. By combining multiple data management capabilities, the solution simplifies IT, helps businesses with innovations, and facilitates digital transformation.
The solution is structured into five groups of capabilities, categorized as:
There are three more SAP products that work alongside SAP HANA and complete the experience for users together. SAP S/4HANA Cloud is a ready-to-run cloud enterprise resource planning (ERP). SAP BW/4HANA is a packaged data warehouse, based on SAP HANA, which allows users to consolidate data across the enterprise to get a consistent view of their data. Finally, SAP Cloud is a single database as a service (DBaaS) foundation for modern applications and analytics across all enterprise data. All three products can combine with SAP HANA to deliver to users an optimized experience regarding their data.
SAP HANA Features
Each architectural group of capabilities of SAP HANA has various features that users can benefit from. These include:
SAP HANA Benefits
SAP HANA provides many benefits for its users. These include:
Reviews from Real Users
According to a database consultant at a pharma/biotech company, SAP HANA is a very robust solution with good data access.
Bruno V., owner at LAVORO AUTOM INF E COM LTDA, likes SAP HANA because the product offers advanced features, helps reduce hours, and makes it easy to find what you need.
SAP HANA was previously known as SAP High-Performance Analytic Appliance, HANA.
Unilever, NHS 24, adidas Group, CHIO Aachen, Hamburg Port Authority (HPA), Bangkok Airways Public Company Limited
Compared to Oracle, the licensing could be better.
SAP HANA is not strong like Oracle when it comes to finance. They are only strong with the logistic business project.
I have around 12 years of experience implementing SAP HANA.
It is stable.
It depends on the enterprise, but the average enterprise has 20 employees. They buy two accounts to use the SAP S4HANA. It means that on average the enterprise will buy 20% to buy the license.
So far technical support is good. If we have any problem that a local partner cannot resolve for the customer, they will write to SAP and support will help fix the problem.
The initial setup is straightforward. It usually takes around eight months but it depends on a customer's requirements. We can spend a month or two customizing.
The SAP license fee is more expensive than other solutions like Oracle or Microsoft Dynamics.
I would rate SAP HANA a nine out of ten. Not a ten because of the price.
We have an ongoing cloud installation but mostly, we implement on-premises.
We use this solution for SAP Business One.
It's used mainly for analytic purposes, reporting, and the processing of large data.
What I like most are the dashboards and pervasive analytics. Those are the most useful to us.
The documentation can be improved in the future.
In the next release, I would like to see integration with smart devices.
I have been implementing SAP Hana for six years.
We are using the latest version.
It's a stable solution.
SAP HANA is scalable.
We are project-based. In each project, there are anywhere from 30 to 50 users.
We have not really received any technical support from SAP HANA.
I think that's also one thing that maybe SAP would be most helpful, especially if we encounter several errors during installation. We don't get to have many references or we don't get to ask the technical guys of SAP HANA.
Previously we were using MySQL, but due to the fast performance of SAP HANA, we switched approximately three years ago.
In the newer versions, the initial setup is mostly straightforward. However, the older version was more complex. We had several issues with installing.
The installation usually takes approximately four hours.
There are two admins at the most to maintain this solution.
We definitely plan to keep implementing this product in the future and I can recommend it.
I would rate this solution a seven out of ten.
We use SAP HANA as our primary database for our enterprise business. The product is centrally hosted where all our business departments access the product through its sister product SAP ERP.
The product hosts data for the deployed modules namely, Finance and Control (FICO), Materials Management (MM), Plant Maintenance (PM), Production Planning (PP), Quality Management (QM), Human Capital Management (HCM), and Sales and Distribution (SD).
It also hosts the business warehouse (BW)/BI environment.
The performance in terms of processing time is unmatched due to the in-memory processing capability.
The administration of the many records that were previously distributed in different systems into a central location has been made easier. All that information has been availed central from multi-locations without the requirement for manipulation using worksheets, as was the case before.
The database is also running our business warehouse and business intelligence environment, where insightful reports are generated for business management.
Security and performance are the two most valuable features. Our processing time came down to less than two hours from more than ten hours in the legacy system. We use the product to process our small-scale grower payments at the end of the month and whose daily tea deliveries records are in hundreds of thousands.
The audit trails in the HANA product are so robust that one can trace back to the tiny details of what happened at a particular time, who did it, and the time it was done. This makes auditing of both the transactions and performance of the product possible.
The product is very demanding on memory requirements. This is a result of it being an in-memory processing product. The choice of the hardware must be done carefully because when subject to other hardware, it gets slow and just crawls. Memory on the other hand is not cheap because you have to buy it from a third-party.
The cost of the database is not cheap either, as you have to pay for the runtime for any licenses that you purchase, and that comes each year. Now that is punitive with increasing license requirement.
We have been using SAP HANA for six years.
This is a very stable product.
SAP HANA is very scalable.
The customer service is excellent, whereas the technical support is not among the best but we managed.
We used another solution before this one and we switched due to data growth and the need for predictive management.
The initial setup is complex.
SAP itself assisted us with deployment.
Setup and licensing require planning and proper budgeting, as it is not cheap.
We evaluated products by Microsoft and Oracle.
We have a lot of clients from different industries, such as factories and hospitals. We have deployed it on the cloud as well as on-premises for various clients.
All features are valuable.
They can improve their technology for the CRM subsystem. There are other products that are better and more effective for the CRM subsystem.
Its price could be better. It is expensive.
I have been using SAP HANA for several years. I have been using it since they launched the HANA database.
It is stable.
It is scalable. We have installed SAP HANA for around 15,000 users.
I would say they are average. Sometimes, they are not able to answer our questions, or their answers come very late after we have already resolved the issue. They should be more familiar with the product.
We used our own product, which we developed on our own. After engaging SAP, we substituted our own product with SAP HANA.
The initial setup was straightforward.
It is expensive.
I would recommend this solution. We plan to continue using this solution for our clients.
I would rate SAP HANA an eight out of ten.
We are system implementers and we have many clients who use SAP HANA. Some examples of our customers are factories, hospitals, and other businesses.
This is a feature-rich product and I like all of them.
The price of this product should be reduced.
Technical support should be more customer-friendly.
We would like to see better CRM functionality in the future because there are other products that are better and more effective.
I have been using SAP HANA since they first launched the HANA database, several years ago.
This is a stable solution.
SAP HANA is scalable and we have a lot of clients who use this product. We have installed it for perhaps 15,000 users, and plan to increase our client base.
The technical support from SAP is medium. I'm not fully satisfied and it could be improved.
It isn't always a matter of them needing to being faster. Sometimes they cannot answer our questions, whereas other times, the answers come so late that we have already solved the problem.
We used to implement our own product that we had developed. However, after engaging with SAP, we substituted our own product for SAP HANA.
The initial setup was straightforward.
We have a team of about 200 consultants who implement, deploy, and maintain solutions such as this one.
SAP HANA is an expensive product.
SAP HANA is a good product and I can recommend it.
I would rate this solution an eight out of ten.
What is good about SAP HANA is its simplicity and its flexibility.
Its in-memory capabilities are good, which is why many companies still use it.
SAP HANA is a very proprietary tool and there's not as much support available for it as there is for an SQL Server (which is more popular).
It requires some internal SAP knowledge to work with the tool and it's a completely graphical modeling kind of a system. You can't come in cold with no knowledge or understanding of the solution and think you can jump in and start working.
You have to work with the very few tools that are given to you. It could probably increase its flexibility and there could be more components added, which would make it more versatile. They could improve the solution by adding more components and by making it more feature-rich and including typical features that other more popular tools have.
There needs to be better support from the SAP support team. There needs to be more support for other programming languages like high-level C++, Java, or Python. That could be another improvement.
HANA needs more integration with open-source tools, and with general reporting and analytics tools that are out there on the market. Once again, more integration on so many levels would be amazing. It's very SAP-centric and very proprietary right now. There are ways to connect SAP HANA with many tools already, however, in particular with open-source tools, if there could be even more integration, that would be helpful.
There needs to be more data transformation and more ELT features that can be implemented in the view.
While I'm not exactly sure how long the company itself has used the solution, I've been dealing with it for four years at this point. It's been a while.
In terms of stability, I can't comment much. It depends on the underlying system and infrastructure, and it has the same kind of stability as any other on-premise solution. It doesn't have any cloud features such as multiple replication and multiple locations, et cetera. In that sense, it has the same stability as any other on-premise solution and does not guarantee any SLA.
In terms of scalability, it's quite scalable. We've used it for production solutions very often and from any number of users. Generally, there are a few hundred users or so. I have not really worked on an implementation that uses thousands of users or anything that big, so I can't really comment on massive scaling. However, if it's for enterprise applications that have a few hundred internal users, it's good.
The community support needs to be better. I haven't been impressed with it. In general, it just needs better support.
I have only worked on SAP and I haven't worked on other solutions.
I don't have information on the pricing, as that is an SAP and corporate-level agreement, which is not really known by all the in-house teams. I'm not really aware of the pricing. On the internet, I couldn't find much information about the cost of SAP HANA. I have heard that it is an expensive option. Being an enterprise-level solution, however, I don't have exact numbers.
I'm not really part of the decision making team or the architecture team. I do not know if my organization has a business relationship with SAP or not.
I'd rate the solution five out of ten.
In the case of enterprise projects, I've heard that SAP HANA is used very widely. I would say, in general, it would be good to explore other alternatives, and not just go with HANA. It would be good to explore big data alternatives that are out there. They might be a better fit. Databricks these days seems to be quite popular. It might be an interesting alternative for some organizations. Depending on the use case, I'd recommend that other alternatives should be considered. If it's a reporting solution that people are building, which is using a lot of SAP internal data, then SAP HANA is a good option. Otherwise, other alternatives are out there.
We primarily use the solution as a kind-of database for our workloads.
The solution is extremely stable. That's the most important aspect of the solution, for our organization. There is no downtime, and the performance is very good.
You can upgrade and upscale without any downtime as well. It's excellent.
The HANA appliance is certified and can be seamlessly implemented based on the HANA platform dependency. Everything works. On a daily basis, it runs extremely well.
The pricing is pretty good.
I don't think that there is a feature that is lacking. It's quite good as a solution and we're pretty happy with most aspects of the product.
I'd just like to see some more improvements done on the training, both on the functional training and technical training sides as a part of the complete solution.
Currently, training is assumed to be a separate part of the solution. You have to purchase it separately. This should be a part of the solution's mandatory requirements. Most of the time, people fail to purchase training, and they fall back on it afterward, during implementation, as they realize how crucial it is.
I've been using the solution for three years at this point. It's been a while.
The solution is very, very stable. It's reliable and its performance is excellent. There aren't bugs or glitches. It doesn't crash or freeze. It runs all the time without issues.
You can easily scale this solution. In fact, you can scale it and upgrade it without ever experiencing any downtime. It's excellent in that sense. If an organization needs to expand it, they can do so with no issues whatsoever.
We have a dedicated support person from Cisco that assists us if we need any help. We also have a service level agreement. We're quite satisfied with the level of service. They are professional, knowledgeable, and responsive.
We had specialists that handled the implementation. We didn't handle it ourselves. It would be difficult to comment on the level of difficulty since we didn't manage the setup in-house.
We had specialists from OEM that took care of everything for us. We also had consultants from Cisco. They gave us initial assemblers until everything was scaled properly.
We're pretty happy with the pricing. It's not overly expensive.
We're just a customer. We don't have a business relationship with SAP HANA.
I'd rate the solution around nine out of ten. It's practically perfect.
It's a great solution and I would recommend it.
There's some configuration that needs to happen at the outset, however, after that, there isn't much dependency on the technical side, which makes it very user-friendly for companies.
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.
The memory capabilities are great.
The performance is very, very good. It's one of the best aspects of the solution.
I've used Oracle for ten years, and yet, I find SAP better than Oracle. Oracle is more cost-based.
Oracle tends to have better features than SAP HANA. They should work to add the kinds of features clients expect from Oracle.
With Oracle, you can install their cloud and that enables you to see more of the database and multiple accounts. This is better than what SAP has on offer.
SAP could really work on its monitoring capabilities.
There's data aging that needs to be dealt with on the solution. It's not ideal. You might have a lot of raw data and aging can really affect it.
It would be help if the solution had a graph database. They're lacking that right now.
There's an issue in the partition. When you record more than two million records, partitioning does not work well. In Oracle it's easy. SAP must resolve this issue in order to be more competitive with Oracle.
I've been using the solution for about five years at this point. It's been about half a decade.
The scalability of the solution is pretty good. We don't have any problems in that area.
We've dealt with technical support in the past. It wasn't that good. Sometimes the information we received from them wasn't accurate. It's a difficult solution. I would say, to be fair, that their support is better than Oracle's.
In the case of Oracle, I had an issue once with Oracle GoldenGate. It took two weeks to resolve the issue. That's far too long. SAP is much more responsive. It's never taken two weeks to resolve anything.
We also used Oracle. We find SAP to be very fast. It's much faster than Oracle.
The initial setup was five years ago, so it's been a while. However, I do recall it being straightforward. We typically install a version on Linux. While it can be difficult, at the moment, it's pretty good. Things have changed a bit, and they've improved the setup a bit. It's not really that unsimilar to Microsoft's SQL server.
We're just a customer. We don't have a business relationship with SAP.
We're using the latest version of the solution.
We use an on-premises version and e have a private cloud in our company.
I'd recommend the solution. If you have, for example, a huge project that's kind of a unique, scalable database I recommend SAP HANA for it. It's easy to use and handles more RAM.
I'd rate the solution nine out of ten.
We're writing SQL queries for the verification process, and we're using SAP master tables for tables. We write huge queries for processing data.
The feature that I like the most is that we can transport the data to our web data application.
SAP HANA's performance is really perfect. We're working on big data, and SAP HANA is really working on high performance. We are happy working with it.
The user experience should be better. Its user interface is not good. I also don't like the transition concept.
I have been working in the SAP HANA environment for around two years.
We have experienced some glitches, and we are solving them with the help of our technical team.
It is a bit complex, but if you follow the instructions, it can be installed. The initial setup could be easier.
SAP HANA is expensive, which isn't a problem for us because it is processing the data so fast.
It is an SAP tool. Therefore, replicating the data from SAP to HANA is easy because it provides a high-performance area without overworking the SAP site. Working with big data is really nice in the SAP HANA database.
I would rate SAP HANA a seven out of ten. I took some points because of the pricing, user experience, and stability issues.
The user interface is very good. You can do any kind of reporting analytics from the platform.
The solution needs to improve its integration capabilities.
There could be some debugging techniques when the solution goes wrong or if some of the data is wrong.
The solution needs to work a little bit faster.
When you do a report on a non-SAP platform, you face some compatibility problems.
I've been using the solution for seven years.
HANA is currently a stable solution after many upgrades. It's been seven years in the market, so it's fairly mature. It's been working fine for many clients here.
Scalability is good. That's the reason many customers like it. Initially, it was not so good and there were some problems with the software when it came to the market. Now it's fool proof in terms of running solutions for many clients. We typically handle enterprise-level businesses, so companies that have 500+ employees.
In terms of technical support, it depends on what partnership you have with SAP. If you're a platinum partner or a gold partner, for example, you can expect a certain level of support.
The initial setup is straightforward. It's not too difficult to install if you are experienced with the solution.
We use the on-premises deployment model.
I'd recommend the solution. It's a very good product to learn and it's easy to use once you have an understanding of the technology. It's a nice product to work on.
I'd rate it eight out of ten.
The deployment model used was on-premises.
The most valuable feature is the unique style of this solution, on the performance side and then the data.
The data storage requirement is reduced from the original database to the HANA database.
Previously the data takes 100% storage space, but when moved to HANA, the data was 70% to 75%. The data compression is very high.
If you are using SAP applications, HANA is suitable.
I think that the pricing is high and it needs improvement.
In the next release, they could separate the modules from the costing of the database. If they bundle it together with a new affordable price then customers will be ready to purchase it.
They need an affordable price to achieve most of the minimum requirement assets.
This solution is stable.
They keep upgrading to new versions and keep adding new add-ons to this solution. It is helpful to the customers who are ready to run HANA.
The initial setup is not complex to install. Anyone with Windows or a Mac would know the process.
The pricing is expensive and it should be broken into two products.
People who are technical will accept the cost, but financially they will assess whether this solution will bring them revenue or not. People often ask, how will I profit when the cost is so high?
If you value a good product and can afford it, then add it to the business.
I would rate this solution an eight out of ten.
The speed of the solution, and the clarity offered are the solution's most valuable features.
The functionality is of the solution is very good.
The challenge right now is all databases are on S4 HANA architecture. You're running it for HANA, but not all the functionalities are available. If they can speed up getting all the databases on S4 HANA that would help.
The production seems to be stable, but outside of that some of the QA doesn't show as 100% stable. Currently, we're still assessing whether it's a network issue or it's a server problem. That said, it is pretty stable in production.
We have been in touch with technical support, but not for any major issues. I'd rate them seven out of ten.
The initial setup was a bit complex for us because we had a lot of other add-on solutions, like the Open Expanding Invoice Management solution. We had to upgrade it because the current version we had, 10.5, wasn't compatible with the upgraded S4 HANA.
I found the process complex because I had to re-implement all open expanding invoice management. We were using ICC and ICC also wasn't compatible either. We had to then switch over to BCC, which I had to re-implement and reconfigure the whole system again.
I'd rate the solution eight out of ten.
Right now, they say the solution is S4 HANA, but, not everything on there is S4 HANA, so it is kind of confusing that they say that they're moving us to S4 HANA, but we are not really on it. Because of that, we're not 100% happy. Once everything is properly moved over, it might be better.
I am the technical consultant at our firm and our primary use case of the solution is to manage our databases.
We don't really use the solution for code integration purposes but one feature I find very valuable, is the response time of the application on the database memory.
If the developers were to enhance or improve the application logic while processing the transactions, that would be great. For example, if you are accessing a transection, it takes about 10 seconds. So the logic behind the transection usually is part of the development part and a product code is not from the database.
The solution is currently very stable. We have about 80,000 people in our company's underlying database.
The technical support is good and they were very helpful.
The initial setup was complex and we had to contact the vendor a couple of times. And for the licensing part we've also had a couple of issues. We did the deployment ourselves, as a team.
On a scale from one to ten, I rate this solution an eight. In the future I would like to see the response time of the application being much faster than it currently is. The response time on a task should be faster so that we don't have to wait for 10 seconds each time.
We're using the on-premises deployment model.
This solution did improve my organization. We had some changes to better our organization, especially in the procurement process. Here in the Middle East, we have some processes that are not according to standard business processes. Through our change management processes, we had to re-change or resend our process to adapt it with SAP.
Integration is the most valuable feature we use SAP HANA for.
FI, or the financial module of SAP, has room for improvement. It has to have some better localization for the Middle East, especially in regards to taxes and the letter of a credit cycle. I would like to see better localization from the HCM.
We are satisfied with the solution's stability.
This solution is fine to scale. It converted great.
We have a technical support contract with a subcontractor from SAP in the from of an SLA, a service-level agreement, divided into four categories. First, second, third, and fourth lines of support. We are satisfied with the technical support.
It was a little bit complex in the beginning, but after gaining experience training through business structures, now it is straightforward for us. Especially, as we are building our internal team now, it is becoming easier and easier.
It took us eight months to deploy because we are running five modules. In some cases, it may take even longer than that.
The biggest lesson learned was that we started late. We all should have started earlier.
Out of ten, I would rate this solution as eleven.
We are using on-premises, but I have also done some research in the last six months trying to go towards the cloud. We want to upgrade it because we also did the same thing with another company we are working with which is using the Sage X3 Cloud. We started with Sage Evolution, but now we are also moving to Save X3 Cloud.
It helped us because some of the people who are busy supporting us are not local. We opened SAP HANA more for the management. We even got some tenders that we were able to submit documents online and sending it to our servers. The key value is that we can get more tenders because of the lower cost while giving a better product or service. This is possible only because of our use of SAP HANA.
The most value for us was in terms of using it to issue tenders online. We host our server, but it is open to the public, so clients who want to buy those tenders were able to go online, put their tender documents up, and we could evaluate them using SAP. We were basically able to do pre-qualifications using SAP. After that, we could send notifications to people who qualified and go through the non-qualified people using SAP. That feature is very effective in terms of supplier relationship management. We can issue tenders and people put their big documents through SAP HANA, which helps with communication and gives them notifications.
One is the menu. There is a part of the menu where the button should be "reject." The interface is a little bit hard to customize. You almost have to consult the SAP original developer to change it. Now we have to consult SAP just to do some interface changes. You expect it to be easy to get into the menu, but you can't. Instead of changing the console you wanted to reject it, for example, if a tender that does not meet a specific qualification. Basically, the customization of the interface needs to be more friendly.
I think we are also going towards mobile technology, so I would like to see the integration of a mobile app.
It's quite stable. There haven't been many cases of bugs, crashing, or freezing. It has been quite stable.
Its scalability is good, in terms of meeting our needs.
I think technical support is okay. They should be more focused on updating the knowledge transfer for people who have experience with SAP in general but need to transition their knowledge to the local client. This part is a little bit challenging.
We used another solution, but it was more of a client-oriented system, where you get developers to make and customize them for you. It's more local or in-house than regular IT systems. When you only have one company developer to make some products for you and he is the only one who can support you, it's a little bit of a challenge. With SAP HANA, if you get stuck somewhere you can call any other SAP HANA partner.
It was easy for us to set up, because we had that QA code, in terms of the system analysis and system requirements. Once we got the system requirements, we were able to connect to the hardware and software. We could make sure before we did the implementation that we had the right environment.
The main lesson is the importance of ERP capability, stability, and speed. The other lesson is about knowledge transfer because that is how you learn.
At the end of the day, I like it because it's one of the affordable ERP systems. I would rate is as eight of ten.
We use a hybrid deployment model for this solution. Our primary use case of SAP HANA is for business intelligence.
In terms of improvement, the speed is not as good as we thought it would be. That is why we are trying different solutions that will be built with different technologies.
Also, the cost is an issue. SAP HANA is extremely expensive, especially in the cloud. Right now that has changed because you can actually purchase modules of that size but, for example, two years ago when we had a database of 10 terabytes, then we would have to purchase the hardware on our own and then put it in the cloud foreign location of the vendor. It runs on our own software that we have purchased. It's just placed in the same location as the rest of the cloud of the vendor.
They should improve the speed and scalability
If you want to scale the entire size of the database then that is difficult and has an impact on the speed. If you want to scale with new processes and new reports, that's fairly easy.
We have more than 1,000 users using this solution.
The initial setup, from what I recall, was complex. I remember we had a lot of issues to tackle when we set this up and with upgrading.
We used a partner for the implementation. We had mixed feelings about our experience with them. It wasn't bad. It wasn't exceptionally good.
We're moving away from HANA and currently implementing a new solution which is not yet productive. Only the first part of it has become productive and I can't really say whether it's better or worse. During testing, we can see it's faster than HANA and provides the same data which is promising. I would restrain myself from providing any recommendations because that might give a false impression.
I would not recommend SAP HANA because it has some issues with the speed and scalability of the size. It's also extremely expensive. It's probably the most expensive solution of all and you could expect more from it. On the other hand, we don't have much experience with other solutions yet, so it will be very difficult to provide a real recommendation.
I would rate it a seven out of ten.
We use this solution for database storage.
I am an SAP developer and consultant at my company. I examine the client's system and propose solutions that will ease their processes or make them faster. This involves programming, as well as other kinds of development.
We are using the on-premise deployment model.
This solution is very fast.
The backup solution and time machine should be more accurate, reliable, and comfortable to use. The inclusion of a well-performing Time Machine is vital.
If the interface were more comfortable and easy to use then it would be excellent. Sometimes, an incorrect request is taken to production and it will corruption everything in the production database.
When there are a large number of records to process in a transaction, it is not any faster than Oracle.
This solution is very stable. We have been using it for one year and there have been no problems with the database.
I was not involved in the setup of this solution. I only installed SAP HANA Express on my laptop, which was easy. The full version requires professional knowledge. It's not something you can install, like Microsoft Office, on any laptop.
We hired a consulting firm in Turkey to set up our solution. The two machines were configured by SAP Turkey.
I have more than nineteen years of experience with the Oracle database, from version 7.2 through to RAC. I know the administration, as well as backup and recovery very well.
There are not many differences between Oracle and HANA. As an example, for transactional purposes, it is very similar to Oracle.
We switched to HANA from Oracle because SAP systems are moving entirely to the HANA platform. There will be no support for SAP using Oracle.
We do not use the HANA features, for example, embedded scripts. This is something that we may use in the future.
My advice to anybody looking to implement a relational database is to use Oracle, rather than HANA. HANA consultants are very rare and therefore costly. My testing has also shown that Oracle in memory is much faster than HANA.
This is a good solution, but the vendor inaccurately promises that the database is ten-thousand times faster than Oracle.
I would rate this solution a seven out of ten.
It is a memory database that has all the content of the database. Once the database is turned on, it is loaded in the server RAM. It has a very huge bandwidth and data transfer. Once you try to do any queries against this database you can get the result very fast. You can get real-time output or results. This aspect is very helpful to me.
From the deployment-side, I don't have any issues with the solution and haven't heard of any problems from clients.
The solution is very expensive, however. The pricing depends on the number of users and many other factors that affect licensing.
It is very stable. I use the Linux operating system and find it to be quite stable.
The solution is scalable. You have horizontal or vertical capabilities. You can upgrade the server itself in case the memory is at capacity. The resources of one server are not enough because it's big. According to your requirements, you can expand by adding more servers into one big cluster.
I don't go through the official support team from SAP, but most of the time I use the website to find the answers I need. It's very detailed and most of the problems that I've faced in the past while handling the implementations I can find on the website or on the internet.
Before using SAP HANA, we used other SAP products.
The initial setup is straightforward. For one system, the stand-down system, it will take about four to five days for implementation from scratch. I often handle implementation, so for me, it's straightforward because I have some experience in this area. You do need a skilled team. You have to understand many areas if you want to deploy it yourself. You have to have experience with the storage, the network, with operating systems, etc.
I know SAP itself recommends that you have to have a certificate or a certified person that can deploy SAP HANA.
We are an integrator, so we handle the installation for clients.
The SAP portfolio is huge. It covers all industries and fields. It is very wide horizontally or vertically. It has modules for all industries, fields, and for all departments: accounts, HR, production, they have a solution for each industry and for each department in any organization.
There are some applications that are very sensitive to the delay or the latency so for these types of applications I would recommend SAP HANA. However, if these are not concerns, there may be other database technologies that would be more cost-effective than HANA.
I would rate this solution eight out of ten.
Provides us with predictive capabilities for asset maintenance and real-time forecasts.
Real-time database, near zero downtime for production business.
Graphical programming without coding.
System recovery in version 1.0 failed due to corrupt log files. Version 2.0 is stable now.
Should have scalibity from terabytes to petabytes/zetabytes/yotabytes for both scale-up and scale-out, multi-tenancy approach.
Gradual deployment from straightforward to complex, on-premise and then to cloud platform.
Set up a consortium of consulting partners and hardware vendors to define your tech. Landscape TCO (total cost of ownership) and then approach the OEM for pricing (on-premise or on cloud or a hybrid model).
Check if you can bring your own licenses for some of the existing application licenses on the new platform, to reduce TCO.
Product was the first of its kind for us. However, we later evaluated other products: Oracle Exadata, Exalytics, Teradata, Hadoop, MongoDB.
By now most of us are well aware of the data explosion, that businesses are creating more data than they can effectively manage. This is not a new problem. Throughout history societies have always made efforts to create repositories to organize, analyze and store documents (recorded knowledge). Some of these ancient repositories still exist today in the form of “brick and mortar” libraries. But just like anything else in a consumer’s market, demand (Time-To-Solution) eventually becomes greater than the supply (Information Available/Accessible).
The global economy is currently undergoing a fundamental transformation. Market dynamics and business rules are changing at an ever increasing speed. Those responsible for keeping the company on track for the future have a massive need for high-quality data--both from inside and outside the company. Technology decision makers are facing the challenge of having to create infrastructures that leverage speed, scale and availability.
Data technology must assist in the removal of silos and support collaboration and the sharing of expertise across the company and with business partners. Successful companies will need access not only to their own "Data repository" but to data from various heterogeneous sources. Today, finding mission-critical data or even being aware of all potential sources is more a question of luck and intuition than anything else.
How important is your data to your organization? How does your organization use its data? How do they access and interact with it? Are the decisions being made from data, innovative or disruptive in nature? What’s the value and impact?
According to a Forbes article written by Caroline Howard, “People are sometimes confused about the difference between innovation and disruption. It’s not exactly black and white, but there are real distinctions, and it’s not just splitting hairs. Think of it this way: Disruptors are innovators, but not all innovators are disruptors — in the same way that a square is a rectangle but not all rectangles are squares”.
Database accessibility is critical for rapid but sensible, innovative and disruptive decision making. A business database management system must be able to processes both transactional workloads and analytical workloads fully in-memory. By bringing together OLAP and OLTPL to form a single database, your organization can benefit dramatically from lower total cost up front. Additionally, gaining incredible speed that will accelerate their business processes and custom application.
SAP HANA DB takes advantage of the low cost of main memory (RAM), data processing abilities of multicore processors and the fast data access of solid-state drives relative to traditional hard drives to deliver better performance of analytical and transactional applications.
Fusing SAP HANA with a scalable shared memory platform will enable businesses and government agencies running high-volume databases and multitenant environments to utilize high-performance DRAM that can offer up to 200 times the performance of flash memory to help deliver faster insight.
Here’s my analogy: players go to the “Super Bowl” for one of two reasons, to watch or participate. To be successful in today’s global market companies must effectively participate or risk being on the sidelines watching.
Since its introduction in 2011, SAP tries to push HANA very heavily and there is a lot of marketing buzz over this new product. For a freelance consultant focused on SAP Sybase database products, like me, it is next to impossible to ignore HANA in year 2013. So, I decided not to rely to marketing slogans and check what HANA is, what it can do, and, importantly, what HANA is NOT. I put my first impressions to this blog post; hopefully other HANA-related posts will follow. Note that I’m not a HANA expert (yetJ) and I’m writing these rows as a person with a lot of experience with IQ and some other RDBMSs and trying to learn HANA.
So, why to compare HANA and IQ? Both are designed for data warehouse environment, both are column-based (with some support of row-based data), both provide a data compression out-of-the-box and highly-parallel. Years ago, much like SAP for HANA today, Sybase claimed that IQ processed data so fast that aggregation tables are not really needed, because the aggregations can be just performed on-the-fly. Well, experience with a number of big projects showed me how problematic that statement was, and it is only a single example.
According to SAP, the strong point of HANA is its ability to utilize CPU cache , which is much faster than accessing the main memory (0.5 - 15 ns. vs. 100 ns.). Currently, IQ and other Sybase RDBMSs lack this capability. Therefore, I decided to build a test environment which allows performing of queries that answer a number of conditions:
Some notes about the test environment:
For IQ, I used 16-core RHEL server with hyper-threading turned on (32 cores visible to OS) and 140GB RAM available. I used IQ 16.0 SP01 for my tests.
For HANA, I had to use HANA SPS6 Developer Edition on a Cloudshare VM, which provides HANA on a Linux server with 24GB RAM. However, only 19.5 GB is actually available from the Linux point of view (free –m output) and most of this memory is allocated by various HANA processes. In fact, less than 3GB RAM is available for user data in HANA . I only wish that SAP would allow us to download HANA and install it on any server that answers to HANA’s requirements for CPUs, but it seems that the SAP’s policy is to distribute HANA as a part of appliances only, so I don’t expect free HANA download any time soon.
This brings us to an additional requirement for the test: the test dataset should be relatively small , because of severe RAM restrictions imposed by HANA Developer Edition on Cloudshare.
Finally, I decided to base my tests on a relatively narrow table that represents information about phone calls (for those involved in Telecom industry, it is like short and very much simplified CDRs). Here is the structure of the table:
create table CDRs (<br>
CDR_ID unsigned bigint, -- Phone
CC_ORIG varchar(3), -- Country code
of the call originatior
AC_ORIG varchar(2), -- Area code of
the call originatior
NUM_ORIG varchar(15), -- Phone number
of the call originatior
CC_DEST varchar(3), -- Country code
of the call destination
AC_DEST varchar(2), -- Area code of
the call destination
NUM_DEST varchar(15), -- Phone number
of the call destination
STARTTIME datetime, -- Start time of
ENDTIME datetime, -- End time of
DURATION unsigned int -- Duration of
the conversation in seconds
I developed a stored procedure that fills this table in SAP Sybase ASE row-by-row according to some meaningful logic and prepared delimited files for IQ and HANA. The input files are available upon request. At first, I planned to run tests on a dataset with 900 million rows, but I finally discovered that I have to go down to 15 million rows because of the VM memory limitations mentioned above.
Important note about the terminology. In IQ, inserting of the data from a delimited file into a database table is called LOAD, and retrieving of the data from a table to a delimited file is called EXTRACT. In HANA, the inserting is called IMPORT and the retrieving is called EXPORT. The term LOAD in HANA has a totally different meaning – it means loading of a whole table, or some of its columns, to the memory from disk, when the data is already in the database.
IMPORT functionality in HANA is not similar to IQ, at all. Actually, it contains two phases: IMPORT and MERGE. During the first phase, the data is imported to a “delta store” in an uncompressed form. Then, the data from the “delta store” is merged into “main store”, where the table data is actually resided. The merge is performed automatically, when a configurable threshold is crossed (for example, the size of the “delta store” becomes too big). To ensure that the imported data is fully inside the “main store”, a manual MERGE may be required. The memory requirements during the MERGE process are quite interesting, maybe I will write about it in a different post. It is pretty much possible that you will be able to IMPORT the data, but will not have enough memory to MERGE it; it happened to me a number of times during my tests. I would recommend you to read more about HANA architecture here: http://www.saphana.com/docs/DOC-1073, Chapter 9.
Given the significant difference between the test systems (a powerful dedicated server for IQ vs. small VM for HANA), I didn’t plan to compare the data load performance between IQ and HANA. However, so far I see HANA performing the IMPORT using not more than 1.5 core of 4 available, thus underutilizing the available hardware. The MERGE phase, though, is executed in a much more parallel way. The bottom line is that IQ seems outperform HANA in data loading, possibly quite by far. I will probably return to this topic in one of following posts, additional tests with larger dataset are required.
Now, we come to the data compression. Since IQ and HANA approach the indexing quite differently, I chose to compare the compression without non-default indexes in both IQ and HANA. It appears that IQ provides better data compression and needs 591M to store 15,000,000 rows, while HANA needs 748M to store the same data. HANA provides a number of compression algorithms for columns, which are chosen automatically, according to the data type and data distribution. However, it seems that neither of compression algorithms offered by HANA contains LZW-like compression used by IQ. I’d prefer to test the compression on a more representative data set (15,000,000 is way too small) and play with different HANA compression algorithms. I hope one of future posts will be dedicated to this topic.
Finally, the data is inside the database and we are ready to query it. To answer the test conditions mentioned above, I chose the following query:
a.CDR_ID CDR_ID_1, b.CDR_ID CDR_ID_2,
a.NUM_ORIG NUM_A, a.NUM_DEST NUM_B, a.STARTTIME STARTTIME_1, a.ENDTIME
b.NUM_DEST NUM_C, b.STARTTIME STARTTIME_2, b.ENDTIME ENDTIME_2,
from CDRs a, CDRs b
where a.NUM_DEST = b.NUM_ORIG
and datediff(ss, a.ENDTIME, b.STARTTIME) between 5 and 60
order by a.STARTTIME;
This query finds cases when a person A called person B and then the person B called person C almost immediately (in 60 seconds). This query has to perform a lot of logical I/O by its very definition. With my test data set, this query returns 31 rows.
In IQ, this query takes 6.6 seconds while executed fully in memory and when all relevant indexes are in place. The query uses sort-merge join and runs with relatively high degree of parallelism, allocating about 60% of 32 CPU cores available.
In HANA, the same query takes only 1 second with no indexes in place ! Remember, that in my tests HANA is running on a small VM with just 4 virtual CPU cores! The query finishes so fast that I cannot measure the degree of parallelism. Creation of indexes on NUM_ORIG and NUM_DEST reduces the response time to 900 ms.
A note about indexes in HANA: HANA offers only two index types and, by default, it chooses the index type automatically. In my tests, I have found that indexes improve query performance in HANA, sometimes significantly. Unfortunately, I have not found any indication of index usage in HANA query plans, even when some indexes were used by the query for sure. The role of the optimizer statistics in the query plan generation is also not very clear to me. I hope to prepare a separate post about query processing in HANA, stay tuned!
Another amazing and totally unexpected finding in HANA – index creation on NUM_DEST (varchar(15)) takes 194 ms. Index on DURATION (int) is created in 12ms!
My conclusions so far:
Update: see IQ query plan for my test case here: Download ABC_15mln_fully_in_memory
I’m not a great fan of SAP, or Oracle for that matter, but SAP’s HANA architecture is an unexpected innovation from a company that is rooted in serving the dull administrative needs of large organisations. In a nutshell HANA is an in-memory database capable of handling very large amounts of data with frightening speed. This is very timely, and more importantly will serve the needs of organisations for decades to come. While the focus is currently on the ability of HANA to address real-time analytics, the capability offered by HANA will serve us as we move into the feedback and control (cybernetics) era which has yet to unfold.
The current preoccupation with all forms of analytics (data mining, statistics, text mining, optimisation) and big data are predicated on very fast database systems. Traditional disk based technology is typically too slow and SAP has taken a simple idea – placing all data in much faster memory – and made it a reality. The idea is simple, but making it a reality is not. HANA enables many forms of business activity that were simply not possible before – real-time recommendations for customers, real-time tracking of very large distribution networks – and so on. This alone is enough to make HANA important for many businesses.
On the horizon however, and virtually unseen by most commentators, is the need to implement real-time feedback and control systems. It’s all very well to analyse current activity, but at which point is action called for, and what type of action will rectify a situation? Recommending additional purchases to customers in real time might not be optimal, and the response rate might start to drop off. At what point is remedial action needed, and how should the algorithms be modified? This is where we are headed – not just analysis, but analysis of analysis – a level of awareness within systems.
Massive computing ability is needed and there simply is no way that slow disk based technology will deliver the goods. HANA is a foundation for this move into a brave new world – and there are no real alternatives. There is a saying in technology markets that ‘if it works it’s already obsolete’ – I would make HANA an exception to this rule. For many organisations it will be a solid investment that will see them move into an age of real-time, intelligent business systems. Who would have thought that such an innovation would come from a German software company rooted in dull software applications that serve the needs of business administration.