SAP Datasphere: Virtualization or Replication? How to Choose the Right Approach

One of the most common architecture decisions in SAP Datasphere is surprisingly simple to ask but difficult to answer:

Should I virtualize the data or replicate it into SAP Datasphere?

There is no single answer that works for every scenario.

The right choice depends on data freshness, performance requirements, data volume, source-system workload, transformation complexity and how frequently the data will be consumed.

This article provides a practical way to make that decision.

1. What is virtualization?

With virtualization, the data remains in the source system and SAP Datasphere accesses it remotely when required.

Conceptually:

Source System → SAP Datasphere → Query → Source System

This approach can be attractive when:

• Data needs to be close to real time.

• The dataset is relatively small.

• Users do not repeatedly query the same large dataset.

• You want to avoid unnecessary data duplication.

• The source system can handle the additional workload.

For example, imagine a business user needs current customer master data from an SAP source system.

If the data is relatively small and must always reflect the latest state, virtual access may be a sensible choice.

2. What is replication?

With replication, data is persisted in SAP Datasphere so that analytical queries can work against the local copy.

Conceptually:

Source System → Replication → SAP Datasphere → Query

Replication is often preferable when:

• The dataset is large.

• The same data is queried frequently.

• Complex transformations or joins are required.

• Analytical performance is important.

• The source system should not be repeatedly queried by reporting workloads.

• Some latency is acceptable.

For example, consider a sales reporting model containing several years of transactional data.

Repeatedly accessing the source system for every analytical query may introduce unnecessary load and performance challenges. Persisting the required data in Datasphere can provide a more predictable analytical experience.

SAP's current best-practice guidance similarly recommends considering replication when data needs to be modeled, transformed or repeatedly accessed, particularly when complex processing is involved.

3. The mistake: treating virtualization and replication as an “either/or” decision

In real projects, the best architecture is often a combination of both.

For example:

DataRecommended approachSmall master data requiring current valuesVirtualizationFrequently queried transactional dataReplicationLarge historical dataReplication / appropriate storage strategyData requiring complex transformationsReplicationReal-time operational informationVirtualizationFrequently reused analytical datasetsReplicationData that would put significant load on the source systemReplication

The objective is not to minimize replication at any cost.

The objective is to create the right balance between freshness, performance, cost and source-system workload.

4. Ask these five questions before choosing

Question 1: How fresh must the data be?

If the business requires the latest possible source values, virtualization may be appropriate.

If the business can work with scheduled updates or some latency, replication becomes more attractive.

Business requirement should drive the architecture—not the technology preference.

Question 2: How frequently will the data be queried?

A dataset accessed occasionally is very different from a dataset used by hundreds of users throughout the day.

If the same large dataset is repeatedly accessed, persisting the data can reduce repeated source-system access and improve analytical performance.

Question 3: How large is the dataset?

Data volume matters.

A small master-data table and a multi-billion-row transaction table should not automatically follow the same design pattern.

Large datasets require careful consideration of:

• filtering,

• partitioning,

• historical data,

• storage,

• refresh frequency,

• query patterns,

• and workload.

Question 4: How much processing is required?

If the data needs significant transformation, joins, unions or business logic before it can be consumed, persistence in Datasphere can make the overall architecture more practical.

SAP's best-practice guidance also recommends reducing data early, pushing filters toward the source where appropriate, optimizing joins and avoiding unnecessary calculations.

Question 5: What is the impact on the source system?

This is one of the most important questions.

A technically valid virtual model may still be a poor architecture if it generates significant workload on an operational SAP system.

Always consider:

Who is paying the performance cost of the query?

If the answer is the source system, replication may be the better architectural choice.

5. A practical architecture pattern

A useful approach is to think in layers.

Source Systems

↓

Data Acquisition

↓

Reusable / Harmonized Data

↓

Business Models

↓

Analytical Consumption

Not every layer needs to physically persist every dataset.

For example:

S/4HANA

→ Virtual master data

→ Replicated sales transactions

→ Harmonized sales model

→ Analytical Model

→ SAP Analytics Cloud

This avoids blindly replicating everything while still providing a performant analytical foundation.

6. Don't carry the old BW mindset into Datasphere

For teams coming from SAP BW, this is an especially important consideration.

In traditional BW architectures, data is often persisted at several layers because of the architecture and processing requirements.

In Datasphere, you have more flexibility.

That does not mean:

“Never replicate data.”

It also does not mean:

“Replicate everything like BW.”

Instead, every persistence decision should have a reason.

Ask:

Why does this data need to be persisted?

Possible answers include:

• Performance

• Source-system protection

• Transformation

• Reusability

• Query frequency

• Data volume

• Historical analysis

If there is no clear reason, reconsider the design.

7. A simple decision framework

A useful starting point is:

Need near-real-time data?
→ Consider virtualization.

Large dataset queried frequently?
→ Consider replication.

Complex transformation required?
→ Consider persistence and transformation in Datasphere.

High workload on source system?
→ Consider replication.

Small dataset with low query volume?
→ Virtualization may be sufficient.

Frequently reused analytical dataset?
→ Consider creating a reusable persisted layer.

These are guidelines, not absolute rules.

Final Thoughts

SAP Datasphere gives architects more flexibility in deciding where data should live and how it should be consumed.

The best architecture is rarely:

“Virtualize everything.”

It is also rarely:

“Replicate everything.”

A better approach is to evaluate each important dataset based on:

Freshness + Performance + Volume + Transformation + Source-System Impact

Once these factors are understood, the virtualization-versus-replication decision becomes much easier.

At Seestron, we approach SAP Datasphere architecture from both the SAP BW/4HANA perspective and the modern cloud data-platform perspective, helping organizations design models that balance performance, maintainability and business requirements.

Have a Datasphere architecture question? Contact Seestron to discuss your use case.