Hi team, I'm running Elementary

0.23.1

on dbt-fabric (Microsoft Fabric Warehouse). Our

dbt-fabric

adapter does not yet support the

merge

incremental strategy, so all Elementary artifact/run-results models currently fail on my setup. We are planning to upgrade the dbt-fabric adapter soon to a newer version, right now we aren't able to do it safely. The only supported non-append strategy on Fabric is

delete+insert

. As a workaround I'm overriding Elementary's dispatched macro in my own project:

{%- macro fabric__get_default_incremental_strategy() %}
    {% do return("delete+insert") %}
{% endmacro %}

Before I roll this out, I wanted to sanity-check with you whether this is safe for Elementary's data model. A few concerns I'd appreciate your input on: 1.

created_at

semantics —

insert_rows.sql

auto-assigns

created_at

on insert. Under

merge

, matched rows keep their original

created_at

. Under

delete+insert

, the row is dropped and reinserted, so

created_at

is overwritten on every run. Is this used anywhere by the Elementary UI / Cloud as a "first seen" timestamp, or is

generated_at

the canonical one? 2. Atomicity / partial failures —

delete+insert

is two separate statements. If the INSERT fails after the DELETE, rows are missing until the next run. Are any Elementary models (especially

dbt_run_results

,

elementary_test_results

,

data_monitoring_metrics

) relied upon by other models within the same invocation in a way that this transient inconsistency could break? 3.

merge_update_columns

/

merge_exclude_columns

— are any Elementary models using these? They'd be silently ignored under

delete+insert

. 4. Cross-table consistency —

dbt_columns.parent_unique_id

etc. logically reference

dbt_models.unique_id

. During a run, when the parent table is mid delete+insert, child tables briefly reference non-existent parents. Is that handled downstream, or does the Cloud UI / report generation assume a consistent snapshot?

These are good questions, but I have to be upfront: the knowledge sources available to me don't contain detailed internal documentation about Elementary's incremental strategy implementation for dbt-fabric, nor do they cover the specific semantics you're asking about at the level of detail needed to give you confident answers on all four points. Here's what I can say based on the available evidence: What the knowledge sources confirm Your macro override approach is a known pattern. Overriding Elementary's dispatched macros at the project level is an established workaround. For example, the community has done exactly this for Redshift to split

delete+insert

into separate statements: [Redshift macro override]

# dbt_project.yml
dispatch:
  - macro_namespace: elementary
    search_order: ['<YOUR_PROJECT_NAME>', 'elementary']

This pattern is considered safe as long as you don't alter schemas or constraints. On your specific concerns 1.

created_at

vs

generated_at

semantics The knowledge sources confirm that these two fields have distinct meanings: •

generated_at

= the dbt execution time •

created_at

= the time the row was written to the database Elementary support explicitly recommends

created_at

as the more reliable field for incremental load logic. [generated_at vs created_at] However, whether

created_at

is used as a "first seen" timestamp in the Elementary UI/Cloud is not addressed in the knowledge sources. I cannot confirm or deny this. 2. Atomicity / partial failures The knowledge sources do acknowledge that

delete+insert

is two separate statements and that a failure between them leaves the table in an inconsistent state until the next run. This is noted as a known risk in the BigQuery concurrent transactions issue: [BigQuery concurrent transactions] However, whether Elementary's models within the same invocation have hard dependencies on

dbt_run_results

,

elementary_test_results

, or

data_monitoring_metrics

being fully consistent mid-run is not documented in the knowledge sources. 3.

merge_update_columns

/

merge_exclude_columns

The knowledge sources do not mention these dbt incremental config options in the context of Elementary's models. I cannot confirm whether any Elementary models use them. 4. Cross-table consistency The knowledge sources confirm that tables like

dbt_columns.parent_unique_id

logically reference

dbt_models.unique_id

, and that Elementary's artifact tables are updated via

delete_and_insert

logic in

on-run-end

. [dbt artifacts behavior] However, how the Elementary Cloud UI or report generation handles transient cross-table inconsistency is not covered in the knowledge sources. Recommendation Given the gaps in the available documentation, I'd strongly recommend raising this directly with the Elementary team (e.g., via their Slack community or a GitHub issue), as these are implementation-level questions that require access to Elementary's internal model dependency graph and UI rendering logic. The knowledge sources simply don't go deep enough to give you the safety guarantees you're looking for before rolling this out to production. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.