Concept card

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

As of 2026-09-27

Edited by Cédric Mary, 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.

The critical property is that all three engines share the HANA transaction log and security model. A single SQL query can join a relational customer table, a graph traversal of the customer's referral network, a spatial filter on a delivery polygon, and a JSON document of the customer's preference payload — all in one statement, all under one row-level security rule, all in milliseconds.

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.
HANA Cloud also ships a Vector Engine (embeddings/similarity search) and a separate native Knowledge Graph Engine (RDF/SPARQL) alongside the property-graph GRAPH workspace this card covers — three distinct "graph-adjacent" capabilities, not one.
September 2026: the Knowledge Graph Engine adds GeoSPARQL support (QRC3 2026) and further agentic-AI-oriented innovations — a second path to geospatial reasoning alongside this card's OGC ST_* operators.
Decision test: multi-model earns its keep while the value comes from joining models in one transaction; once a single engine's own workload (traversal depth, ingestion velocity, index size) becomes the dominant cost driver, evaluate a dedicated engine for that workload specifically.

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 property-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.
Vector Engine: HANA Cloud's native embeddings and similarity-search engine, sharing the same transaction log and security model as the relational, graph, spatial and JSON engines — the semantic-search half of HANA Cloud's hybrid-RAG story.
Knowledge Graph Engine (RDF/SPARQL): A native HANA Cloud engine distinct from the property-graph GRAPH workspace this card covers; it stores and queries RDF triples via SPARQL and underpins the fact-based-relationship half of hybrid RAG, feeding the same SAP Knowledge Graph that grounds Joule.
Hybrid RAG: Combining vector similarity search with fact-based graph relationship queries in one retrieval step, rather than choosing one mode — HANA Cloud implements this by running its Vector Engine and Knowledge Graph Engine side by side in the same database.

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 →