QlikToDax

Extract.qvf → QVD layer 1 → Transform.qvf → QVD layer 2 → app

QVD layers (extract, transform, model) to Fabric in Power BI

The classic multi-tier QVD architecture maps to Fabric's medallion lakehouse: raw data (bronze) → cleaned (silver) → modelled star schema (gold), with a semantic model on top. Without Fabric, Power BI dataflows are the reuse layer, but they are not a full QVD replacement.

Partial / different approach Fabric Power Query Power BI service

Short answer: Extract QVDs → bronze Delta tables (pipelines or Dataflow Gen2). Transform QVDs → silver/gold tables (notebooks, SQL or dataflows). Model app → one shared semantic model, ideally Direct Lake on the gold tables. Dashboard apps → thin reports on that model.

What it does in Qlik

Qlik teams usually split loading into extract apps (one QVD per source table), transform apps (business rules, joins, incremental merge), and a data model app that UI apps binary-load. QVDs are fast, reusable files on a share.

Qlik example

Qlik script
// Layer 1: Extract.qvf
Orders: SQL SELECT * FROM dbo.Orders;
STORE Orders INTO [lib://QVD/1_Extract/Orders.qvd] (qvd);

// Layer 2: Transform.qvf
Orders: LOAD *, ApplyMap('Map_Region', CountryCode) AS Region
FROM [lib://QVD/1_Extract/Orders.qvd] (qvd);
STORE Orders INTO [lib://QVD/2_Transform/Orders.qvd] (qvd);

// Layer 3: Dashboard.qvf
Binary [lib://Apps/Model.qvf];

Power BI equivalent

Fabric mapping

  • 1_Extract QVDs → bronze lakehouse tables, loaded by a pipeline Copy activity or Dataflow Gen2
  • 2_Transform QVDs → silver and gold tables, built with notebooks, warehouse SQL or Dataflow Gen2
  • Model app → a semantic model on the gold tables (Direct Lake or Import)
  • Binary UI apps → thin reports connected live to that model

Gold table in Spark SQL

SQL
CREATE OR REPLACE TABLE gold.fact_orders AS
SELECT o.*, m.Region
FROM silver.orders o
LEFT JOIN silver.map_region m ON o.CountryCode = m.CountryCode;

Gotchas and behaviour differences

  • Don't recreate one semantic model per old QVD. The QVD layer becomes tables; the semantic model layer should be one (or few) shared star schemas.
  • Power BI dataflows (Gen1) store data, but other reports can only read them through Power Query, so they are slower to reuse than QVDs. Fabric lakehouse tables are the closer match.
  • Fabric requires capacity (F SKU or a trial). Without it, the realistic pattern is SQL views or a database as the reusable layer, plus Import semantic models with incremental refresh.
  • Qlik "optimized QVD loads" have no direct counterpart. Performance comes from Delta/Parquet and query folding instead.

Official documentation

Related pages

STORE Orders INTO [lib://Data/Orders.qvd] (qvd); STORE INTO (writing QVDs) Power Query in Power BI Desktop can't write files. A query only feeds the model. Qlik's STORE pattern, transforming once, saving a QVD and reusing it, maps to Fabric: a Dataflow Gen2 with a data destination such as a Lakehouse table, a notebook writing Delta tables, or a Power BI dataflow that other models connect to. A Power BI dataflow (Gen1) only needs Pro licences, but it stores its output internally, not as files you manage. Without Fabric, the most robust answer is to store in your database or SQL views. Partial / different approach WHERE Modified >= '$(vLast)' ... Concatenate ... WHERE NOT Exists(ID); STORE ... INTO x.qvd QVD incremental load The QVD incremental pattern (load the changes, append the old QVD rows not in the change set, store) has no file-level equivalent in Power BI. Use the incremental refresh policy on the semantic model, or in Fabric land the data in a Delta table with MERGE. Partial / different approach ApplyMap('MapName', expr [, default]) Mapping Load and ApplyMap ApplyMap looks up a value in a two-column mapping table during load. In Power BI, use a merge in Power Query, a record lookup, or simply a relationship with RELATED. The behaviour differs for case sensitivity, duplicates and missing keys. Partial / different approach Scheduled reloads, reload tasks and task chains Reload schedules and tasks A Qlik reload becomes a semantic model refresh in the Power BI service. On-premises sources need an on-premises data gateway. Chained tasks (load QVDs, then the app) become a Fabric Data Factory pipeline or an API-driven sequence. Partial / different approach $Syn tables (automatic) Synthetic keys and associative linking Qlik links tables automatically on every field with the same name and builds synthetic keys when they share several fields. Power BI doesn't link on every shared name. Relationships are model objects (autodetect may suggest some from matching names at load, so check them), use a single column and have a direction, so migrations usually remodel to a star schema. No 1:1 equivalent

Spotted an error or a better pattern? QlikToDax is maintained by a working BI consultant; corrections are welcome via the About page. Last reviewed 2026-10-25.