Not every tool can query the Semantic Layer. Exports bridge the gap: dbt platform runs a saved query after your models are built and writes the result to a table or view in the warehouse. The metric logic stays in dbt; the tool reads an ordinary table.

Copy and paste

The export, on the saved query:

saved_queries:
  - name: monthly_sales_by_country
    description: Revenue and orders by month and country since 2026.
    label: Monthly sales by country
    query_params:
      metrics: [revenue, order_count]
      group_by:
        - TimeDimension('metric_time', 'month')
        - Dimension('customer__country')
    exports:
      - name: monthly_sales_by_country
        config:
          export_as: table          # or view
          schema: reporting         # optional: defaults to the environment's schema
          alias: sales_monthly      # optional: defaults to the export name

Turn exports on for the production environment: in dbt platform, Orchestration → Environments → your environment → Environment variables, add

DBT_ENGINE_EXPORT_SAVED_QUERIES = TRUE

Run them in the deploy job, after the models they read:

dbt build                            # builds models, then the saved queries downstream of them
dbt build --select orders+           # only what depends on orders, exports included

Test in development with the dbt Cloud CLI (outside dbt v2):

dbt sl export --saved-query monthly_sales_by_country
dbt sl export-all

In the Studio IDE or any environment on dbt v2, run dbt build with the variable set instead.

How it runs

With the variable set, saved queries become part of dbt build, in DAG order: a saved query runs after the models it depends on. The dbt platform’s MetricFlow server compiles the SQL and runs a create table (or create view) in your warehouse, with the environment’s credentials, so the data stays in your data platform.

With dbt Core, the same dbt build finds the saved query and reports it as a no-op (NO-OP=1): there is no MetricFlow server to run the export, and no table is written. Exports are a dbt platform feature, on Starter and Enterprise plans.

Table or view

A saved query can have several exports with different names, schemas or types, for example a table for a dashboard and a view for analysts.

Costs and limits

Running an export counts as queried metrics for billing; reading the resulting table does not. The table holds exactly the grain of the saved query: users who need another breakdown have to aggregate it again, which is safe for sums and counts and wrong for distinct counts, averages and ratios. For flexible analysis, connect the tool to the Semantic Layer instead.

The saved query was tested with dbt Core 1.12 and MetricFlow 0.213 on DuckDB, where dbt build reported it as a no-op; the export steps come from the dbt documentation (October 2026).

References