你想在开发环境试一张新报表，却发现第一步不是写 SQL，而是先把生产数据复制一份。数据要搬、权限要配，副本还可能慢半拍。dbt 这次接入 Amazon Redshift 的原生数据共享，试图省掉这套搬运：开发和 CI 环境直接读取获授权的生产数据，同时把自己的计算结果写进隔离的目标数据库。
dbt 是一套数据转换工具：团队用 SQL 定义报表和指标所需的数据模型，dbt 再按依赖顺序，在数据仓库里构建表或视图。Amazon Redshift 则是云端数据仓库，用来集中存放和分析数据。本次信息全部来自 dbt 官方博客，尚无 AWS 文档、代码变更或第三方测试交叉验证，因此性能判断应视为官方说法。
共享输入，隔离产物
Redshift data sharing——数据共享——允许另一个 Redshift 环境直接读取获授权的数据对象，不必先复制一份。它可跨集群、Serverless workgroup、AWS 账户和 Region，共享表、视图等实时数据。
这对开发环境很有用。开发者可以在独立集群、数据库甚至 AWS 账户中工作，通过共享读取生产数据，却不与生产任务争用同一套计算资源。dbt 的 defer 功能还能把尚未修改的上游模型指向生产环境；当前正在开发的模型，则写进自己的数据库。换句话说，输入可以来自生产，产物仍留在开发区。
这不是说整条管线从此不再写数据。dbt 仍会进行“物化”——把查询逻辑落实成表、视图或增量表。减少的是为共享输入而制造的副本，而不是模型计算与落盘本身。
AWS Big Data Blog 曾介绍 Warner Bros. Games 的类似困境：公司过去维护一套复杂的数据搬运设施，在单款游戏的集群和公司级集群之间复制、移动和装载数据。数据共享让不同工作负载可以分开计算，却继续读取同一份数据。dbt 此次更新，相当于把这种架构进一步接进日常建模流程。
一个开关，改掉元数据路径
新版本加入 profile credential datasharing: true。问题的关键不只是“能否看见数据”，还在于 dbt 写入前要先查清目标数据库里已有些什么。
过去，dbt-redshift 使用 PostgreSQL 的目录表查询元数据。这些接口只能看见当前连接的数据库。如果连接在 dev，模型却要写入 dev_analytics，dbt 无法正确检查后者，跨数据库写入就会失败。
启用 datasharing: true 后，适配器改用 Redshift 原生的 SVV_* 系统视图和 SHOW API。它们能够识别跨数据库对象，因此 dbt 可以解析目标库元数据，并把模型物化到当前连接之外的数据库。dbt platform 可在环境的 Extended Attributes 中开启；本地使用时，则写入 profiles.yml。
不过，这个开关只解决元数据和事务上下文问题，不会自动授予权限。执行 dbt 的数据库用户仍须拥有目标数据库的 CREATE 权限。
为什么值得关注
此前，dbt 引用数据共享来源有一组窄限制：环境须使用 RA3 或 Serverless，并设置 ra3_node: true；引用共享来源的模型必须物化成 table，不能使用 view，也不支持 cross-project reference——跨 dbt 项目引用。高级 CI 环境因此很难横跨隔离集群运行。
新方案把“读共享数据”和“向另一数据库写入”接到同一次 dbt 运行中。它直接影响团队如何设计开发、CI 和多团队数据架构：不必为每个环境维护完整的生产数据副本，也能让各环境分别管理计算、权限和模型产物。
官方还称，迁移到 SVV_* 与 SHOW API 后，dbt 运行更快，元数据解析更可靠，高并发下表现也更好。但博客没有提供耗时、并发规模或版本对照，暂时不能把“显著提速”当作已量化结论。
局限与未知
datasharing: true目前处于 Beta，仅在 dbt platform 的 Latest release track 提供，尚未进入 Compatible 或 Extended tracks。- 供稿末尾被截断，完整的功能边界、事务语义以及 dbt Mesh 等平台能力的支持情况没有呈现。
- 现有材料只有 dbt 官方博客；跨账户、跨 Region 和高并发场景的实际配置成本与性能，仍缺少独立验证。