A dbt catalog flag can cost more than the BigQuery model build

A dbt customer reproduction found a BigQuery build with --write-catalog issuing one catalog query per dataset in dbt v2.0.11. In that small test, each catalog query billed about 1 GB while the model build billed about 10 MiB; v2.0.6 did not issue those queries. The ratio belongs to the reported project, not every dbt deployment.

Identify the query, not just the job total

Use BigQuery job history for a controlled run and group jobs by command, dataset and query text. Look for region-level INFORMATION_SCHEMA.TABLE_STORAGE reads alongside the actual model query. BigQuery's job metadata provides billed bytes and query details. Compare the same project, selection and permissions on the versions you intend to deploy.

Decide when catalog generation is needed

dbt documents --write-catalog as the way to create catalog.json during local v2 commands. It is a separate metadata job, not a prerequisite for every developer build. Check which downstream tool needs the artifact and how fresh it must be. Do not remove it from a production job merely to lower a test bill without confirming the effect on metadata consumers.

Gate the upgrade with a cost sample

Record billed bytes for build work and catalog work separately across representative datasets. If cost rises after the upgrade, preserve job IDs and the dbt version for support. The issue mentions macro overrides as a workaround, but a broad override can hide missing metadata; test any workaround in a copy before deployment.

Adovo’s view

Metadata has an operating cost. When a flag that makes the catalog more useful also changes the warehouse workload, measure both benefits and spend. A green build cannot tell you what the documentation query cost.