Querona for SQL Server users#

If you work with Microsoft SQL Server, Azure SQL or Microsoft Fabric, you already know most of Querona. It speaks the TDS protocol and Transact-SQL, so the tools, drivers and skills you use today work against Querona with little or no change.

Think of Querona as the essentials of those Microsoft data tools — SQL Server, PolyBase, linked servers, SSIS, SQL Agent, Azure SQL, Synapse, Data Factory and Fabric — in one tool you already know how to drive. Architecturally it is a Logical Data Warehouse: a single governed, SQL-accessible layer over your distributed data, materialized only where it is actually needed — not a copy-everything-first warehouse.

Your skills transfer#

Your Microsoft data skills apply directly:

  • Your tools — connect with SQL Server Management Studio (SSMS), Azure Data Studio, sqlcmd, or any application that uses an ADO.NET, OLEDB or ODBC SQL Server driver.

  • Transact-SQL — write the SELECT statements, joins, GROUP BY, window functions and CREATE VIEW you already know. See the Transact-SQL reference.

  • Catalog and DMVs — query the sys.* catalog views and dynamic management views much as you do today.

  • Scheduling — schedule jobs with the same sp_add_job / sp_add_schedule procedures; the interface and behaviour are close, though there is no separate SQL Agent service.

  • Security — roles and permissions, row- and column-level security and data masking, configured centrally; close to what you know, with some differences in the details.

  • BI tools — point Power BI, Tableau and Excel at Querona as you would a SQL Server instance (see Client Connectivity).

  • Linked servers — register Querona as a SQL Server linked server with sp_addlinkedserver, so your existing SQL Server instances can query it.

Note

The one new idea: in SQL Server a database stores its own data — its tables live in the database’s files on disk. In Querona a virtual database stores no data of its own; its tables and views map to objects in your external sources and are resolved at query time. You write the same T-SQL, and Querona pushes the work down to the sources and combines the results.

Familiar concepts#

If you have used external tables, elastic query, linked servers or OneLake shortcuts, the mental model carries straight over:

In the Microsoft stack

In Querona

CREATE EXTERNAL DATA SOURCE / Azure SQL elastic-query source

Data source connection

CREATE EXTERNAL TABLE / external table

Virtual table and virtual views

PolyBase scale-out groups

Federation engine plus Spark materialization

Linked server (sp_addlinkedserver)

Linked server — the same procedure, supported natively

OneLake shortcuts / Fabric mirroring

Live federation — data reached in place, no copy

A user database

Virtual database (VDB)

Indexed / materialized views, columnstore, Direct Lake

Materialized view copies on the engine you choose

sys.* catalog views and DMVs

sys.* views and DMVs (see Reference)

SQL Agent jobs (sp_add_job …)

Jobs — the same sp_* stored procedures

For BI and analytics platforms#

Querona is a strong companion to Power BI, Tableau, Apache Superset and other exploration and visualization tools — not an alternative to them (it has no visualization of its own). It takes over the jobs those tools do least well and centralizes them:

  • Data integration and connectivity — rather than rebuilding connectors and data prep inside each tool, point them all at one SQL Server–compatible endpoint. Querona handles connectivity and federation; your tools just read.

  • Governance and security in one place — access control, row- and column-level security, data masking, auditing, a semantic layer of business-friendly reusable views, and metadata lineage, defined once and applied across every tool that connects.

  • A future-proof reporting backend — reports point at one endpoint and one data model (virtual databases); Querona decides where the data physically lives and computes. Because that physical layer is decoupled from what the tool sees, you can materialize hot views without touching a report, modernize or replace the engine underneath transparently, choose the right engine per model, and evaluate a new stack fast by re-materializing the same VDB on a candidate engine.

In short, Querona gives your BI and analytics tools a single, governed Logical Data Warehouse — a SQL-accessible layer over your distributed data, materialized only where it is needed. It is a companion to those tools, and an alternative to the warehouse or lakehouse you would otherwise build to feed them.

Try it with your own tools#

  1. Make sure you have access to a running Querona instance (see Installation if you need to install one).

  2. Open SSMS or Azure Data Studio and connect to the Querona host, just as you would a SQL Server instance.

  3. Create a connection and a virtual database over one of your existing sources — follow the Quickstart.

  4. Run a query that joins two different sources in one SELECT. That federated query — plain T-SQL, no data movement — is Querona in a nutshell.

Works with what you have#

Querona slots in alongside the SQL Server and Azure investments you already run. Connect them as sources, reuse your models and tools, and expose everything through one surface — no rip-and-replace required.

Next steps#