Turbo CI with Snowflake shared databases

​

Overview

003029 (0A000): SQL compilation error:
Cannot clone from a table that was imported from a share.

​

Why a macro override is needed

1. Snowflake cannot clone shared objects. Zero-copy cloning works by referencing a table’s underlying storage metadata, which stays in the provider’s account. A shared database is a read-only window into that account, so there is nothing to clone from. This is a platform limit with no workaround, and no GRANT changes it.
2. dbt™ has the right fallback, but never uses it on Snowflake. The clone materialization already knows how to create a view over the production relation instead of a clone. It picks between the two up front by asking the adapter can_clone_table(), and the Snowflake adapter answers true unconditionally. The check means “does this warehouse support CLONE at all”, not “can this specific relation be cloned”, and dbt™ does not catch the error and retry as a view. The result is that the fallback exists but the routing to it never fires.
3. The routing is overridable. dbt clone builds its SQL through dispatched macros, so a project-level snowflake__create_or_replace_clone can make the clone-or-view decision per relation instead of per adapter.

​

Configure the macro override

​

1. Add the macro

{% macro snowflake__create_or_replace_clone(this_relation, defer_relation) %}

    {% set shared_dbs = var('shared_databases', []) | map('upper') | list %}

    {% if defer_relation.database | upper in shared_dbs %}
        {# Share-backed relation: CLONE is not possible, create a pointer view instead #}
        create or replace view {{ this_relation }} as
            select * from {{ defer_relation }}
    {% else %}
        {# Normal path: identical to the dbt-snowflake default implementation #}
        create or replace
          {{ "transient" if config.get("transient", true) }}
          table {{ this_relation }}
          clone {{ defer_relation }}
    {% endif %}

{% endmacro %}

​

2. Register the override

dispatch:
  - macro_namespace: dbt
    search_order: ['my_project', 'dbt']

​

3. List your shared databases

vars:
  shared_databases: ['RAW_SHARED', 'PROD_ANALYTICS']

​

Usage

dbt clone --select state:modified+ --target ci
dbt build --select state:modified+ --target ci

show views in schema <ci_database>.<turbo_ci_schema>;

​

Requirements and limitations

• Permissions: the warehouse user in your ci environment needs IMPORTED PRIVILEGES on each shared database. If it can already select from the share, no extra grant is needed.
• Views read live data, not a snapshot: a clone freezes data at the moment it is created, while a view always shows the share’s current state. If the provider refreshes the shared data during or between CI runs, queries against the view reflect the new data. This is usually fine for CI, but results are not point-in-time reproducible the way clones are.
• Upstream schema changes: Snowflake expands select * when the view is created. If the provider adds, removes, or renames columns in a shared table, existing views can fail or return an outdated column set. Re-run dbt clone with --full-refresh to recreate them.
• Re-runs: dbt clone skips relations that already exist in the target schema. Pass --full-refresh when you want them recreated, for example while testing this setup.
• Changed incremental models: a view is not a writable base. An incremental model that is itself modified in a pull request and whose production relation lives in a shared database builds from scratch in the CI schema. For very large models, add a row-limit filter for the ci target.
• dbt™ versions: requires dbt™ 1.6 or later, when dbt clone was introduced. The macro shadows the adapter’s default implementation, so compare it against the default again after major dbt-snowflake upgrades.