SAP Hana and MS SQL can be compared on various parameters such as capabilities , securities , cost and other features . as my other colleagues pointed out it can be compare based on anyone of these parameters if objective of comparision is known to us .
Enterprise Programmes Architect at a logistics company with 10,001+ employees
Real User
2017-11-01T01:42:15Z
Nov 1, 2017
DP DHL does use both tools but the use is largely restricted by business function. To begin with I must set the context of which we use these tools.
I need to point out we also use Software AG's Terracotta and Mongo db for in-memory solutions as well as SAP's Hana. Terracotta is used for persistent memory associated with our ESB and Complex Event Processing, while Mongo db is primarily for report and user facing applications. Hana is largely confined to within the Global Business Management with limited use outside that division. All in-memory solutions are considered secondary drawing their data from relational data stores which is usually denormalized to support rapid access.
MS SQL is used for departmental level data stores and usually for non-mission critical applications. We have as primary data stores Oracle, Informix and Teradata (for data warehousing). MS SQL is usually defined as a functional data store (not really an ODS) and rarely connected to on-line transactional processing, but frequently as a localized data mart or in a supporting function.
The difference we have experienced between the tools was on speed of resolution for on-line requests, and if atomic, relational data was needed.
Hana worked well for us in areas where using large volumes of aggregated and unstructured data for analysis. It was primarily tied to our SAP ERP solutions with the native integration a prime feature. We rarely found it useful in big data search as we tend to approach big data in a non-standard and proprietary approach. Hana allowed close integration s well to a number of statistical modeling tools that support the financial analysis and forecasting.
MS SQL excelled in the areas of data quality validations, drill down of finite sets of data for a given subject area (limited business objects over small temporal windows). It integrated well and was actually a necessity for the use of the Microsoft BI stack, and tools. These are usually locally enabled, along with Tableau and Qlik-View by business functions. However, once “productionizing” the analytics we move to in-house developed solutions to reduce license and run costs.
Each tool has its own niche within DP DHL, and there is no view to replacing one with the other.
Security Data Analyst at a tech company with 10,001+ employees
Real User
2017-10-31T19:24:54Z
Oct 31, 2017
There are several similarities b/w the relational databases. I would go with one or the other only based on the use-case.
This particular tabular format helps compare and contrast the features.
db-engines.com
SAP Hana under the full use license can support non-SAP applications that's not the problem, but I don't think anyone would want to do it because of its high cost. Also notice that SAP HANA uses it's own SQL flavor and has a limited choice of drivers.
Software Architect at a tech consulting company with 51-200 employees
Real User
2017-10-31T18:23:14Z
Oct 31, 2017
I have NOT stated that HANA is a regular RDBMS, only I have done is to compare certain specific functionality that is similar between HANA and editions of SQL Server 2016, like for instance, columnstore indexes and xVelocity (I am using SQL Server monikers to describe similar functionality)
HANA as an appliance has functionality that roughtly corresponds with what Parallel Data Warehouse in SQL Server 2016 offers.
SAP Hana its not a RBMS, its an applications that run on memory and is only available as appliances and your data source can be a database coming RDBMS SQL. But are differents applications and filosofy.
Software Architect at a tech consulting company with 51-200 employees
Real User
2017-10-31T16:40:25Z
Oct 31, 2017
It is SQL Server 2016 that we should compare with SAP HANA, and not SQL Server 2017.
Before I get into the details of the comparisons, allow me to give you some feedack on why the comparison has to be with SQL Server 2016 and not with 2017.
Microsoft has embarked on a roadmap to have a SQL Server product line that offers the same tools and technologies on both Windows and Linux, but as of today, it is not there yet, so, for now, the full product line for SQL Server is only available in Windows with SQL Server 2016.
SQL Server 2017 does offer the same tools and technologies on both Windows and Linux, but SS 2017 only offers a subset of all the tools and technologies available with SQL Server 2016. As the roadmap for the common Windows/Linux codebase for SQL Server evolves over time, it is expected that coming versions of said products will widen the coverage of available tools and technologies.
Now that we have settled this point, we can get into the comparisons.
To start with, SAP HANA is only available as appliances for On Prem, and as a Cloud service, so, that gives you and idea of the budget range that would be involved.
Regarding SQL Server 2016, main functionality present in HANA, like In-Memory OLTP, or column store indexes and PowerPivot / xVelocity BI, is also available in SQL Server 2016 Enterprise, that runs on commodity hardware.
You also have this functionality as a Cloud Service in SQL Azure, and you could also design a hybrid solution of SQL Server 2016 Standard On Prem / SQL Azure for some tables that may require In-Memory OLTP support, and this is much less expensive than either only Enterprise or only SAP HANA.
It is SQL Server 2016 Parallel Datawarehouse (PDW) edition that offers all the functionality present in SAP HANA, and, just like HANA, PDW comes as appliances for On Prem and as a Cloud Service.
If you have any more questions pertaining to this, or some of point that I have covered are not clear, just ask.
Here is a useful tabular comparison of the two database engines:
db-engines.com
You could say that Microsoft SQL Server is more flexible than SAP HANA, and achieves a higher score and ranking.
On the other hand, if your environment is all SAP, SAP HANA may integrate better with the other application components.
The databases are completely different and I mean completely different.
Hana is an in-memory, columnar database that can mimic a row store in some cases.
SQL Server is anything from a classic relational DB to a distributed parallel warehouse, PDW.
If you are implementing SAP modules for your business, HANA gets consideration because of the expertise of the SAP people there to do the implementation. If you are implementing a home grown system or expecting to support the new system with in-house people, pick the DBMS that your in-house people are most comfortable working with.
From my limited perspective, I would only use HANA if I were depending on SAP to set up and maintain the system in perpetuity. If I wanted an in-memory columnar database and was expecting to support it with in-house people, I would look at other options, like Cassandra.
There are new languages to learn and many differences in how to properly architect columnar vs relational.
If you have Teradata in your environments already, you are well on the way to understanding the new NoSQL databases. If you are strictly a relational shop, the new NoSQL databases take some learning and a change in thinking.
Hans Chambers
Lavanya,
What is the context for comparison? Are you trying to compare performance in relation to a specific hardware configration? As John pointed out, you are kind of comparing apples and donuts, unless you have a specific use-case that can provide more detail for the comparison. Hana may, in some environments, replace the role a SQL server is holding, particularly if the SQL server is a data bridge, but you need to get way more specific in the ask.
We performed a comparison between SAP HANA and SQL Server based on our users’ reviews in five categories. After reading all of the collected data, you can find our conclusion below.
Ease of Deployment: Users of both solutions feel their initial setup is mostly straightforward with some complexity. SAP HANA users mention more difficulties, however, and note that it’s really complex if you’re migrating from another system.
Features: Users of both products are generally happy with their...
SAP Hana and MS SQL can be compared on various parameters such as capabilities , securities , cost and other features . as my other colleagues pointed out it can be compare based on anyone of these parameters if objective of comparision is known to us .
DP DHL does use both tools but the use is largely restricted by business function. To begin with I must set the context of which we use these tools.
I need to point out we also use Software AG's Terracotta and Mongo db for in-memory solutions as well as SAP's Hana. Terracotta is used for persistent memory associated with our ESB and Complex Event Processing, while Mongo db is primarily for report and user facing applications. Hana is largely confined to within the Global Business Management with limited use outside that division. All in-memory solutions are considered secondary drawing their data from relational data stores which is usually denormalized to support rapid access.
MS SQL is used for departmental level data stores and usually for non-mission critical applications. We have as primary data stores Oracle, Informix and Teradata (for data warehousing). MS SQL is usually defined as a functional data store (not really an ODS) and rarely connected to on-line transactional processing, but frequently as a localized data mart or in a supporting function.
The difference we have experienced between the tools was on speed of resolution for on-line requests, and if atomic, relational data was needed.
Hana worked well for us in areas where using large volumes of aggregated and unstructured data for analysis. It was primarily tied to our SAP ERP solutions with the native integration a prime feature. We rarely found it useful in big data search as we tend to approach big data in a non-standard and proprietary approach. Hana allowed close integration s well to a number of statistical modeling tools that support the financial analysis and forecasting.
MS SQL excelled in the areas of data quality validations, drill down of finite sets of data for a given subject area (limited business objects over small temporal windows). It integrated well and was actually a necessity for the use of the Microsoft BI stack, and tools. These are usually locally enabled, along with Tableau and Qlik-View by business functions. However, once “productionizing” the analytics we move to in-house developed solutions to reduce license and run costs.
Each tool has its own niche within DP DHL, and there is no view to replacing one with the other.
There are several similarities b/w the relational databases. I would go with one or the other only based on the use-case.
This particular tabular format helps compare and contrast the features.
db-engines.com
SAP Hana under the full use license can support non-SAP applications that's not the problem, but I don't think anyone would want to do it because of its high cost. Also notice that SAP HANA uses it's own SQL flavor and has a limited choice of drivers.
Sap hana is a in-memory database and expensive. If there is a sap r/3 , you may consider Hana, otherwise no need.
I have NOT stated that HANA is a regular RDBMS, only I have done is to compare certain specific functionality that is similar between HANA and editions of SQL Server 2016, like for instance, columnstore indexes and xVelocity (I am using SQL Server monikers to describe similar functionality)
HANA as an appliance has functionality that roughtly corresponds with what Parallel Data Warehouse in SQL Server 2016 offers.
Kind regards, GEN
SAP Hana its not a RBMS, its an applications that run on memory and is only available as appliances and your data source can be a database coming RDBMS SQL. But are differents applications and filosofy.
It is SQL Server 2016 that we should compare with SAP HANA, and not SQL Server 2017.
Before I get into the details of the comparisons, allow me to give you some feedack on why the comparison has to be with SQL Server 2016 and not with 2017.
Microsoft has embarked on a roadmap to have a SQL Server product line that offers the same tools and technologies on both Windows and Linux, but as of today, it is not there yet, so, for now, the full product line for SQL Server is only available in Windows with SQL Server 2016.
SQL Server 2017 does offer the same tools and technologies on both Windows and Linux, but SS 2017 only offers a subset of all the tools and technologies available with SQL Server 2016. As the roadmap for the common Windows/Linux codebase for SQL Server evolves over time, it is expected that coming versions of said products will widen the coverage of available tools and technologies.
Now that we have settled this point, we can get into the comparisons.
To start with, SAP HANA is only available as appliances for On Prem, and as a Cloud service, so, that gives you and idea of the budget range that would be involved.
Regarding SQL Server 2016, main functionality present in HANA, like In-Memory OLTP, or column store indexes and PowerPivot / xVelocity BI, is also available in SQL Server 2016 Enterprise, that runs on commodity hardware.
You also have this functionality as a Cloud Service in SQL Azure, and you could also design a hybrid solution of SQL Server 2016 Standard On Prem / SQL Azure for some tables that may require In-Memory OLTP support, and this is much less expensive than either only Enterprise or only SAP HANA.
It is SQL Server 2016 Parallel Datawarehouse (PDW) edition that offers all the functionality present in SAP HANA, and, just like HANA, PDW comes as appliances for On Prem and as a Cloud Service.
If you have any more questions pertaining to this, or some of point that I have covered are not clear, just ask.
Kind regards, GEN
Here is a useful tabular comparison of the two database engines:
db-engines.com
You could say that Microsoft SQL Server is more flexible than SAP HANA, and achieves a higher score and ranking.
On the other hand, if your environment is all SAP, SAP HANA may integrate better with the other application components.
The databases are completely different and I mean completely different.
Hana is an in-memory, columnar database that can mimic a row store in some cases.
SQL Server is anything from a classic relational DB to a distributed parallel warehouse, PDW.
If you are implementing SAP modules for your business, HANA gets consideration because of the expertise of the SAP people there to do the implementation. If you are implementing a home grown system or expecting to support the new system with in-house people, pick the DBMS that your in-house people are most comfortable working with.
From my limited perspective, I would only use HANA if I were depending on SAP to set up and maintain the system in perpetuity. If I wanted an in-memory columnar database and was expecting to support it with in-house people, I would look at other options, like Cassandra.
There are new languages to learn and many differences in how to properly architect columnar vs relational.
If you have Teradata in your environments already, you are well on the way to understanding the new NoSQL databases. If you are strictly a relational shop, the new NoSQL databases take some learning and a change in thinking.
Hans Chambers
Lavanya,
What is the context for comparison? Are you trying to compare performance in relation to a specific hardware configration? As John pointed out, you are kind of comparing apples and donuts, unless you have a specific use-case that can provide more detail for the comparison. Hana may, in some environments, replace the role a SQL server is holding, particularly if the SQL server is a data bridge, but you need to get way more specific in the ask.
SAP Hana is only to Support SAP , its an appliance for SAP its not an RDBMS like sql server
you can't you it to run your helpdesk app or anly thing .