Reordering dbt BigQuery cluster columns can break a table rebuild

A dbt v2 issue shows a BigQuery table model failing when the cluster_by columns are reordered without changing their members. Fusion sends CREATE OR REPLACE TABLE without first dropping the existing table; BigQuery rejects the changed specification. The reporter reproduced this on 2.0.9 locally and 2.0.11 in a platform job.

Why order is a real change

dbt's BigQuery configuration accepts multiple clustering columns as a list. BigQuery documents clustering as a table property, so a reordered list belongs in a physical-change review. The error text may mention “partitioning spec” even if the table has no partition. Do not conclude from that wording alone that the partition setting changed.

Compare planned and actual DDL

In a development dataset, build the current model, change only cluster order and inspect the generated job sequence. The report says an order-only change omits the drop step, while changing the set of columns triggers one. Save the dbt version and BigQuery job ID. This is a release-specific reproduction, so verify it against the engine version you actually run.

Plan a safe rebuild

If the table must be recreated, agree on the backfill, permissions, dependent views and cutover window before a manual drop. An alternative is to defer the order-only change until the adapter path is confirmed fixed. Validate table row counts and key queries after the rebuild. A passing SQL compile does not prove the DDL transition will succeed.

Adovo’s view

Physical design changes are deployments, even when the model SQL stays the same. Put the warehouse transition and recovery plan beside the dbt configuration change. The cost of a failed rebuild is paid by every downstream reader.