Data Virtualization and the Semantic Layer: Query Without Copying

Data virtualization lets you query data where it lives. Instead of copying data to a central location, you connect to each source and issue queries directly. A virtualization engine translates your SQL into the source's native protocol (JDBC for databases, S3 API for object storage, REST for SaaS), retrieves the data, and combines results from multiple sources into a single result set.

From the user's perspective, all data appears in one unified namespace. A PostgreSQL production database, an S3 data lake full of Parquet files, and a Snowflake analytics warehouse all look like tables in the same catalog.

The keyword is "no replication." The data stays where it is. The queries go to the data, not the other way around.

What a Semantic Layer Adds on Top

Virtualization solves the access problem. But access without context is dangerous. Raw access to 50 federated sources means 50 sources where analysts can write conflicting metric formulas, join tables incorrectly, and query sensitive columns without authorization.

A semantic layer added on top of virtualization provides:

• 
  Metric definitions: "Revenue" is calculated the same way regardless of which source the data comes from


• 
  Documentation: Wikis describe what each federated table and column represent in business terms


• 
  Join paths: Pre-defined relationships prevent analysts from guessing how tables connect


• 
  Access policies: Row-level security and column masking enforced at the view level, even for sources that have no fine-grained access controls of their own

The combination is powerful: you get real-time access to all your data (virtualization) with consistent meaning and governance (semantic layer), and without data movement (no ETL).

Why They're Stronger Together

Each technology is useful alone. Together, they cover gaps neither can fill individually:

is built on this architecture natively. It combines a high-performance virtualization engine (supporting 30+ source types including S3, ADLS, PostgreSQL, MySQL, MongoDB, Snowflake, and Redshift) with a full semantic layer (virtual datasets, Wikis, Labels, Fine-Grained Access Control).

A practical query flow:

1. An analyst queries business.revenue_by_region — a virtual dataset (view)


2. Dremio's optimizer determines that this view joins data from PostgreSQL (customer records) and S3/Iceberg (order transactions)


3. Predicate pushdowns push filter logic to each source (e.g., date range filters applied at the source)


4. Results are combined using Apache Arrow's columnar format (zero serialization overhead)


5. Row-level security filters the results based on the analyst's role


6. If a Reflection (pre-computed copy) exists, Dremio substitutes it transparently for faster performance

The analyst sees one table. Behind it, two sources, one semantic layer, and automatic performance optimization.

When to Virtualize vs. When to Materialize