Concept card

SAP HANA Cloud

As of 2026-09-27

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is SAP HANA Cloud?

SAP's in-memory database delivered as a managed cloud service on BTP — and the engine that actually runs SAP Datasphere and, beneath it, Business Data Cloud. Sized in capacity units, released quarterly, and not the same product as on-premise SAP HANA 2.0.

What it is

SAP HANA Cloud is SAP's in-memory, multi-model database delivered as a managed service on SAP Business Technology Platform. Its importance to anyone working in SAP analytics is structural rather than optional: it is the storage and compute engine underneath SAP Datasphere, and therefore underneath SAP Business Data Cloud as well. A conversation about Datasphere performance, cost or sizing is, one layer down, a conversation about HANA Cloud.

It is not on-premise HANA with a hosting contract. SAP HANA 2.0 and SAP HANA Cloud share lineage and much of the SQL surface, but they are operated as different products. HANA Cloud follows a quarterly release cycle rather than support package stacks; administration moves from HANA Cockpit and hdbsql-on-a-host to the BTP cockpit and a managed control plane; and several on-premise operational levers — kernel-level parameters, direct filesystem access, some scale-out topologies — are simply not exposed. Teams that plan a HANA 2.0 to HANA Cloud move as a database migration and nothing more consistently underestimate the operational relearning that comes with it.

Compute and storage separate, and that is the cost model. HANA Cloud sizes memory, compute and storage as separately scalable elements consumed in BTP capacity units, and it pairs the in-memory database with two colder tiers: Native Storage Extension for warm data that should stay queryable but not resident, and the HANA Cloud data lake — a relational engine plus a file store — for volumes that never justify memory. Getting the tiering wrong is the most common way a Datasphere estate becomes expensive without becoming faster.

Why it matters

Every Datasphere and BDC sizing, cost and performance question resolves one layer down, in HANA Cloud. A consultant who can only discuss the semantic layer cannot defend an estimate.

Key points

The engine under Datasphere and, through it, under Business Data Cloud — not an adjacent product.
Managed service on BTP: quarterly release cycle, managed control plane, several on-premise operational levers not exposed.
Compute and storage scale separately and are consumed in BTP capacity units.
Three tiers, one decision: in-memory · Native Storage Extension (warm) · HANA Cloud data lake (cold). Mis-tiering is the usual cause of a costly-but-slow estate.
Multi-model — graph, spatial, JSON document store and a vector engine — which is why it appears in Joule and agentic-AI architectures.
🔴 SAP HANA 2.0 and SAP HANA Cloud are operated as different products; a move between them is not a database migration and nothing more.

Terms used on this page

Capacity unit (CU): The BTP commercial unit in which HANA Cloud compute, memory and storage are consumed and billed.
Native Storage Extension (NSE): The warm tier: data that stays queryable without staying resident in memory, at lower cost per gigabyte.
HANA Cloud data lake: The cold tier — a relational engine plus a file store — for volumes that never justify memory.
QRC (Quarterly Release Cycle): The cloud delivery cadence that replaces on-premise support package stacks.
Vector engine: The HANA Cloud capability that stores and searches embeddings, used for retrieval-augmented generation over SAP data.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →