What is data virtualization?
A technique that queries data across multiple sources as one, without copying it: a middle layer translates the query in real time.
Data virtualization is the technique that lets you query data from different sources, a transactional database, a data warehouse, a SaaS application, as if they were a single source, without physically copying them into a central repository. A middle layer receives the query, translates it in real time into each source's own language, queries every system at the moment the request is made, and reassembles the result into one answer. Whoever writes the query does not need to know where each piece of data physically lives, or manage separate connections for every system: they see one logical schema, even when five different systems with incompatible formats and protocols sit behind it. It is the opposite approach to ETL and ELT, which physically copy data into a new repository before making it queryable: here the data stays where it was born, and the query reaches it at the exact moment it runs, without going through an intermediate copy.
The key difference from ETL/ELT
ETL and ELT physically copy data into a new place, typically a data warehouse, before it becomes queryable: the data is duplicated, but the queries that follow are fast and do not depend on the original source's availability at the time they run. Virtualization does the opposite: it copies nothing, data stays where it was born and is fetched at the exact moment of the query. The upside is zero duplication and a result that is always current in real time, because there is no copy that can go stale between loads. The flip side is that performance depends entirely on the original source: if it is slow, overloaded or unreachable at that moment, the query will be too.
When it makes sense
Virtualization pays off when data must stay current in real time without the delay of an ETL pipeline that runs once a day or once an hour, when you need fast, temporary access, perhaps for a one-off analysis, without building a permanent copy infrastructure for a need that lasts a few weeks, or when copying the data is simply not possible, for example due to regulatory constraints on data residency that prevent moving it outside a jurisdiction or a specific system.
The honest limit
Data virtualization does not replace a data warehouse for heavy, repeated analytical workloads. Querying the original source every single time is slower and more fragile, sensitive to performance dips or temporary unavailability of the source, than querying a copy already optimized for analysis. On a dashboard hit hundreds of times a day by dozens of users, the copy wins almost every time: virtualization is built for point-in-time access, not for sustained load.
The link to data fabric
A modern data fabric often uses virtualization as one of the technologies it automates under the hood, alongside active metadata and access orchestration. But the data fabric is the overall architecture that decides when and how to connect sources; virtualization is just one of the techniques that makes it possible, the same one that can be adopted on its own, with a dedicated tool, without building an entire fabric.
Why it matters for a business
The choice between copying data with ETL/ELT and querying it in place with virtualization is not ideological: it depends on how much data freshness matters relative to query speed and stability. A company that needs to quickly join data from a newly acquired system, without waiting months for integration, gains from virtualization; one building recurring reports on large volumes gains from copying. The two techniques are not mutually exclusive: they often coexist in the same stack, each used where the freshness-versus-speed trade-off makes it the right choice.
Related terms
- Data fabric · A metadata-driven architecture that automates data integration and delivery across different environments.
- ETL vs ELT · Same three steps, different order: ETL transforms data before loading it, ELT loads it raw and transforms it inside the destination platform.
- Data residency · The physical location where data is stored and processed. It says where data resides, not who can be compelled to hand it over: it is not sovereignty.
- Trino and Presto · Distributed SQL query engines that separate compute from storage to query multiple sources without moving data.
- Database-per-service · Each microservice owns its own datastore and no other service reads it directly, only through its exposed interfaces.
A term that hits close to home? Let's talk.
CONTACT ME