SAP HANA licensing, runtime versus full use
HANA ships under two license types, and the boundary between them is the source and shape of the data on the database. Get the mapping right and HANA is one of the cheaper lines in the SAP estate. Get it wrong, one custom table wrong, and a routine renewal becomes a reclassification claim.
Prepared by Redress Compliance · August 6, 2026 · SAP licensing advisory. Based on 30 to 40 HANA licensing reviews run 2024 to 2026.
Executive summary
Runtime HANA licenses the database solely to support the SAP application it ships with, S/4HANA and BW/4HANA carry it by default, priced as a percentage of the application license value, commonly 8 to 15 percent. Full use HANA licenses the database as a standalone platform.
Priced per 64GB memory block at a list benchmark near $32,500 per block, and it is what side car scenarios, native applications, and non SAP data require.
The boundary is enforced through the catalog, not the contract. Custom data models and non SAP data are not permitted on a runtime database, and SAP's measurement reads the system catalog directly: tables outside the SAP namespace, external tools pointed at the database.
And custom SQL are each reclassification triggers. A handful of custom Z tables can move the entire database from the runtime percentage to full use block pricing.
That is not a theoretical risk. Across our HANA reviews, custom tables or non SAP data sat on a runtime database in roughly 6 of every 10 estates, each one a latent full use exposure waiting for an audit or a renewal to price it.
The gap between what buyers believed they had licensed and what the estate consumed averaged 20 to 35 percent of memory.
Memory, not cores, drives the full use bill, which makes sizing the largest lever: memory was over provisioned 15 to 30 percent against measured peak because sizing was set at project start and never revisited.
And non production blocks ran at production tier in about half the estates when a lower cost tier applied.
HANA Cloud prices on a Capacity Unit model with its own meter, so every migration is also a repricing event.
The two license types, and the boundary between them
How you license HANA depends less on the technology than on what runs on top of it. The same database engine carries two very different commercial constructions:
| Runtime HANA | Full use HANA | |
|---|---|---|
| What it permits | The database supporting its SAP application only, S/4HANA, BW/4HANA, and their standard content | Anything: custom applications, non SAP data, side car scenarios, external tools |
| How it prices | 8 to 15 percent of the application license value | Per 64GB memory block, list benchmark near $32,500 per block |
| What breaks it | Custom data models, tables outside the SAP namespace, non SAP data, custom SQL and external tools against the database | Nothing to break; the constraint is the memory bill |
| Where it is audited | The system catalog, read directly by SAP's measurement | Memory sizing against licensed blocks |
The reclassification is whole database, not per table. One team writing a handful of custom Z tables onto a runtime instance does not create a small full use exposure; it creates an argument that the entire database, every block of memory, should reprice at full use rates.
That asymmetry is why the boundary deserves an owner.
The catalog is the audit, what triggers reclassification
SAP's measurement does not interview your architects; it reads the database catalog. The findings that move a runtime instance to full use are mechanical:
- Tables outside the SAP namespace. Custom Z tables and Y tables holding application data on the runtime instance, the most common finding in our reviews.
- Non SAP data loaded onto the database, whether by interface, replication, or a well meaning integration project that needed somewhere fast to put things.
- External tools and custom SQL pointed directly at the database, bypassing the SAP application layer the runtime license assumes.
The defense is the same read, run by you first: query the catalog for non SAP namespace objects on every runtime instance, quarterly, and either migrate the offenders to a properly licensed platform, BTP or a full use instance sized for the purpose.
Or license the instance honestly before a measurement prices it for you.
The wider measurement mechanics sit in the SAP audit survival guide.
The HANA runtime restriction trap
The full boundary analysis: what the runtime license actually permits, the catalog queries auditors run, the reclassification math, and the remediation paths that avoid full use pricing.
Get the white paper →Memory sizing, the full use lever nobody revisits
Full use HANA bills by the 64GB block, so every block of over provisioned memory is a licensing decision wearing an infrastructure costume.
The sizing pattern in our reviews was universal: memory set generously at project start, never reconciled against measured peak, and carried through every renewal since. The over provisioning ran 15 to 30 percent, worth one to several blocks per instance at $32,500 list each.
Non production compounds it: development, test, and sandbox instances licensed at the production tier in about half the estates, when lower cost non production terms applied.
The remediation is an afternoon of measurement and a renewal conversation: peak memory per instance against licensed blocks, production terms against non production reality, and the delta priced at your discount rate as the negotiation position.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across HANA reviews, 2024 to 2026
Across roughly 30 to 40 SAP HANA licensing reviews we ran between 2024 and 2026, the gap between believed and actual license position averaged 20 to 35 percent of memory, and the same three findings recurred:
Z tables or non SAP data on a runtime database, each a latent whole instance reclassification to full use pricing.
Development and test blocks licensed at the production rate when a lower cost tier applied to the workload.
The pattern behind the findings was ownership: the boundary between runtime and full use belonged to nobody, so application teams built where the memory was fast and the licensing question surfaced years later, at audit prices.
The estates that stayed clean assigned the catalog check to the same owner as the FUE classification, and ran both before every renewal. The application side mechanics sit in the S/4HANA licensing guide.
HANA Cloud, the same questions on a new meter
SAP HANA Cloud prices on Capacity Units, a consumption construct covering compute, memory, and storage, metered and audited differently from on premises blocks.
The runtime versus full use question does not disappear in the cloud; it translates: what the subscription permits you to run against the database is still a contract boundary, and the migration is a repricing event in which the whole estate converts at whatever terms you negotiate at that moment.
The HANA Cloud negotiation guide and the HEC guide cover the conversion mechanics, and the RISE pricing benchmarks place the database line inside the wider bundle.
The buyer side rule for the transition is the same as for the estate: map every workload to its correct license construct before the conversion is priced, because the conversion inherits every misclassification at the new meter's rates.
And the leverage to fix the mapping exists only while the signature is still pending.
Your first five moves
- Query the catalog on every runtime instance for objects outside the SAP namespace, quarterly, before any measurement does.
- Remediate the boundary violations deliberately: migrate custom data to BTP or a sized full use instance, or license the instance honestly at negotiated rather than audit prices.
- Reconcile memory against measured peak per instance, and reclaim the 15 to 30 percent of blocks sized at project start.
- Move non production to non production terms, the finding in half the estates and the easiest recovery in the file.
- Map every workload before any cloud conversion is priced, because the conversion locks the mapping in at the new meter. The SAP practice runs the review with you, on your side of the table.
Frequently asked questions
What is the difference between runtime and full use HANA licensing?
Runtime licenses the database solely to support the SAP application it ships with, priced at 8 to 15 percent of the application license value.
Full use licenses HANA as a standalone database, priced per 64GB memory block near $32,500 at list, and is required for custom applications, non SAP data, and side car scenarios.
Can we put custom tables on a runtime HANA database?
No. Custom data models and non SAP data are outside the runtime grant, and SAP's measurement reads the system catalog for tables outside the SAP namespace.
A handful of custom Z tables can reclassify the entire database to full use block pricing, which is the single most common HANA audit finding, present in 6 of 10 estates we reviewed.
How much does full use SAP HANA cost?
The list benchmark sits near $32,500 per 64GB memory block before discount, and memory sizing, not core count, drives the bill. With memory over provisioned 15 to 30 percent against measured peak in most estates, sizing reconciliation is typically the largest single recovery on the HANA line.
Does S/4HANA include the HANA database license?
S/4HANA and BW/4HANA carry runtime HANA by default, priced as a percentage of the application value, which covers the database strictly in support of that application.
Anything beyond it, custom builds, non SAP data, external tools against the database, needs full use licensing, whatever the deployment brochure implied.
Are non production HANA systems licensed like production?
They should not be, but in about half the estates we reviewed, development and test blocks ran at production tier when lower cost non production terms applied.
Reconciling tiers against actual workload roles is one of the easiest recoveries in the SAP estate, and it belongs in every renewal position.
How does HANA Cloud licensing differ?
HANA Cloud meters Capacity Units, a consumption construct spanning compute, memory, and storage, priced and audited differently from on premises blocks.
The runtime versus full use boundary translates into subscription terms, and the migration converts the estate at whatever mapping you bring, so the workload classification has to be fixed before the conversion is priced.
