dbt now supports Amazon Redshift data sharing — and your pipelines just got a lot faster

For Amazon Redshift users, one of the most requested capabilities in dbt is finally here: native support for Amazon Redshift data sharing read and writes. With this release, dbt can materialize models across Redshift data warehouse, unlocking a new class of multi-team data architectures — all without copying or moving a single byte.

Alongside data sharing support, this release includes a significant under-the-hood upgrade: dbt-redshift has migrated away from legacy Postgres metadata APIs to Redshift-native SVV_* system views and SHOW APIs. The result is faster dbt runs, more reliable metadata resolution, and dramatically better behavior under high-concurrency workloads.

Let's dig into what changed and why it matters.

What is Redshift data sharing?

Amazon Redshift data sharing lets you securely share live data across Redshift clusters, serverless workgroups, AWS accounts, and AWS Regions without copying or moving it. A producer exposes database objects (schemas, tables, views, materialized views, UDFs) to one or more consumers, who can query that data in real time as if it were local. Because all consumers read from the same live source, they always see transactionally consistent, up-to-date information the moment a write is committed on the producer.

Until now, dbt couldn't fully take advantage of this. Models could only reference sources in a foreign database under narrow conditions: RA3 or serverless node types, a special ra3_node: true profile flag, and a hard constraint that any model referencing a datashared source had to be materialized as a table. Views were out. Cross-project references were out. Advanced CI environments that span clusters were out.

With this release, all of that changes.

The fix: datasharing: true

The core of this release is a new profile credential: datasharing: true.

Here's the problem it solves. By default, when you configure a dbt model to write to a database other than the one your connection is pointed at — using something like {{ config(database='dev_analytics') }} — dbt needs to introspect that target database before it can write. It does this using PostgreSQL catalog tables (pg_tables, pg_views, information_schema), which only surface objects within the currently connected database. If your connection is pointed at dev and your model targets dev_analytics, those metadata queries return nothing for dev_analytics, and the cross-database write fails with an error like:

Database Error in model fct_tpch_orders

Cannot write to a different database inside a transaction when USEd db was not

set before the transaction began.

Setting datasharing: true switches the adapter's metadata queries to Redshift's native SVV_* system views and SHOW APIs, which are cross-database aware. With this flag enabled, dbt correctly resolves metadata for databases it isn't directly connected to, and cross-database writes succeed.

In dbt platform, you set this via Extended Attributes on the environment — no code changes required:

datasharing: true

Locally, it goes in your profiles.yml under your Redshift connection config.

Note: datasharing: true is currently in Beta on the Latest release track in dbt platform. It is not yet available on the Compatible or Extended tracks.

Setting it up end to end

The setup involves three steps.

Step 1 — Create the target database. In your Redshift Query Editor, connect to your primary database and create the database you want to write into:

CREATE DATABASE dev_analytics;

Step 2 — Configure your model. Add database='dev_analytics' to the model config:

{{

config(

materialized = 'table',

database='dev_analytics'

)

}}

select * from {{ ref('stg_orders') }}

Step 3 — Enable datasharing in your dbt platform environment. In dbt platform → Orchestration → Environments → your environment → Extended attributes, add:

datasharing: true

That's it. dbt will now correctly resolve metadata for dev_analytics and materialize the model there.

One important note on permissions: datasharing: true enables the metadata path required for cross-database writes, but it does not grant database permissions. Your database user still needs CREATE privileges on the target database. If permissions aren't set up correctly, you'll get a permissions error — datasharing: true only solves the transaction context problem, not access control.

Defer and cross-database writes: two chapters of the same story

The most powerful way to use this feature is in combination with dbt's defer capability. These two things together directly address a common problem for Redshift customers: how do you use dbt effectively when your environments are completely isolated across AWS accounts?

Chapter 1 is defer with datasharing. Your dev environment reads from Production’s tables cross-account via a Redshift datashare, enabling slim CI and fast iteration without copying production data. This doesn't require any special adapter flags — just infrastructure setup (AWS Organizations + Redshift datashare configuration).

Chapter 2 is cross-database writes with datasharing: true. Your dev environment writes models into a separate target database (like dev_analytics), while upstream references still defer to prod via the datashare. Both things happen in the same dbt run: upstream models resolve against production data cross-account, and the current model materializes into the dev target database.

This combination means dev environments can be genuinely isolated — separate cluster, separate databases, separate AWS account — while still iterating against real production data and not contending with production workloads.

What this unlocks for dbt platform features

Redshift data sharing support doesn't just fix a materialization problem. It makes a range of dbt platform capabilities work correctly for Redshift customers that have been blocked.

dbt Mesh / cross-project references: Teams using dbt Mesh to split large projects into independently-owned domains can now use ref() across projects that span different Redshift data warehouses and databases. A downstream team's models can depend on an upstream team's certified datasets without either team needing to own the data warehouse the other is running on.

Advanced CI: dbt's CI environment support relies on creating slim, isolated project versions for each pull request. With data sharing support, CI environments can live on a dedicated cluster while reading shared source data from production via a datashare — enabling genuinely isolated, fast CI without duplicating upstream datasets.

Workload isolation: One of the most common Redshift best practices is separating ETL workloads from BI query traffic onto dedicated clusters. Teams can now route specific models to specific clusters or databases directly from their dbt project config, keeping heavy transformation work off the clusters powering dashboards — all without stepping outside of dbt.

Faster runs for everyone: the metadata API upgrade

Even if you're not using data sharing, this release makes dbt-redshift faster.

The migration from pg_* catalog views to Redshift's native SVV_* system views and SHOW APIs isn't just required for cross-database visibility — it's also significantly faster. The legacy Postgres-inherited metadata views were not designed for Redshift's architecture. At scale, under high concurrency, teams saw metadata queries add meaningful overhead to every dbt run — seconds per query, multiplied across large projects with many models.

The SVV_* and SHOW-based APIs are optimized for Redshift and return consistent results regardless of concurrency or cluster size. For teams running large projects or high thread counts, the improvement is noticeable.

Known limitations

Redshift data sharing is a powerful capability, but there are constraints worth knowing before you architect around it.

You cannot create regular views directly on top of datashared tables on the consumer side. This is an AWS-level limitation: on a consumer cluster, regular views cannot reference objects that live in a datashare. If you try to build a view model in dbt that queries a datashared source directly, it will fail.

The workaround is to materialize the datashared data as a table first, then build your views on top of that table. Your first layer of models referencing datashared sources should use materialized='table' or incremental. Downstream models can then be views, as usual:

-- First layer: must be a table, reads directly from datashare

{{ config(materialized='table') }}

select * from {{ source('producer_cluster', 'orders') }}

-- Downstream: can be a view, reads from the materialized table above

{{ config(materialized='view') }}

select order_id, customer_id, amount

from {{ ref('stg_orders_from_datashare') }}

where status = 'completed'

Late-binding views and materialized views can be shared from a producer cluster, but regular views on the consumer side cannot directly reference datashare objects. See AWS's documentation on view support in data sharing for the full breakdown.

Additionally, write operations across datashares (INSERT, UPDATE, DELETE on producer tables from a consumer cluster) have their own SQL constraints on the AWS side. Review the AWS documentation on multi-warehouse writes if your use case requires bidirectional data flow.

Getting started

To use dbt's Redshift data sharing support, you'll need:

• An RA3 or RG or Redshift Serverless cluster (DC2 does not support data sharing)
• Redshift datashares configured by your AWS administrator
• dbt-redshift on the Latest release track in dbt Cloud (Beta), or dbt-redshift v1.11+ locally
• datasharing: true set in your profile or dbt Cloud Extended Attributes
• The connecting database user granted CREATE permissions on the target database

Read through the dbt-redshift setup documentation for the full configuration reference, and the dbt Cloud release notes for the latest on the Beta rollout.

What's next

This release opens up significant new surface area for dbt on Redshift, and we're actively tracking feedback on what to build next — including broader IDE and lineage support for cross-database dependencies, and expanded CI/CD patterns for teams using defer and cross-database writes together.

If you're building on this and have a use case — or a limitation you've hit — we want to hear from you. Open an issue on dbt-adapters or start a conversation in dbt Community Slack.