Guide

SAP HANA data analytics — the engine under your reporting, not a second tool

As of 2026-11-05

Edited by Cédric Mary, publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

SAP HANA data analytics means running analytical work inside SAP's in-memory database rather than beside it: aggregation, predictive functions and live queries execute where the data sits. In 2026 that engine is usually SAP HANA Cloud, a managed service on SAP BTP that sits underneath SAP Datasphere and, through it, SAP Business Data Cloud. So the decision is rarely which tool to buy. It is which data stays in memory, which moves to colder tiers, and which queries reach the engine live.

One engine, three layers that get confused

The database is SAP HANA Cloud. The semantic layer, where models and data access controls live, is SAP Datasphere, which runs on it. The front end for reporting and planning is SAP Analytics Cloud, a separate product that reads from those layers. People who search for a single "HANA analytics" product are usually looking at two or three of these at once.

They meet at the connection. On a live connection each render pushes a query down to the Analytic Model, calculation view or InfoProvider, nothing is copied into SAP Analytics Cloud, and access controls flow through. An imported model copies data on a schedule instead: it renders faster, but it inherits no row-level access. Our working design budget for live is roughly two hundred simultaneous ad-hoc users per Analytic Model, a figure from our corpus and not an SAP limit.

On-premise 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, moves administration to the BTP cockpit, and does not expose some on-premise levers such as kernel-level parameters.

Where the data sits decides the bill

HANA Cloud scales memory, compute and storage separately, consumed in BTP capacity units, and it offers three tiers. Choosing between them is the design, not an optimisation for later. A capacity-unit estimate that never mentions memory, Native Storage Extension or the data lake has skipped the part that holds the cost.

Queried interactively, or feeding a live model or a story — Tier: in-memory, or Native Storage Extension for warm data · Why: it must answer at reporting speed.

Kept queryable but not read every day — Tier: Native Storage Extension · Why: it stays available without staying resident.

History held for compliance or occasional analysis — Tier: HANA Cloud data lake · Why: the volume never justifies memory.

Putting everything in memory because it is fast is the usual way an estate becomes expensive without becoming faster.

Big data on HANA is a tiering pattern, not a product

We find no separate product that answers to the phrase big data platform on HANA. What exists is the cold end of the tier model: the HANA Cloud data lake, a relational engine plus a file store, for volumes that should not sit in memory. A large estate on HANA Cloud is therefore a question of how much history is resident, how much is warm, and how much is held in the lake, with the semantic model reading across them.

HANA Cloud also carries graph, spatial and JSON document engines and a vector engine. The vector engine is the reason it appears in Joule and agentic AI architectures rather than only in reporting ones. Those engines widen what the data can be used for. They do not change the tiering question.

Analytics inside the database

Three routes run machine learning and statistics in the engine, so the data does not have to leave it. The Predictive Analysis Library (PAL) is SQL-callable and covers classification, regression, clustering, time series, association rules and anomaly detection; it leaves the choice of algorithm and its tuning to the caller. The Automated Predictive Library (APL) makes that choice behind a smaller set of higher-level functions. The hana-ml client lets a data scientist drive the same in-database work from Python.

PAL suits a team that wants explicit control of the method, and APL suits one that wants a result with fewer decisions. Both are worth weighing before data is exported to a separate tool, because an export also exports the governance problem.

Query design comes before capacity

A slow HANA model is seldom solved by buying more of it. The levers are the column store, push-down, partitioning, statistics and indexes, and the choice between materialising and federating. Plan Visualizer is the diagnostic tool, and reading a plan is a skill worth a few minutes of practice before an escalation.

Two habits do most of the damage. Script views in a dependency tree stop push-down, so work that should run in the engine does not. Deeply stacked calculation views are the second, which is why our corpus keeps them to two levels. When a model federates many sources, measure whether materialising is the better trade before adding capacity.

What to settle before you quote

Ask for the target split across memory, Native Storage Extension and the data lake before quoting capacity units. Ask which consumers connect live and how many will do so at once. Ask whether a HANA 2.0 estate really needs a kernel-level lever that HANA Cloud does not expose; if it does, that is a reason to stay for now, decided with the maintenance horizon in hand.

For a BW 7.5 estate the clock is separate. SAP's announcement of 23 April 2020 ends mainstream maintenance on 31 December 2027, with optional paid extended maintenance to 2030, and maintains BW/4HANA until at least 2040. A lift-and-shift onto HANA Cloud without re-tiering buys time without buying capability.

What we cannot assert

SAP publishes no fixed capacity-unit floor and no public price list that we can cite for a given HANA Cloud estate, so this page names no cost figure. Size with SAP's official estimator.

Frequently asked

Is SAP Analytics Cloud the same thing as SAP HANA Cloud?

No. SAP HANA Cloud is the database. SAP Analytics Cloud is the reporting and planning front end, which reads from it through a live connection or an imported model.

Can SAP HANA handle very large data volumes?

Yes, by tiering rather than by keeping everything in memory. Warm data goes to Native Storage Extension and cold data to the HANA Cloud data lake, which pairs a relational engine with a file store.

Do I need SAP Datasphere to run analytics on HANA?

Not for a query: a live connection can read a calculation view directly. Datasphere adds the governed semantic layer, and our default for new stories is live to a Datasphere Analytic Model.

Can machine learning run inside SAP HANA?

Yes. PAL and APL run in the database, and hana-ml drives them from Python, so training data does not have to be exported.

Engage the editor

This guide is written by Cédric Mary, SAP AI & Analytics Architect & Team Lead. 27 years of SAP — Datasphere, Business Data Cloud, SAC Planning, Joule. Freelance or permanent · Hybrid / remote · Anywhere in EMEA.

Profile and contact

What this page is built on

External sources

Get new SAP Analytics missions every week

No account needed. We first ask you to confirm by e-mail; nothing is sent without that confirmation, and every alert has a one-click unsubscribe link. Privacy

Open missions

SAP analytics jobs and contracts · freelance SAP contracts.