You're correct—when using Cosmos to orchestrate dbt models as individual Airflow tasks, each model run triggers the Elementary on-run-end hook, which writes to tables like dbt_run_results. In BigQuery, this can quickly exceed the DML rate limits (25 DML statements per table per 10 seconds), leading to the error you're seeing. Workarounds and Recommendations: 1. Disable Artifacts Autoupload in Hooks: You can reduce the number of DML operations by disabling the automatic upload of dbt artifacts (like dbt_models, dbt_sources, etc.) in the on-run-end hook. This is done by setting the following in your `dbt_project.yml`:

yaml    vars:      disable_dbt_artifacts_autoupload: true

Then, schedule a separate job (e.g., hourly or after all model runs) to run:

dbt run -s elementary

This approach batches the artifact uploads, reducing DML pressure during parallel model runs. However, note that result tables like dbt_run_results and elementary_test_results are still append-only and will receive inserts from each run. This may help, but may not fully resolve the DML limit if you have a very high degree of parallelism [Disable artifacts autoupload](https://slack.com/archives/C02CTC89LAX/p1740748388054459). 2. Batch or Aggregate Results Outside Hooks: Some users have discussed the idea of collecting run results (e.g., storing run_results.json files in S3 or another object store) and then uploading them to Elementary tables in a single, controlled batch process. This would require a custom process, as Elementary does not natively support this workflow yet, but it could significantly reduce DML contention [Discussion on batching uploads](https://slack.com/archives/C02CTC89LAX/p1740748388054459). 3. Reduce Parallelism or Use Airflow Pools: If possible, limit the number of concurrent dbt tasks that trigger Elementary hooks by using Airflow pools or other scheduling controls. This can help you stay within BigQuery's DML limits, though it may impact overall pipeline runtime [Airflow pool workaround](https://slack.com/archives/C02CTC89LAX/p1689186975724739). 4. Accept Some Data Loss or Delay: As a last resort, you could consider running Elementary hooks less frequently (e.g., only on full runs or on a schedule), accepting that some model/test runs may not be immediately logged in Elementary. Summary: The most straightforward solution is to disable artifact autoupload in the on-run-end hook and batch the uploads in a separate job. For result tables, if DML limits are still exceeded, you may need to implement a custom batching/upload process or reduce parallelism. This is a known challenge with high-concurrency dbt+Elementary+BigQuery setups, and the Elementary team is aware of these limitations and open to further discussion and contributions for better solutions. Let me know if you need more details on implementing any of these approaches!