Contents
Key takeawaysRuntime vs full useWhat each costsReclassification triggersChecking your positionMemory sizingWhat we have seenSAP's lines and your repliesHANA CloudWhat to do nextFAQRuntime HANA costs 8 to 15 percent of the SAP application value but covers only that application. Full use costs about $32,500 per 64GB block at list, and a few custom tables on a runtime database can put the whole database at full use rates.
- Two license types. Runtime HANA supports only the SAP application it ships with, while full use allows custom applications, non SAP data and external tools.
- Different price bases. Runtime is a percentage of application license value, and full use is priced per 64GB memory block.
- The catalog decides. SAP's measurement reads the system catalog, and custom tables, non SAP data or direct SQL access on a runtime instance support a full use claim on the entire database.
- A frequent finding. About 6 in 10 runtime instances we reviewed carried custom tables or non SAP data.
- Memory is oversized. Full use memory ran 15 to 30 percent above measured peak, and non production often sat at the production tier.
- Cloud reprices everything. HANA Cloud meters Capacity Units, so every migration converts your current classification, right or wrong, at new rates.
What is the difference between a HANA runtime license and a full use license?
A runtime license covers HANA only as the database for the SAP application it was sold with. A full use license covers it as a general database for any workload. The engine is identical, and what you are allowed to put on it decides which license you need and what it costs.
S/4HANA and BW/4HANA carry runtime HANA by default, priced as a share of the application license value it supports. Full use HANA, sold as the standard and enterprise editions, is priced per block of memory before discount. The table sets the two side by side.
| 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, sidecar scenarios, external tools |
| How it is priced | Commonly 8 to 15 percent of the application license value | Per 64GB memory block, list benchmark near $32,500 before discount |
| What breaks it | Custom data models, tables outside the SAP namespace, non SAP data, custom SQL and external tools against the database | Nothing in the grant; the limit is the memory you have paid for |
| What an audit checks | The system catalog, read directly by SAP's measurement | Memory in use against licensed blocks |
Where the runtime grant ends
SAP's Software Use Rights allow a runtime database to be used only in conjunction with the SAP packages you licensed. The restrictions below all come from that clause. A workload that reaches the database without going through the SAP application sits outside the grant.
In practice that rules out custom data models built in the database, non SAP data loaded straight into it, and reporting or integration tools that open their own connection. A sidecar HANA fed from S/4HANA for a custom dashboard is a full use scenario, even though every row in it came from SAP.
SAP treats reclassification as a whole database question. A few custom Z tables on a runtime instance do not create a small full use exposure. They support an argument that the entire database, every block of memory, should be repriced at full use rates. That asymmetry is the reason the boundary needs a named owner.
How much does each HANA license cost in practice?
Runtime cost scales with what you paid for the SAP application, while full use cost scales with memory. The two can land close together on paper and far apart after an audit, because a reclassification claim prices every block of memory at full use rates, and the runtime fee you already paid may not be credited against it.
Take a hypothetical company with $4,000,000 of S/4HANA application license value and a 1.5TB production database. The runtime line and a full use claim on the same system compare like this:
| Item | Calculation | Result at list |
|---|---|---|
| Runtime HANA, low end | 8 percent of $4,000,000 | $320,000 |
| Runtime HANA, high end | 15 percent of $4,000,000 | $600,000 |
| Memory to license at full use | 1,536GB divided by 64GB | 24 blocks |
| Full use claim on the whole database | 24 blocks at $32,500 | $780,000 |
The $780,000 is before SAP's annual maintenance, which is charged as a percentage of license value and grows with it. On paper the full use claim is only 30 percent above the high runtime figure. In practice it is additional money, because the runtime fee is already spent unless you negotiate a credit.
How the answer changes with your situation
- Single S/4HANA system, no custom reporting on the database. Runtime is almost always the cheaper license, and your job is keeping the database clean.
- S/4HANA plus BW/4HANA with a data team. The pressure to build directly on HANA is highest here. Decide which workloads stay in the SAP layer and license a separate full use instance for the rest.
- Sidecar or native HANA applications. These need full use from day one. Size the instance for its measured workload, not for growth you hope to see.
- Moving to RISE or HANA Cloud. The database is repriced inside a new contract, so classify every workload before the quote is built.
The HANA runtime restriction analysis
The catalog queries auditors run, the reclassification arithmetic and the remediation paths, built for the renewal before the audit.
Get the white paper →What triggers reclassification from runtime to full use?
Reclassification is triggered by what SAP finds in the database catalog. SAP's measurement does not interview your architects. It reads the catalog, and 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 an 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.
Your protection is running the same read first. Query the catalog for objects outside the SAP namespace on every runtime instance each quarter. Then either migrate the offenders to a properly licensed platform, BTP or a full use instance sized for the purpose, or license the instance openly at negotiated prices before a measurement prices it for you.
Custom ABAP objects and objects built in the database are different cases
Tables created through the ABAP Dictionary, inside the SAP application and its schema, are argued differently from tables, views or procedures created directly in HANA by a database user. Where SAP draws that line for your contract is worth getting in writing. The wider measurement process is covered in the SAP audit survival guide.
Why buying full use for everything is usually the wrong fix
A common recommendation after a scare is to convert every runtime database to full use and stop worrying. We advise against it for most companies. Full use pricing runs on every block of memory, so converting a large production system buys a license for terabytes that only ever run SAP.
The offending workloads are often a handful of tables. Move them to BTP or a full use instance sized for them, and keep the main database on runtime.
How do you check your own HANA license position?
You check it by running the same reads SAP runs, on every instance, before anyone asks. Your basis team can do this with standard system views and transactions in a few hours per SAP system.
- List schemas and owners. Query SYS.SCHEMAS and SYS.TABLES for schemas other than the SAP application schema and for tables owned by database users rather than the SAP schema user.
- List custom objects in the SAP schema. Filter for Z and Y table names, then record for each one whether it was created through the ABAP Dictionary or directly in the database.
- Check who connects. M_CONNECTIONS shows client hosts and database users. Any connection from a reporting server, ETL tool or desktop SQL client deserves an explanation.
- Read the memory figures. M_LICENSE shows the licensed memory limit and current usage, and M_LICENSE_USAGE_HISTORY keeps the peak usage by period that SAP's measurement relies on.
- Compare with the measurement output. Run USMM and the License Administration Workbench as SAP would, so the numbers you send match the numbers you checked.
How does memory sizing drive the full use bill?
Full use HANA bills by the 64GB block, so every block of unused memory you license is money spent on an infrastructure decision. In our reviews, memory was over provisioned 15 to 30 percent against measured peak because it was set generously at project start and never reconciled.
That gap was carried through every renewal afterward. It typically amounted to one to several blocks per instance, each priced at list.
A worked sizing example
Say a full use instance is licensed for 24 blocks, 1,536GB, and its measured peak over the last year is 1,180GB. Peak rounds up to 19 blocks, or 1,216GB. The 5 surplus blocks are 21 percent of the licensed total and $162,500 at list, before maintenance.
Non production tiers
Development, test and sandbox instances often sit at the production tier by default, even where lower cost non production terms apply. Each HANA system records its role in the usage parameter of the system_information section of global.ini, set to production, test, development or custom. Check that parameter against the tier you pay for, instance by instance.
Fixing both problems takes an afternoon of measurement and a renewal conversation: peak memory per instance against licensed blocks, production terms against actual workload roles, and the difference priced at your discount rate as your opening position.
What have we seen in recent SAP HANA license reviews?
Across roughly 30 to 40 SAP HANA licensing reviews we ran between 2024 and 2026, the gap between the license position a company believed it had and what it actually used averaged 20 to 35 percent of memory. The same findings came up again and again:
- 6 in 10 runtime instances carried custom data. Z tables or non SAP data sat on a runtime database, each a latent reclassification of the whole instance.
- 1 in 2 had non production at production tier. Development and test blocks were licensed at the production rate when a lower cost tier applied.
- Memory sizing was never revisited. Most full use instances still carried the sizing chosen at project start, the gap covered in the memory section above.
The cause was ownership. The boundary between runtime and full use belonged to no one, so application teams built where memory was fast, and the licensing question surfaced years later at audit prices.
The companies that stayed clean gave the catalog check to the same person who owned user classification, and ran both before every renewal.
That owner handles FUE classification on the application side, which is explained in the S/4HANA licensing guide.
What will SAP's account team say about HANA, and how should you answer?
Expect the conversation to start from SAP's reading of the catalog and to end with an offer that bundles the fix into a larger deal. These are the lines we hear most often:
- "The measurement shows custom objects, so the database is full use." Ask which objects, in which schema, created by which user. Then ask SAP to show the contract clause that makes ABAP Dictionary objects a breach.
- "Full use is the only way to be compliant with your analytics plans." Reply that you will license a separate instance sized for those workloads and keep production on runtime.
- "We can waive the back license if you sign RISE this quarter." Ask for the waiver in writing as a standalone release, whatever you decide about RISE.
- "Memory is measured at the allocation limit." Ask for the measurement method in writing, and present your own peak usage history from M_LICENSE_USAGE_HISTORY.
Contract wording to ask for
- A written definition of permitted custom development on runtime HANA, naming ABAP Dictionary objects, so the audit cannot reinterpret it.
- A cure period for boundary findings, letting you move data off a runtime instance before any full use fee applies.
- Credit for runtime fees paid if any instance is converted to full use.
- Non production pricing stated per instance, so test and development blocks cannot default to the production rate.
- Price holds on additional 64GB blocks for the contract term, at your negotiated discount rather than list.
How does HANA Cloud licensing change the question?
SAP HANA Cloud replaces memory blocks with Capacity Units, a consumption construct covering compute, memory and storage. SAP sells them as a subscription with a monthly entitlement that depletes with usage, metered and audited differently from on premises blocks.
The runtime versus full use question does not disappear in the cloud. What your subscription allows you to run against the database is still a contract boundary. The migration is a repricing event, and every workload converts at whatever terms you negotiate at that moment.
Classify before the conversion is priced
Map every workload to its correct license before SAP prices the conversion, because the conversion inherits every misclassification at the new meter's rates. Your ability to fix the mapping lasts only while the signature is pending.
The HANA Cloud negotiation guide and the HEC guide cover the conversion itself, and the RISE pricing benchmarks show where the database line sits inside the wider bundle.
What to do next
- This quarter. Query the catalog on every runtime instance for objects outside the SAP namespace, and repeat it quarterly before any measurement does.
- For each finding. Migrate custom data to BTP or a sized full use instance, or license the instance at negotiated rather than audit prices.
- Before the renewal. Reconcile memory against measured peak per instance and reclaim the blocks sized at project start.
- At the same time. Move non production instances to non production terms, the easiest recovery on the HANA line.
- In the contract. Ask for the definition of permitted custom development, a cure period and runtime fee credit in writing.
- Before any cloud conversion. Map every workload to its license before the conversion is priced, since the conversion locks the mapping in. The SAP practice can run the review with you, independent of SAP.
Holding an SAP quote or renewal? Our SAP negotiation advisors work only for buyers, for a fixed fee or 25 percent of what we save you.
Frequently asked questions
What is the difference between runtime and full use HANA licensing?
Runtime covers HANA only as the database behind the SAP application it was bought with, and it is priced as a share of that application's license value. Full use turns HANA into a general database you can build on, load any data into and query with any tool, paid for by the memory block.
Can we put custom tables on a runtime HANA database?
Not safely without checking your contract. Custom data models and non SAP data fall outside the runtime grant, and SAP looks for tables outside the SAP namespace when it measures. Custom Z tables were the most frequent HANA finding in our reviews, and they can support a claim that the entire database needs full use licensing.
How much does full use SAP HANA cost?
Expect a list benchmark near $32,500 for each 64GB of licensed memory, discounted in negotiation and followed by annual maintenance. Core count plays no part. Because licensed memory usually exceeds measured peak, reconciling sizing before renewal tends to be the single largest saving on the HANA line.
Does S/4HANA include the HANA database license?
Yes, in its runtime form. S/4HANA and BW/4HANA are sold with runtime HANA as a percentage of the application value, and that license covers the database strictly in support of the application. Custom builds, non SAP data and external tools reading the database need full use, whatever the deployment brochure implied.
Are non production HANA systems licensed like production?
They should not be. Lower cost terms exist for development, test and sandbox systems, yet about half the companies we reviewed paid production rates for them. Bring a list of every instance and its actual role to the renewal, and ask SAP to price each one at its correct tier.
How does HANA Cloud licensing differ?
HANA Cloud draws down Capacity Units from a subscription instead of licensing fixed memory blocks, so cost follows compute, memory and storage consumed. The limits on what you may run still come from the contract. Fix workload classification before SAP prices the migration, because the new subscription inherits it.
Is the SAP HANA runtime license the same as the enterprise edition?
No. The enterprise edition is a full use license, sold per 64GB memory block, that allows custom development, native modeling and non SAP data. The runtime edition is restricted to SAP applications and priced from their license value. Moving a system from runtime to the enterprise edition means buying full use memory, so negotiate the credit for runtime fees before you sign.