Amazon Redshift Late-Binding Views in dbt: Hidden CI/CD Pitfalls (and How to Fix Them)

Learn why Amazon Redshift late-binding views create unique challenges for dbt CI/CD, and how a simple post-hook restores early validation.

In dbt, models are materialized as views by default. When using Amazon Redshift, this behavior introduces certain constraints because standard Redshift views enforce strict dependencies on the underlying database objects. These constraints complicate development and production workflows, especially when models are frequently rebuilt or adjusted.

Limitations of Standard Redshift Views

Standard Redshift views require that all referenced objects exist and remain unchanged. If a table or other dependent object is dropped or altered, any view referencing it must also be dropped beforehand. This creates operational friction.

In a dbt context, this becomes particularly problematic. For example, if a view-based model depends on a table-based model, running the table model can result in the underlying table being dropped and recreated. This process implicitly drops the dependent view, leading to instability in the system.

Late-Binding Views as a Solution

Late-binding views address these limitations by deferring dependency validation until query time rather than enforcing it at creation time. When a late-binding view is created, Redshift does not check whether the referenced objects exist or are valid. As a result, the view is not tightly coupled to its underlying tables.

This approach allows underlying objects to be dropped or altered without immediately impacting the view definition. In practice, this flexibility enables smoother rebuilds of upstream models, since dependent views do not need to be dropped and recreated during each change.

Risks and Trade-offs

Although late-binding views provide flexibility, they introduce a different set of challenges. Because dependency validation is deferred, errors are only discovered when the view is queried. If an underlying table has been dropped, renamed, or modified, queries against the view will fail at runtime.

Similarly, if a query references columns that no longer exist in the underlying object, the failure will only surface during execution. This delayed feedback can make late-binding views appear fragile and can turn them into a significant source of runtime errors if not carefully managed.

Another important consideration is that dbt does not validate these dependencies during a run. Even with advanced features such as the Fusion engine and stricter static analysis (tested in dbt Fusion Preview.154), dbt only creates the view and does not execute it. As a result, issues remain undetected until the view is actively used.

Redshift Use Cases That Require Late-Binding Views

Late-binding views are essential in certain scenarios where standard views cannot function. One such case is when dbt sources reside in a different Redshift database. Another is when working with Redshift Spectrum and querying external tables. In both situations, late-binding views are the only viable option for creating views over these data sources.

These scenarios make late-binding views unavoidable rather than optional. However, they also expose an important limitation in a common dbt Slim CI/CD workflow.

The recommended slim CI/CD dbt run, which uses the defer flag, creates views in the CI/CD database that point to objects in the production database. But Redshift does not allow a late-binding view in a QA database to reference a Prod late-binding view when that Prod view depends on objects in Source database and CI/CD fails!

create or replace view prod.staging.vw_gtm as select * from source.fivetran.gtm with no schema binding;

create or replace view qa.staging.vw_gtm as select * from prod.staging.vw_gtm with no schema binding;

SQL Error [XX000]: ERROR: cross-database reference to prod.staging.vw_gtm found while analyzing an LBV on producer.

As a result, models that need to participate in cross-database Slim CI/CD workflows often need to be materialized as tables or materialized views instead of late-binding views.

dbt Support

Support for late-binding views in Amazon Redshift was introduced in dbt version 0.9.1.

{{ config(materialized='view', bind=False) }}

select * from public.test

But to use it reliably you need one more configuration step: run select from the view in a post hook macro.

{% macro validate_view() %}

 {% if execute and flags.WHICH in ('run','run-operation', 'build') %} 

    {% set model_name = model.get('alias', model.get('name'))  %}
    {% set model_schema = model.config.schema | default(target.schema, true) %}
    {% set model_database = model.config.database | default(target.database, true) %}

    {{ log("Validating model: " ~ model_name, info=True) }}

        {% set sql %}
            select *
            from {{ model_database }}.{{ model_schema }}.{{ model_name }}
            limit 1
        {% endset %}    

        {% do run_query(sql) %}

    {{ log(model_name ~ " validated successfully", info=True) }}

{% endif %}

{% endmacro %}

Using this approach, running dbt run — select state:modified+ in your CI/CD pipeline will not only create the view in the database but also effectively validate it.

Conclusion

Late-binding views are a powerful Redshift feature, but they introduce important considerations for dbt projects. Besides limitations in some Slim CI/CD scenarios, their biggest drawback is that dependencies are not validated when the view is created. Adding a simple post-hook that queries each view immediately after creation restores early error detection while preserving the flexibility that makes late-binding views valuable.