Concept card

SAP HANA Cloud Multi-Model (Graph, Spatial, JSON Document Store)

As of 2026-07-23

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 Multi-Model (Graph, Spatial, JSON Document Store)?

HANA Cloud's graph, spatial, and JSON engines share the same transaction log and security model as its relational tables — one SQL statement can join a customer record, a graph traversal, and a JSON document, in milliseconds.

What it is

SAP HANA Cloud is not just a columnar in-memory relational engine — it is a multi-model database that runs graph traversals, spatial queries, and JSON document operations natively against the same data, in the same transaction, without ETL into a separate engine. This matters because a non-trivial share of SAP analytics use cases (customer 360, supply-chain network optimisation, IoT-on-the-edge) is fundamentally non-relational, and the multi-model surface lets the architect serve them from one engine.

Three non-relational engines ride inside HANA Cloud. The graph engine treats any pair of tables joined by a foreign key as a graph; the CYPHER-flavoured GRAPH workspace lets you write shortest-path, community-detection, and ego-network queries directly in SQL. The spatial engine implements OGC-compliant geometry types (POINT, POLYGON, LINESTRING) with ST_* operators (ST_Distance, ST_Within, ST_Intersects); it serves the entire geo-analytics layer for SAC Geo Maps and BDC location use cases. The JSON document store implements MongoDB-compatible CRUD operations on JSON columns; semi-structured payloads (IoT events, web logs, social signals) land natively without a forced schema.

Why it matters

It removes the ETL step to a separate graph or document database when the use case is customer-360, supply-chain network optimisation, or IoT-on-the-edge.
The spatial engine's ST_* operators (ST_Distance, ST_Within, ST_Intersects) already serve SAC Geo Maps and BDC location use cases directly.
It's the wrong tool at petabyte-scale graph analytics or high-velocity IoT ingestion — those need a dedicated graph database or a streaming platform upstream.

Key points

Graph engine — CYPHER-flavoured GRAPH workspace in SQL; shortest path, community detection, ego networks on existing relational data without schema duplication.
Spatial engine — OGC-compliant geometry types and ST_* operators; powers SAC Geo Maps and BDC location use cases.
JSON document store — MongoDB-compatible CRUD on JSON columns; semi-structured payloads (IoT, web logs) land without a forced schema.
One transaction, one security model — a single SQL statement joins relational, graph, spatial, and JSON operations under unified row-level security.
Limits — not for petabyte-scale graph analytics or high-velocity IoT ingestion; use dedicated engines upstream for those.
SAP HANA Cloud Multi-Model (Graph, Spatial, JSON Document Store) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

Terms used on this page

Multi-model database: A database that natively supports more than one data model (relational, graph, document, spatial, key-value) under one transaction log and security model; eliminates the multi-engine sprawl pattern.
GRAPH workspace: HANA Cloud's native graph engine; defined over existing relational tables connected by foreign keys, queried via a CYPHER-inspired pattern-matching syntax embedded in SQL.
OGC geometry: Open Geospatial Consortium-standard geometry types and operators (POINT, POLYGON, ST_Within, ST_Intersects); HANA Cloud spatial is OGC-compliant.
JSON Document Store: HANA Cloud's MongoDB-compatible API surface over JSON columns; CRUD operations on documents without ETL into a separate document database.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

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.

Open in the app →