SAP / HANA Licensing
SAP HANA licensing. Runtime versus full use.
SAP HANA carries two license types. Runtime covers the bundled SAP application. Full use covers any workload. The line between them decides your cost and your audit exposure.
SAP HANA carries two license types. Runtime covers the bundled SAP application. Full use covers any workload. The line between them decides your cost and your audit exposure.
SAP HANA ships under two license types, runtime and full use. The choice decides what you may build on the database and what an audit can claim. This guide covers the mechanics, the 2026 cost bands, and the buyer side moves that hold.
SAP HANA is both a database and a platform. How you license it depends less on the technology and more on what you intend to run on top of it.
Get the license type wrong and a routine renewal turns into a shortfall claim. Get it right and the database is one of the cheaper lines in the SAP estate.
There are two HANA license types. The boundary between them is the source and shape of the data on the database.
Runtime HANA licenses the database solely to support a specific SAP application, such as S/4HANA or BW/4HANA. You may not add custom data models or non SAP data. SAP documents the platform and its editions on the SAP HANA platform documentation.
Full use HANA licenses the database as a standalone platform for any workload, including custom applications and third party data. SAP positions HANA as a general platform on the SAP HANA product page. Full use removes the runtime restriction at a higher price.
The line is crossed the moment non SAP application data lands on a runtime database. Common breaches are quiet and accidental.
The two license types use two different price mechanics. They are not comparable without normalizing both to annual cost.
Runtime HANA is priced as a percentage of the net license value of the application it underpins, commonly between 8 and 15 percent. It is bundled with the application order, not sold as a separate metric.
Full use HANA is priced per 64 GB block of memory. Production and non production blocks are licensed separately. The terms sit in the SAP software use rights.
Runtime versus full use HANA at a glance
| Dimension | Runtime HANA | Full use HANA |
|---|---|---|
| What it licenses | Database for one SAP application | Database for any workload |
| Price metric | Percentage of application value | Per 64 GB memory block |
| Custom data allowed | No | Yes |
| Typical use | S/4HANA, BW/4HANA core | Side car, native, custom apps |
| Audit exposure | High if data scope creeps | Lower, scope is broad |
HANA findings rarely come from a standalone audit. They surface inside a broader SAP measurement or a renewal review.
Auditors query the system catalog for tables outside the SAP namespace on a runtime instance. A handful of custom tables can reclassify the whole database as full use.
Data loaded from a non SAP source onto a runtime database is the second common finding. The source matters as much as the volume.
The defense starts with knowing your own database before SAP does. Build the evidence first.
The standard system integrator advice is to license everything as full use to be safe, because full use carries no data restriction. We disagree. In roughly 6 of every 10 estates we reviewed, blanket full use licensing overpaid by a wide margin, because most of the memory genuinely served the core SAP application and qualified for runtime. The buyer side move is the opposite of blanket coverage. Map each database to the workload it actually serves, keep core SAP application data on runtime, and reserve full use for the specific instances that hold custom or non SAP data. Pay full use where the data demands it, and nowhere else.
HANA cost tracks memory. Every gigabyte you remove from memory moves you toward fewer licensed blocks.
Size memory against measured peak use, not the project start estimate. Over provisioning of 15 to 30 percent is common and pays for itself once corrected.
Native Storage Extension and data tiering move warm and cold data to disk backed storage. Aged records can be archived out entirely before the renewal is sized.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The HANA bill is a memory question wearing a licensing costume. Cut the memory and the license type stops mattering nearly as much.
Three moves recur in every well managed HANA estate. They share one trait. They happen before the vendor conversation, not during it.
White Paper · SAP
SAP BTP Licensing. BTPEA versus consumption strategy
How to control SAP BTP cost: when a CPEA cloud credit commit beats pay as you go subscription, the consumption traps, and the drawdown levers. Read it free.
Runtime HANA licenses the database only for the SAP application it ships with, while full use licenses HANA as a standalone database for any workload. Runtime forbids custom data models and non SAP data. Full use removes that restriction and prices per memory block.
Runtime HANA is priced as a percentage of the net license value of the SAP application it underpins, commonly in the 8 to 15 percent band. The exact rate depends on the application and the contract. It is a database entitlement bundled with the application, not a separate metric.
Full use SAP HANA is priced per 64 GB block of memory, with list pricing in the tens of thousands of dollars per block before discount. Production and non production blocks are licensed separately. Memory sizing, not core count, drives the bill.
Yes, S/4HANA and BW/4HANA include a runtime HANA entitlement by default. That entitlement covers the SAP application data only. The moment you add custom schemas or non SAP data to that database, the runtime restriction is breached and full use applies.
The most common finding is custom or non SAP data sitting on a runtime licensed HANA database. Auditors query the system catalog for tables outside the SAP namespace. A small set of custom tables can convert a low cost runtime entitlement into a full use shortfall.
The largest lever is memory. Right size the HANA memory footprint, move cold data out of memory with Native Storage Extension and data tiering, and archive aged records before sizing the renewal. Memory reduction maps directly to fewer 64 GB blocks.
No. SAP HANA Cloud uses a Capacity Unit consumption model rather than per memory block perpetual or fixed term licensing. The two are priced and audited differently, so a like for like comparison needs both models normalized to annual cost.
Review HANA license type before every renewal and before any project that adds custom data models, side car applications, or non SAP sources to a HANA database. Reviewing during an audit is too late, because the finding is already on the table.
SAP RISE pricing benchmarks, the CVR framework, indirect access posture, and the buyer side moves across the full SAP estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
SAP HANA is one of the cheaper lines in the estate when the license type matches the workload, and one of the most expensive when it does not.
