你想在笔记本上试一套数据分析流程，过去往往要先装数据库连接组件，甚至准备远程数据仓库。dbt v2 正在缩短这段准备工作：它首次内置 DuckDB 适配器，第一次运行时自动下载并缓存对应 driver。DuckDB 是一种嵌入应用进程的分析型数据库，不必另养一台服务器；dbt 则负责把一组互相引用的 SQL 按正确顺序执行、建表并测试。两者接到一起，本地开发的起点就低了一截。
不过，“DuckDB 住进 dbt”需要说准确：内置的是适配器——把 dbt 的通用命令翻译成 DuckDB 能执行的连接层；driver 并非预先塞进安装包，而是首次使用时按需下载。材料也没有证明 DuckDB 已成为 dbt 的默认执行后端。本文事实均来自 DuckDB 官方博客这一项信源，便利性与兼容性描述仍需按单一来源理解。
从社区插件走进核心工具链
这条路线始于一个社区项目。按 DuckDB 官方博客的回顾，dbt-duckdb 在 2021 年 8 月 27 日收到第一个 pull request。此后，用户可以通过 pip 安装这个 Python 包，把 dbt 指向本地 DuckDB 文件，在不购买服务器或数据仓库的情况下建立模型、表和视图。截至博客成稿时，该项目在 GitHub 约有 1.4k stars。
转折发生在 2025 年。dbt Labs 于 5 月 28 日公布基于 Rust 的 Fusion engine，但最初没有开箱支持 DuckDB。两天后，用户 ran-codes 在 GitHub 提出适配请求。他说，正是 dbt-duckdb 的轻量安装帮自己越过了学习门槛。截至成稿，这个请求获得 146 个爱心和 21 个赞。五年间，一个降低入门成本的社区插件，逐渐变成主产品需要吸收的能力。
2026 年 6 月 1 日，dbt Core 2.0 发布首个 alpha。DuckDB 官方博客称，dbt Labs 随后把 Fusion 的大部分代码以 Apache 2.0 许可证并入 dbt-core 仓库，并归档 dbt-fusion 仓库。9 月 14 日，dbt 2.0.0 发布。v2 目前有两个可在本地免费安装、使用同一引擎的发行版：专有的 dbt 与开源的 dbt-oss。材料没有进一步说明两者的授权边界和功能差异。
少装一个包，只是第一步
在 dbt v1 中，适配器是独立的 Python 包。到 v2，适配器进入 Rust monorepo，并通过 ADBC drivers 连接数据库。用户安装 dbt 后，不再需要另装 dbt-duckdb；首次运行 DuckDB 时，dbt 会自动下载并缓存 driver。基本配置仍要写明 type: duckdb 和本地数据库文件路径，因此“开箱即用”更准确的意思是少装一层组件，不是完全零配置，也不代表首次使用无需联网。
更值得关注的是，v2 新增了旧 Python 适配器没有的 catalog support。catalog 可以理解为数据表的“目录和登记系统”：它记录表在哪里，以及应按什么结构和规则管理。用户可在 catalogs.yml 中配置 DuckLake 或 Iceberg REST catalogs。Iceberg 与 DuckLake 这类开放表格式或 lakehouse 组件，会把数据文件和表结构、版本、事务等元数据结合起来，让本地文件或对象存储也能获得一部分仓库式管理能力。
启用 use_catalogs_v2 后，模型可以指定目标 catalog，dbt 则代为生成并执行 ATTACH 语句。这把本地 SQL 开发与 lakehouse 表管理接到同一条工作流上。不过，现有材料没有完整交代其稳定性、兼容范围和生产环境限制。
连 dbt 自己也能当数据查
另一个变化不在业务数据，而在 dbt 的项目产物。大型项目的 manifest.json 可能增长到数百 MB。为了回答“哪些模型建成了表”“它们落在哪个 schema”“哪些模型缺少测试”这样的小问题，传统做法仍可能要加载并解析整个 JSON 文件。
v2 提供所谓 Information Schema：运行 dbt parse --generate-info-schema 后，可把 manifest 相关元数据写成一组 Parquet 文件。Parquet 是按列组织的数据文件格式；查询只涉及几列时，DuckDB 可以只读取所需列，并在不把全部内容放进内存的情况下筛选。于是，项目说明书本身也变成了可直接用 SQL 查询的数据集。
这对 CI——代码提交后自动执行的检查流程——和审计脚本尤其有用。团队可以在本机读取解析后落盘的文件，检查模型命名、物化方式或测试覆盖，而不必为这类检查启动数据仓库。材料还提到，JSON 产物本身同样可由 DuckDB 查询；Parquet 的主要意义，是让面向少数列的检查更合适。
为什么这件事值得看
变化看似只是“官方多带一个适配器”，实际触及分析工程的开发入口。过去，dbt 常运行在数据仓库之上；如今，分析工程师可以更顺手地在笔记本上开发、测试、查询数据产物，并进一步接入 DuckLake 或 Iceberg catalog。服务器和远程仓库没有因此消失，但许多试验与检查可以更早留在本地完成。
它也展示了另一条产品演进路径：社区先证明轻量工作流有需求，核心工具再把关键连接层收进去。真正的新意不只是“能运行 DuckDB”，而是本地数据库、湖表目录和 dbt 自身元数据开始共用一套更连贯的查询方式。
局限与未知
- 全部信息来自 DuckDB 官方博客这一项信源；1.4k stars 和 issue reactions 只是其成稿时的快照。
- 博客未完整说明 catalog support 的稳定性、兼容限制与生产条件，不能据此推断已全面适合生产部署。
- “内置 DuckDB”指内置 adapter、首次使用时下载 driver；现有材料不能证明 DuckDB 是 dbt v2 的默认 target，也不能把它理解为完全无需配置。