dbt cluster_by on Snowflake: the ORDER BY it adds

Setting cluster_by on a dbt Snowflake model does 2 things: when dbt creates the table, it sorts the whole result with an ORDER BY on those columns, and then it adds them as the table's clustering key. dbt documents the sort as intended, so that the table starts out clustered. The catch is when the whole table is built: a large table model sorts all its rows on every run, and an incremental model sorts everything on each --full-refresh. Keep cluster_by only where the clustering earns that sort.

What dbt sends to Snowflake

For a model like this:

{{ config(materialized='table', cluster_by=['order_date']) }}

select order_id, customer_id, order_date, amount_usd
from {{ ref('stg_orders') }}

dbt-snowflake's create table macro wraps your query in a sort and clusters the table afterwards. The SQL it runs has this shape:

create or replace table analytics.marts.orders as (
    select * from (
        select order_id, customer_id, order_date, amount_usd
        from analytics.staging.stg_orders
    )
    order by (order_date)
);

alter table analytics.marts.orders cluster by (order_date);

Without cluster_by, the same model is a plain create or replace table ... as (select ...), with no sort. dbt's own docs show this example and explain the reason: a table built in key order leaves Snowflake's automatic clustering less to do afterwards.

When the sort runs

From dbt-snowflake's code as of this writing:

So the cost lands where the issue reporters found it: a full refresh of a big incremental model, and, less noticed, a big table model that rebuilds every night.

create or replace table analytics.marts.orders as (
    select * from (
        select order_id, customer_id, order_date, amount_usd
        from analytics.staging.stg_orders
    )
    order by (order_date)
);

alter table analytics.marts.orders cluster by (order_date);

Why it costs credits

Sorting 2 billion rows is far more work than writing them. A sort of that size needs the warehouse's memory, and when that runs out the data spills to local and then remote disk, which Snowflake's query history records for each statement. The build runs longer, and a longer build is more credits on the same warehouse, or a larger warehouse to keep it on time.

The sort also buys something. Without it, Snowflake's automatic clustering would reorganise the new table in the background, and that uses credits too. Which costs more depends on the table: we have not measured it, and the dbt issue gives no figures. Measure on your own table (below).

See it in your own project

dbt compile shows only your SELECT. The ORDER BY is in the statement dbt runs:

1. Run the model: dbt run -s orders.
2. Open target/run/<your_project>/models/.../orders.sql. The create or replace table with order by is there.

To compare the cost, find the builds in Snowflake's query history:

select start_time, warehouse_size,
       total_elapsed_time / 1000 as seconds,
       bytes_spilled_to_local_storage, bytes_spilled_to_remote_storage
from snowflake.account_usage.query_history
where query_text ilike '%create or replace%table analytics.marts.orders%'
order by start_time desc
limit 20;

Run it after a build with cluster_by and after one without (on a dev target); the view can lag by up to 45 minutes. Spill to remote storage is the sign the sort is the expensive part.

Find every model with cluster_by

After dbt parse, the manifest lists every model's config:

jq -r '.nodes[] | select(.resource_type == "model" and .config.cluster_by != null)
  | [.name, .config.materialized, (.config.cluster_by | tostring)] | @tsv' target/manifest.json

The list shows each model's materialization, so the table models, which sort on every run, stand out.

Your options

1. Drop cluster_by where clustering does not pay. Clustering is usually worth it only on tables of several terabytes, queried often with filters on the key, and changed rarely. A 50 GB mart gains little from it and pays for the sort every run.
2. Make a big clustered table incremental. The sort then happens only on the first build and on full refreshes, and you choose when those run.
3. Full-refresh less, and on purpose. Run --full-refresh for one model when its logic changes, not as part of a routine job, and on a warehouse sized for it.
4. Keep the clustering key, skip the sort. Set the key yourself in a post-hook (alter table {{ this }} cluster by (order_date)) and remove cluster_by, so automatic clustering does the ordering in the background. You trade the build-time sort for background clustering credits, so measure both.
5. Override dbt's macro. dbt looks for dispatched macros in your project first, so a snowflake__create_table_as in your macros/ folder replaces the adapter's. It works, but you own a copy of dbt-snowflake's code and must check it on every upgrade; options 1 to 4 are easier to live with.

Keep or drop: a check per model

• Is the table several terabytes, or heading there within the year?
• Do the slow queries on it filter or join on the cluster_by columns?
• Is it read far more often than it is rebuilt?
• Is it incremental, so the sort runs only on a full refresh?

4 yeses: keep it. A no on the first 2: drop it. A table model with 4 yeses on the rest: make it incremental.

Where to follow it

The report is dbt issue 16685, open and awaiting triage as of 19 October 2026. Since dbt's docs describe the sort as intended, a change, if one comes, is more likely to be a setting to turn it off than a removal. Watch the dbt-snowflake changelog.

For the warehouseData WarehouseA database built for analysis: cleaned, structured data from many systems, kept in one place and shaped for fast reports and dashboards. bill itself, the Snowflake cost calculator prices a warehouse by size, hours and idle time before suspend.