LOAD ... RESIDENT table; DROP TABLE table;

Resident load and intermediate tables in Power BI

A Resident load reads a table already in memory. The Power Query equivalent is a referenced query, but it re-runs its source instead of reading from memory. Heavy multi-step transformations are better done upstream in a warehouse, dataflow or lakehouse.

Partial / different approach Power Query DAX Fabric

Short answer: Right-click a query and choose Reference. Turn off Enable load on the intermediate one, which replaces DROP TABLE. For data derived from model tables, a DAX calculated table also works.

What it does in Qlik

LOAD ... RESIDENT Orders reads rows from a table loaded earlier in the same script, often with WHERE, GROUP BY or ORDER BY. The intermediate table is then removed with DROP TABLE. Data is read from RAM, so the source is not queried again.

Qlik example

Qlik script

Raw: LOAD * FROM [lib://Data/orders.qvd] (qvd);

Orders:
NoConcatenate
LOAD OrderID, CustomerID, Amount RESIDENT Raw WHERE Status = 'Closed';

DROP TABLE Raw;

Power BI equivalent

Referenced query

Power Query M

// Query "Raw" (Enable load = off)
let Source = Sql.Database("server", "db"), Orders = Source{[Schema = "dbo", Item = "Orders"]}[Data] in Orders

// Query "Orders" = Reference of Raw
let
    Source = Raw,
    Closed = Table.SelectRows(Source, each [Status] = "Closed"),
    Cols   = Table.SelectColumns(Closed, {"OrderID", "CustomerID", "Amount"})
in
    Cols

DAX calculated table

DAX

Customer totals =
SUMMARIZECOLUMNS ( Orders[CustomerID], "Amount", SUM ( Orders[Amount] ) )

Gotchas and behaviour differences

Performance. Each query that references Raw can evaluate the source again; there is no shared in-memory table. With SQL sources, folding usually keeps this cheap. With files or APIs, consider a dataflow (Gen2) or a lakehouse table as the staging layer.
Calculated tables use memory and are computed after every refresh. Don't use them for big transformations.
NoConcatenate is needed in Qlik because the new table has the same fields as Raw. Power Query has no automatic concatenation, so there is no equivalent.

Official documentation

Loading data from a previously loaded table (Qlik Help)
Referencing queries (Power Query best practices) (Microsoft Learn)
SUMMARIZECOLUMNS function (DAX) (Microsoft Learn)

LOAD ..., Sum(x) RESIDENT t GROUP BY ... Group By in the load script GROUP BY in a Qlik load pre-aggregates a table. Power Query's Group by (Table.Group) is the direct equivalent. In Power BI you often don't need it at all, because measures aggregate at query time. Direct equivalent Concatenate [(table)] LOAD ... Concatenate (append tables) Concatenate appends rows to an existing table. Qlik also does this automatically when field sets match. Power Query's Append queries (Table.Combine) matches columns by name and fills missing ones with null. Direct equivalent 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

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.