Licensing HANA for Non-SAP Applications
SAP HANA isn’t limited to powering SAP’s software – it’s a high-performance database platform that some organizations want to use for their non-SAP applications. For example, a company might develop a custom analytics application or deploy third-party software that could benefit from HANA’s in-memory speed. However, using SAP HANA in this way requires careful attention to licensing.
The standard SAP HANA runtime license (which many SAP customers have for their ERP or BW systems) does not allow the use of third-party or custom databases.
This article guides businesses through the process of determining what licenses are needed to legally use HANA for non-SAP workloads, the limitations and costs to expect, and how to approach this decision.
Full-Use License Required
To run any non-SAP or custom application on SAP HANA, you must obtain a SAP HANA full-use license. This is essentially the “unrestricted” license for HANA, as opposed to the restricted runtime license tied to SAP applications.
The full-use license grants you the right to use HANA as a standalone database platform for any application – your in-house software, third-party vendor applications, custom data warehouses, etc.
There are no technical limitations on usage: you can create tables, load external data, and query HANA directly. In SAP’s licensing terms, full use is required for any scenario where HANA is used as a database independent of SAP’s standard applications.
It’s important to recognize that if you already run SAP systems with a HANA runtime license, that runtime license cannot be extended to cover new custom uses. Many SAP customers mistakenly assume they can leverage their existing HANA database for other data or applications – in reality, doing so would breach the license agreement.
For example, suppose you have SAP S/4HANA (including a HANA runtime license for that application) and develop a separate reporting tool that queries the HANA database directly. In that case, you’ve stepped outside the permitted usage.
The remedy is to purchase a full-use HANA license for that database (or to spin up an additional HANA instance licensed for the custom app).
In practice, if you want to add non-SAP workloads to an existing HANA environment, you’ll need to convert its runtime license to a full-use license.
Read SAP HANA Runtime vs. Full-Use License.
License Options and Considerations
You will deal with SAP’s full-use licensing model when acquiring HANA for non-SAP purposes. Within this category, SAP offers a couple of editions:
- SAP HANA Standard Edition: This edition includes core HANA database functionality. It is sufficient for most custom applications that just need the fundamental in-memory database features. Optional components (like certain integration or analytics engines) can be licensed additionally if required.
- SAP HANA Enterprise Edition: A superset that includes everything in Standard plus additional bundled components (for example, advanced data provisioning or data replication tools). Enterprise Edition is only necessary if your application requires those extras; otherwise, Standard is more cost-effective.
Standard and Enterprise full-use licenses are typically priced by memory capacity (GB of RAM) needed, similar to how HANA is licensed for SAP scenarios.
Be prepared for a significant investment – SAP often treats full-use HANA as a premium product and may not discount it much. For instance, a relatively small deployment (say 64 GB of HANA memory) can cost substantially.
For small and mid-sized businesses with modest needs, SAP has offered the HANA Edge Edition (for SAP HANA Platform), a bundle designed for non-SAP use in smaller environments. It is typically licensed based on several users or CPU cores instead of memory, which can lower costs if your usage is limited. However, HANA Edge still requires purchasing a license through SAP or an OEM partner.
Another consideration is SAP HANA Cloud. Instead of buying HANA licenses upfront for on-premises use, you could use SAP HANA Cloud (a cloud service) for your non-SAP application’s database.
HANA Cloud uses a subscription or consumption-based model, which we discuss below. This model may suit projects where you want to start small or avoid infrastructure management.
Read Upgrading to HANA from Other Databases.
Pricing Implications
When planning to use HANA for a non-SAP application, keep in mind:
- Memory-Based Cost: On-premise full-use licensing is charged per GB of memory. Estimate how much memory your application’s data will require, including future growth. HANA’s compression will help (e.g., 1 TB of raw data might become a few hundred GB in memory), but you must still license enough GB to cover your dataset. Budget for the possibility that HANA’s high performance comes with a high per-GB price tag.
- No Per-User Fees: You do not pay on a per-user basis for the HANA database itself – licensing is independent of how many users will access your custom application. (If you are a software vendor embedding HANA in your product, you’d handle that via an OEM agreement with SAP; end-users of the app don’t need separate SAP DB licenses.)
- OEM Partnerships: If you are a software provider wanting to embed HANA in a solution you sell, you can explore an OEM licensing agreement with SAP. Under such an agreement, you license HANA from SAP (often at partner pricing) and then offer it as part of your product to your end customers. This essentially repackages the full-use license into your solution. End customers then use HANA under your license. OEM licensing requires a special contract, but can be beneficial if you plan to deploy HANA to multiple clients as part of a software offering.
- HANA Express for Prototyping: If cost is a major concern initially, remember that SAP HANA, express edition is a free version (up to 32 GB of memory) that can be used for development or proof-of-concept. You could build and test your non-SAP application on HANA Express at no license cost. For production, you will need to move to a paid full-use license once you go live and exceed the free limits or require support, but using Express can delay license purchase until you are confident in the solution.
Example Scenario
Imagine a financial services company that built a custom risk analytics application and wanted to run it on HANA for performance. Initially, they were running on Oracle, paying Oracle’s license and support fees. When migrating this application to HANA, they negotiated a full-use HANA Standard Edition license for 128 GB of memory.
They found SAP’s willingness to offer discounts was limited, and HANA’s price was largely fixed. The move did increase their database licensing costs (HANA’s annual support was higher in absolute terms than Oracle’s had been). Still, the application’s query performance improved dramatically, which was critical for their risk calculations.
They implemented strict data tiering to manage ongoing costs: only the latest two years of data stay in memory, while older risk data is offloaded to a separate archive system. This keeps the HANA memory usage within the 128 GB they licensed, avoiding the need to buy more.
They also used HANA Cloud for a development/test instance on a pay-as-you-go basis, rather than licensing a full second HANA server, which saved money for non-production environments.
This scenario highlights the balance between HANA’s technical benefits and its licensing expense, and the need for strategies (like data tiering and selective cloud use) to optimize costs.
Recommendations
- Engage SAP Early: Discuss your plans with SAP or an authorized partner to clarify licensing requirements. They can advise whether a Standard or Enterprise edition is needed for your use case and provide pricing estimates. Early engagement also lets you explore any promotions or whether HANA Edge (for smaller deployments) could apply.
- Weigh Value vs. Cost: HANA is powerful, but also one of the more expensive database options. Ensure that the performance or capabilities you need from HANA justify the licensing expense. Consider that alternative if a simpler or cheaper database could meet your needs. Use pilot projects (with HANA Express or HANA Cloud trials) to measure HANA’s benefits in your scenario before full commitment.
- Plan for Compliance: If you’re an existing SAP customer, do not repurpose a HANA runtime instance for a new custom app without proper licensing—the audit penalties will far exceed the license cost. This may mean setting up a separate HANA instance for the non-SAP app with its license. Isolate and manage environments to ensure you remain compliant.
- Consider Cloud Options: Evaluate SAP HANA Cloud or similar services for new non-SAP projects. A cloud approach can let you start small and scale, paying only for what you use. This avoids huge upfront costs. For example, development or pilot environments might run in HANA Cloud (pay-per-use) until the solution is proven; at this point, you decide on a long-term platform.
- Optimize the Footprint: Treat memory as a costly resource, because with HANA’s license model, it is. Use data management techniques (archiving, data aging, compression) to minimize how much data you keep in HANA. A leaner data footprint not only improves performance, it saves money by requiring a smaller HANA license. Regularly review the HANA database and remove anything that doesn’t need to be in-memory.
