SAC / Datasphereadvanced

Datasphere Federation vs Replication: Performance and Architecture (Part 7)

Key takeaway

Choose federation or replication from latency, source load, transformation and governance requirements rather than assuming real-time remote access is always superior.

Explanation

SAP Datasphere can access remote source data virtually or replicate data into the cloud depending on connection and capability. Federation keeps data in the source and queries it remotely, reducing duplication but making consumer performance dependent on source availability, network latency and pushdown capability.

Replication creates a local copy, increasing storage and synchronization responsibility but providing predictable analytical access and reducing repeated source-system load. Replication is often appropriate for high-volume or frequently reused datasets, while federation can suit current low-volume data or scenarios where copying is restricted.

The decision can differ by dataset. One space can federate a small reference table while replicating a large transaction fact.

Measure actual query plans and source load. A federated model that joins remote data with large local datasets can be expensive if filters do not push down effectively.

Govern refresh frequency, failure recovery and data staleness for replicated objects so users know how current a dashboard really is.

Real project scenario

A dashboard federated a multi-million-row ERP table on every refresh. Performance varied with source load. Replicating the high-use fact while federating small master data stabilized response time.

Common mistakes

Calling federation 'real time' without source-load analysis.
Replicating every dataset unnecessarily.
Ignoring filter pushdown.
Hiding data-staleness from consumers.
No recovery plan for failed replication.

Best practices

Decide per dataset.
Measure remote query behavior.
Make freshness visible.
Monitor replication failures.
Avoid unnecessary duplicate copies.

Interview angle

Compare federation and replication using latency, source impact, volume and freshness requirements.

Practice this lesson

Quick check

1. Scenario — A dashboard federated a multi-million-row ERP table on every refresh. In this Data Federation situation, which response best addresses the underlying design risk?

2. What is a key trade-off an administrator must weigh when choosing federation (Remote access) instead of replication for a remote table in SAP Datasphere?

3. A senior review of Optimizing Performance and Troubleshooting Federated Remote Table Queries finds this failure pattern: "Assuming 'connecting' a source automatically means data is copied into Datasphere, when in fact the default remote table access type performs live pass-through queries.". Which corrective action is strongest?

Interview questions

1. A senior architect is reviewing Data Federation. The project situation is: A dashboard federated a multi-million-row ERP table on every refresh. What design changes, validation evidence and production controls would you require before approving the solution?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A retail customer wants a live sales dashboard in SAC that always reflects the current stock levels in their S/4HANA on-premise system, because business users complained that a nightly replicated copy showed stale inventory numbers during promotional events — explain Understanding Data Federation Fundamentals in SAP Datasphere and SAC. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.