Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Participant
So we have all seen the marketing that “SAP HANA is the Answer !”

So now you want SAP HANA in your landscape how can it be purchased ? And how is it priced ?

Now there are probably more ways than I know about (and SAP often invent new pricing models), but these are the ways that I know / have seen :-

  • SAP HANA Enterprise Edition (Most features of SAP HANA – some exotic features extra - sometimes call "Full Use HANA")

    • SAP HANA Service – Enterprise Edition on SAP Cloud Platform

    • SAP HANA Enterprise Edition – On Premise version you install somewhere

  • SAP HANA Standard Edition

    • SAP HANA Standard Edition plus Adhoc Features from the full list available in SAP HANA Enterprise Edition (e.g you only want Database plus Geo Spatial)

    • SAP HANA Service – Standard Edition on SAP Cloud Platform

    • SAP HANA Standard Edition – On Premise version you install somewhere (essentially just the database part of HANA)

  • SAP HANA One (SAP HANA running on public cloud AWS / Alibaba – you pay an all in subscription)

  • SAP HANA, express edition (Free HANA for DB’s up to 32GB running on premise)

  • SAP HANA, Runtime edition for Applications & SAP BW – often called “HANA Runtime”

  • SAP HANA Packaged under a SAP Public Cloud Software as a Service (SaaS) application e.g S/4HANA Cloud – Multiple Tenant

Historic Note : In the past you could purchase SAP HANA Base Edition and SAP HANA Platform Edition – if you did check with your SAP AE how to convert these to the above

The above list is broadly in order of the flexibility you get to use all of SAP HANA’s features and hence broadly in price order (although all licenses are different – please ask you SAP AE for specific pricing) . All the options I have listed except for the last 2 are priced based on the size of the database (sold in blocks of memory). This type of usage is often referred to as “native” HANA as you are allowed to develop directly in SAP HANA.

The “HANA Runtime” one is a priced as a % of the cost of the SAP Application running on top of it (like other on premise runtime DB licenses from SAP).

The pricing when packaged in SAP SaaS solutions is normally bundled to a certain level of storage and then sold by database size.

For these 2 “HANA Runtime” use cases, the features of SAP HANA are only accessible via the Application Layer – so if the developer decided to use a SAP HANA Engine for predictive analytics, machine learning, geo spatial, text analytics, graph processing etc then you can use this feature from the application but you can’t dive in and use the engine in “native” HANA. For SaaS this basically means you only get to access what the SAP developer decided you could access, for the on premise Runtime license you can access the SAP HANA engines only via the Applications programming language e.g ABAP which usually means a more limited scope of features compared to using “native” HANA.

You can have a mix of license types in one landscape.

So what is right for you ?

I would always recommend starting from an Enterprise Architecture capability perspective. Figure out which of the capabilities of SAP HANA your organisations needs by mapping them to your organisations strategies and programmes.

This approach will get you a Logical SAP HANA Model. You can then overlay your non-functional requirements (High Availability, Disaster Recovery, Security, Performance, Cloud/On Premise, Budget etc) to get to a Physical SAP HANA Model.

In an ideal world this is what you would get priced by SAP (in writing of course) and off you go. In reality you may end up tweaking/compromising the Physical SAP HANA Model to take account of the licensing metrics, let’s call that the License SAP HANA Model. If you find that the Physical Model and the License Model are very diverged or you feel the License Model is too compromised, I would recommend active dialogue with SAP to see if you can create a customer specific model that works for you and SAP.

Important Note : The information contained in this blog is NOT an official SAP statement and is designed as a guide based on my experience in the field. You should not make ANY decisions based on this information. Before you make ANY decisions on how you are going to use SAP HANA you should get pricing from an SAP AE and have any use-cases included into your contract with SAP. You may want to use this blog to help guide the conversation with the SAP AE.


Labels in this area