Frederico Nunes
02/25/2026, 3:46 PMcannot insert multiple commands into a prepared statement
Full context:
[0m14:17:21 Using redshift connection "master"
[0m14:17:21 On master: /* {"app": "dbt", "dbt_version": "1.10.19", "profile_name": "data_warehouse", "target_name": "default", "connection_name": "master"} */
begin transaction;
delete from "prod"."elementary"."dbt_models"
where
metadata_hash is null
or metadata_hash in (select metadata_hash from "dbt_models__tmp_20260225141713612576141713617921");
insert into "prod"."elementary"."dbt_models" select * from "dbt_models__tmp_20260225141716870030141716870967";
commit;
[0m14:17:21 Redshift adapter: Redshift error: cannot insert multiple commands into a prepared statement
[0m14:17:21 On master: ROLLBACK
[0m14:17:22 Redshift adapter: Not retrying error: Database Error
cannot insert multiple commands into a prepared statementkapa.ai
02/25/2026, 3:46 PMkapa.ai
02/25/2026, 3:46 PMbegin; delete …; insert …; commit;). Elementary’s delete_and_insert logic is currently compiling exactly that pattern for Redshift, which produces the error you’re seeing. [GitHub issue; Slack thread]
From the shared issues/threads, there are three practical options:
1. Short‑term: disable artifacts autoupload in the post‑hook
This stops the failing dbt_models / dbt_columns writes during on-run-end and lets your runs succeed, while you handle artifacts separately. [GitHub issue]
# dbt_project.yml
vars:
elementary:
disable_run_results: true
disable_dbt_artifacts_autoupload: true
disable_dbt_invocation_autoupload: true
Some teams even temporarily disabled Elementary entirely on prod targets:
models:
elementary:
+schema: elementary
enabled: "{{ target.name in ['beta'] }}"
2. Recommended workaround: override the Redshift macro
Community members fixed this by overriding the Redshift implementation of get_delete_and_insert_queries so it returns two separate statements (delete + insert) instead of one multi‑command transaction. [Slack thread; Linen recap]
Create a macro in your project, e.g. `macros/redshift_get_delete_and_insert_queries.sql`:
{% macro redshift__get_delete_and_insert_queries(relation, insert_relation, delete_relation, delete_column_key) %}
{% set queries = [] %}
{% if delete_relation %}
{% set delete_query %}
delete from {{ relation }}
where
{{ delete_column_key }} is null
or {{ delete_column_key }} in (select {{ delete_column_key }} from {{ delete_relation }});
{% endset %}
{% do queries.append(delete_query) %}
{% endif %}
{% if insert_relation %}
{% set insert_query %}
insert into {{ relation }} select * from {{ insert_relation }};
{% endset %}
{% do queries.append(insert_query) %}
{% endif %}
{% do return(queries) %}
{% endmacro %}
If you’re on dbt Cloud or want to be explicit, add a dispatch rule so your project’s macro overrides Elementary’s: [Slack thread]
# dbt_project.yml
dispatch:
- macro_namespace: elementary
search_order: ['<YOUR_PROJECT_NAME>', 'elementary']
Replace YOUR_PROJECT_NAME with the name from your dbt_project.yml.
This makes Elementary emit two separate statements (delete, then insert) instead of a single begin … delete … insert … commit block, which avoids the Redshift “multiple commands” limitation.
3. Run Elementary models/artifacts in a separate job
As an additional mitigation, you can decouple Elementary from your main runs and execute its models (including artifacts) in a separate dbt job, so failures there don’t break core pipelines. The maintainers explicitly recommend running artifacts outside on-run-end when this issue appears. [GitHub issue]
-------------------------
The knowledge sources show that a fix was released in Elementary 0.21.0, but multiple users on Redshift still reported the same error even after upgrading, and the macro override above is the documented working workaround. [GitHub issue; Slack follow‑up] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.