Concept card

SAP HANA Smart Data Access (SDA)

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 Smart Data Access (SDA)?

Smart Data Access trades replication cost for query-time cost — no ETL or staleness, but every query pays a network round trip and remote load, which is why it wins for low-frequency exploration and loses badly at 100M-row production scale.

What it is

Smart Data Access (SDA) is the HANA-side data virtualization surface — the ability to define a virtual table inside HANA that points to a remote source (Oracle, Microsoft SQL Server, Teradata, Hadoop Hive, PostgreSQL, generic ODBC) and have HANA query the remote source on demand, pushing down predicates and joins where the remote optimiser can handle them. It is HANA's federation pattern, and a key tool when the customer has data scattered across heterogeneous sources that cannot or should not be replicated.

Why it matters

HANA's federation engine pushes filters and joins down to the remote optimiser where it can, and executes the rest locally after the remote returns.
For high-frequency operational queries against large remote tables, replication into HANA (via SDI or BDC native shares) almost always beats SDA on total cost.
The classic failure mode is using SDA for production analytics on a 100M-row remote table — query latency becomes unbearable within a month.

Key points

Federation, not replication — Virtual Tables point to remote sources (Oracle, SQL Server, Teradata, Hive, PostgreSQL, ODBC); queries execute on-demand against the remote.
Pushdown — HANA federation engine analyses queries, pushes filters/joins to the remote optimiser where supported, executes residual locally.
Trade-off — eliminates replication cost (no ETL, no storage, no staleness) but pays query-time cost (network, remote load, no HANA cache).
When yes — exploration, one-time-load, compliance forbids replication.
Anti-pattern — production analytics on 100M-row remote tables; replicate instead via SDI or BDC native shares.
SAP HANA Smart Data Access (SDA) 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

Smart Data Access (SDA): HANA's federation surface — Virtual Tables that query remote sources on-demand without replicating the data; the cheaper-but-slower alternative to Smart Data Integration replication.
Remote Source: A HANA-catalogued connection to an external database (Oracle, MS SQL Server, Hadoop, etc.); the foundation under which Virtual Tables are defined.
Virtual Table: A HANA catalogue object that points to a remote table or view via a Remote Source; appears in HANA's catalogue like a local table but executes against the remote at query time.
Query pushdown: The federation pattern where HANA decides which parts of a SQL query (filters, joins, projections) the remote optimiser can execute, sending those parts to the remote and executing the residual locally.
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 →