General architecture

General architecture#

Querona is a Data Fabric platform, powered by data virtualization, that allows all applications to use data from multiple, heterogeneous data sources. Data is accessed and integrated in real-time across distributed data sources without copying or moving data from its source.

A typical Querona solution is assembled in layers, shaping data progressively from raw sources into a published, business-ready model — and never copying it out of a source unless you choose to materialize it. Each layer builds on the one before it:

  • Connect to the sources. A data source connection establishes access to a source system (a database, file, API or SaaS application) through a data provider.

  • Expose source objects as virtual tables. Virtual tables wrap individual source objects as metadata-only relational tables inside a virtual database, with no data copied.

  • Integrate with views. Views combine, clean and reshape that data into a canonical, business-oriented model. When needed, a virtual database’s views can be materialized into the engine that backs it.

  • Publish to consumers. Curated views and data services expose the integrated model to reporting tools, applications and other consumers through a single, SQL Server–compatible endpoint.

Querona architecture and data flow Consumers connect through the data endpoints to the Querona server, which runs on your infrastructure; administrators and operators manage and monitor it through a separate Web admin portal; it reads from data sources — relational and NoSQL/big-data systems, data warehouses, SaaS and REST APIs, files, data lakes, business apps and streaming, with detailed audit events emitted to a separate (optionally off-site) audit store — over their native protocols and pushes predicates and data down to them; external storage and compute engines — Apache Spark (built-in) plus SQL Server, Azure SQL, StarRocks, Vertica, PostgreSQL, MySQL and more — materialize and offload on the side; security and governance are cross-cutting across the server. Consumers BI & reporting SQL clients Applications Web & AI agents Endpoints SQL Server endpoint TDS v7 · TDS v8 Data API REST · GraphQL · MCP Querona server — runs on your infrastructure Parser & planner Federation & execution Columnar processing in-memory Materialize & cache Jobs & scheduling Metabase metadata · stats · creds Security & governance authentication · row-level security · masking · pseudonymization Data sources Relational NoSQL & big data Data warehouses SaaS & REST APIs Files Data lakes Business apps Streaming Storage & compute Apache Spark built-in External engines SQL Server · Azure SQL · StarRocks · Vertica · PostgreSQL · MySQL + more materialize · offload read (native protocols) push down predicate and data Audit store detailed events off-site optional Users Administrators Management Web admin & monitoring

Components and data flow#

Consumers connect through one of Querona’s endpoints; the Querona server parses, plans and executes each query directly against the data sources, pushing work down to them. Internally the server is a columnar engine: incoming rows are converted to a columnar format for high-parallelism processing, and results are converted back to rows for the SQL Server (TDS) protocol. External storage and processing engines are used on the side — to materialize data and to offload query processing. Security is cross-cutting across the whole server.

The view layers#

Within a virtual database, objects are usually arranged into a progression of layers, each building on the one before it:

  • Base tables — virtual tables that map directly to objects in the source systems.

  • Intermediate views — technical views that join, filter and normalize base tables.

  • Canonical views — views that present data in a consistent, business-friendly model, independent of how any individual source happens to store it.

  • Reporting views, extraction views and data services — the publishing layer consumed by BI tools, data pipelines and applications.

This layering keeps source-specific details isolated at the bottom, so changes to a source system ripple no further than the base and intermediate layers, leaving the canonical and publishing layers — and the consumers that depend on them — unaffected.

See also#