Concept card

SAP Datasphere — Open SQL Schemas

As of 2026-10-06

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 Datasphere?

Open SQL Schemas are a bring-your-own-SQL escape hatch inside Datasphere's governance perimeter — tables there get no catalog discovery, lineage, or model support, so using them as default leaves a tenant with no semantic layer.

What it is

An Open SQL Schema is a SAP Datasphere construct that exposes a standard SAP HANA Cloud database schema directly to authorised users and external tools — bypassing Datasphere's modelling layer and letting developers run native HANA SQL (DDL + DML), connect any HDBSQL/JDBC client, and use HANA developer tooling against tables that nonetheless belong to the Datasphere space's storage and governance perimeter. It is the bring-your-own-SQL escape hatch when Datasphere's graphical/modelling surfaces are too restrictive for a specific use case.

What Open SQL Schemas enable. They are the answer to three recurring needs. Native HANA development: building HANA stored procedures, calculation views with SQLScript, or HANA-native applications inside the Datasphere governance perimeter — without re-implementing in Datasphere's transformation flow. Direct external-tool access: connecting SAP Analysis for Office, third-party BI tools, or custom Python/R scripts directly to a schema without going through Datasphere's consumption views. Code-first ETL: data engineers writing DDL + DML scripts to land + transform data through code-controlled pipelines (git-version controlled) rather than through Datasphere's flow editor.

Why it matters

They solve three real needs — native HANA stored procedures, direct external-tool access (SAP Analysis for Office, third-party BI, Python/R), and git-versioned code-first ETL.
Lineage stops at the schema boundary, and analytic models can't be built directly on Open SQL Schema tables — they must be exposed via a Datasphere view first.
The most common mistake is defaulting to Open SQL Schema as the primary modelling layer instead of Datasphere spaces, local tables, and views.

Key points

Direct HANA Cloud schema access inside a Datasphere space — native SQL (DDL + DML), HDBSQL/JDBC clients, HANA developer tooling.
Three use cases — HANA-native procedure/view development; direct external-tool access (Analysis for Office, BI tools, Python/R); code-first ETL with git-versioned scripts.
Shares storage, security, memory with Datasphere modelling schemas in the same tenant — but content is NOT in the catalog, lineage stops at schema boundary.
Analytic models cannot be built directly on Open SQL Schema tables — expose via a Datasphere view first.
Anti-pattern — Open SQL Schema as primary modelling layer; defeats Datasphere's semantic + lineage value.
Open SQL Schema is where a HANA Cloud RAG/vector pipeline's engineering work belongs (native SQL, NLP functions, embedding calls) — but a table born there is invisible to Datasphere's Catalog (C127) and cannot ground a Joule agent until it crosses into a Datasphere view.
The two-hop pattern for AI or BI alike: engineer in the Open SQL Schema (code, git, fast iteration), publish a thin Datasphere view as the only interface any consumer or agent is allowed to read.
A view layer between the raw schema and its consumers means the schema's internal structure can change (a retrained model's new columns) without breaking every downstream report or agent — the view absorbs the change.

Terms used on this page

Open SQL Schema: A SAP Datasphere construct exposing a standard SAP HANA Cloud database schema directly to authorised users and external tools, bypassing Datasphere's modelling layer; for HANA-native development and code-first patterns inside the Datasphere governance perimeter.
HDBSQL: The SAP HANA command-line SQL client; the canonical way to run native SQL against an Open SQL Schema from a developer workstation or CI pipeline.
Consumption view: A Datasphere object that exposes a curated, business-semantic view of underlying tables for downstream analytic models; the canonical way to expose Open SQL Schema content to analytic models.
Bring-your-own-SQL: The architectural pattern of providing developers with raw SQL access alongside a higher-level modelling surface; SAP Datasphere implements this via Open SQL Schemas.
hdbcli: SAP HANA's Python driver; the typical way a data engineer scripts native SQL and calls external APIs (including SAP AI Core) against an Open SQL Schema from code.
Vector table (HANA Cloud): A table in HANA Cloud carrying a vector-typed column for embeddings, commonly created and populated inside an Open SQL Schema as part of a RAG pipeline's engineering work, then exposed via a Datasphere view for grounding.
Interface stability: The property a Datasphere view provides by sitting between a raw Open SQL Schema table and its consumers — the raw table's internal structure can evolve without breaking the published, consumed shape.

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 →