Quickstart

Go from a fresh Querona instance to querying live data through one SQL Server–compatible endpoint — with no data moved — in a few minutes. You connect a data source, create a virtual database over it, and run a standard T-SQL query against it.

For the concepts behind this, see Data virtualization.

Before you start

• A running Querona instance. If you don’t have one yet, follow Installation, then enter your license as described in Post-installation configuration.

• A data source to connect to — for example a SQL Server, Oracle, PostgreSQL or MySQL database.

Log in

Open the Querona web interface and sign in. The installer creates a default administrator account:

• Username: admin

• Password: admin

Change the admin password after first sign-in. On domain-joined installations you can also sign in with your Active Directory credentials as MyDomain\MyUserName (the local administrators group is granted access by default).

Step 1 — Connect a data source

In the GUI

1. From Quick actions on the dashboard, click ADD SOURCE CONNECTION.

2. Enter a connection name, pick the data source provider (for example SQL Server or Oracle), and click Next.

3. Fill in the provider-specific parameters (usually a server name or URL) and the authentication details.

4. Click Test, then CREATE.

In SQL

Create the connection with sp_addlinkedserver (the parameters vary by provider):

-- create the connection to the source
EXEC sp_addlinkedserver
    @server     = 'MyConnection',
    @srvproduct = 'SQL Server',
    @datasrc    = 'sqlhost',          -- host, or host:port
    @catalog    = 'MyDatabase';       -- source database

-- supply the credentials the connection authenticates with
EXEC sp_addlinkedsrvlogin
    @rmtsrvname  = 'MyConnection',
    @useself     = 'FALSE',           -- use the login below, not the service account
    @rmtuser     = 'sql_user',
    @rmtpassword = 'sql_password';

The detailed reference is in Create a connection. This short demo shows the connection and virtual-database steps end to end:

Step 2 — Create a virtual database

In the GUI

1. Go to DATABASES and click ADD DATABASE.

2. Name the virtual database, choose the connection you just created, and click Next.

3. If the provider requires a source database (the SQL Server provider does), select it and click Next.

4. Querona extracts the source metadata (only metadata — no data is copied) and presents it as tables and columns. Select the tables you want and click CREATE. Source data types are mapped automatically to SQL Server–compatible types.

In SQL

Create the virtual database over your connection — this imports the source metadata:

CREATE DATABASE [MyVdb] WITH CONNECTION = [MyConnection];

To map individual source objects yourself, use CREATE VIRTUAL TABLE; see also CREATE DATABASE.

See Create a virtual database for the full reference.

Step 3 — Run your first query

Open the built-in query editor — or point SSMS, Azure Data Studio or any SQL Server client at the instance — and query your virtual database with ordinary T-SQL:

SELECT TOP 10 *
  FROM MyVdb.dbo.Customers;     -- replace with a table you imported in Step 2

The rows come straight from the source, read live at query time — nothing was copied or moved. From here you can filter, aggregate and join across this and any other connected source using standard SQL, all through the same endpoint.

That’s the core of Querona: your existing SQL tools, one endpoint, every source.

Build solutions in layers

A typical solution is a chain of virtual databases, each adding a layer — the same idea as the medallion pattern:

• Pass-through — one virtual database per source: the virtual SQL Server–compatible bridge, giving direct live access with no copy. (This is what you built in Step 2.)

• Bronze — materialize the raw data as-is, when keeping a copy helps.

• Silver — views integrate, clean and conform the data into a canonical model.

• Gold — views serve a business- and reporting-ready model to consumers.

Every virtual database except pass-through declares a materialization engine — a required setting that is used only when you materialize a view (materialization is selective). Two virtual databases can share an engine, co-locating their data so joins run locally; or each can use a different one. Every layer therefore runs on the engine that suits it — mixed and swapped freely, transparently to the consumers querying it.

What’s next

• Join across sources — the heart of data virtualization; see Federation.

• Connect your BI tools — Power BI, Tableau, Excel, SSMS: Client Connectivity.

• Speed it up with materialization — materialize hot views (built-in Apache Spark): Materialization.

• Shape and integrate your model — normalize schemas, add keys, build canonical views: Managing tables, Managing views.

• Secure your data — permissions, row-level security and masking: Access rights.