Virtual tables and views

Virtual tables and views#

Querona lets you model your data with three kinds of object: a virtual database that contains virtual tables and views. Together they are the building blocks you work with — one logical, SQL-accessible model layered over your sources, with nothing copied until you choose to materialize it. This page explains what each object is and how they relate; for why the approach works this way, see Data virtualization.

Virtual database#

A virtual database (VDB) is a container. It groups schemas, virtual tables and views and presents them through a single SQL Server–compatible surface, so a consumer queries it like one ordinary database. Sources stay autonomous and in place — nothing is copied out unless you materialize it.

A virtual database comes in two kinds, which differ in how they relate to sources:

a pass-through virtual database maps to a single source and sends every query straight to it, translated into that source’s SQL dialect or API — nothing is materialized.
an integration virtual database can combine several sources and materialize their data in a processing engine. It federates across those sources at query time — routing each part of a request to the systems that hold the data — and its backing engine is what makes materialization (below) possible.

An integration VDB is backed by a DBMS — for example Apache Spark, StarRocks, SQL Server or another supported engine. The backing engine influences which features are available, such as indexing and materialized views. Different virtual databases can be backed by different engines and mixed in one solution; see Data virtualization and Materialization.

Virtual table#

A virtual table is a metadata-only object that wraps an existing object in a source system — typically a table or view, the tabular result of a query, or even a file or an API call. It looks and behaves like a relational table but holds no data of its own: queries against it — and updates, where the source supports them — are translated into operations on the object it wraps.

A virtual table that maps one-to-one to a single source object is a base table. Because a base table’s data physically lives at the source, it cannot be materialized directly — you materialize a view built on top of it instead.

For schema-less or loosely-typed sources such as files and some APIs, Querona infers a relational schema during metadata import, which you can refine afterwards. Creating and editing virtual tables is covered in Tables and the CREATE VIRTUAL TABLE statement.

Views#

A view is a saved SQL query that Querona computes on demand and presents as a virtual table. Views are the main tool you model with: you join, filter, clean and reshape virtual tables into a canonical, business-friendly model, expressed entirely in SQL. A view behaves like a view in any DBMS; the one difference is where a materialized view’s data is stored (below). Because a view is just a query, evolving your model usually means editing a view rather than rebuilding a pipeline. See Views.

Materialized views#

When a view is queried often or is expensive to compute, you can materialize it. A materialized view stores the view’s results as a physical table inside the virtual database’s backing engine, so reads are served from that fast store instead of recomputing against the sources every time. Materialized views can include filters, joins and aggregations, and you can index them; they are refreshed fully, incrementally, or on demand, depending on how fresh the data must be. Materialization is what blends the freshness of virtualization with warehouse-class speed — for the strategies and how to configure them, see Materialization.

How they fit together#

A base virtual database wraps each source; an integration virtual database then combines them into one model that consumers query through a single endpoint:

        flowchart BT
    SRC1[(Data source 1)]
    SRC2[(Data source 2)]
    subgraph VDB1["Virtual database 1"]
        BT1[Base virtual table]
        BT1B[Base virtual table]
    end
    subgraph VDB2["Virtual database 2"]
        BT2[Base virtual table]
    end
    subgraph VDB3["Virtual database 3 (integration)"]
        V3["View: join, clean, reshape"]
    end
    SRC1 --> BT1
    SRC1 --> BT1B
    SRC2 --> BT2
    BT1 --> V3
    BT1B --> V3
    BT2 --> V3
    V3 --> OUT["Consumers: SQL, REST, GraphQL, MCP"]

Object	What it is	Stores its own data?	Computed
Base table	A virtual table mapping one-to-one to a source object	No — data stays at the source	Read live, on every query
View	A saved SQL query over other tables and views	No, unless materialized	On demand, at query time
Materialized view	A view whose results are materialized in the backing engine	Yes — a physical copy in the virtual database	Precomputed; refreshed full / incremental / on demand