你想把 PostgreSQL 里的订单，与 MySQL 里的客户资料放在一起分析。过去，即使 DataGrip 能同时连接两套数据库，也只能分别查询；要把结果接起来，还得另找一个共同的计算场所。JetBrains 现在的做法很直接：不自己造跨库查询引擎，而是把 DuckDB 嵌进 DataGrip，让它在本机承担这层计算。
这值得关注，不只因为多了一项功能。它展示了一种颇有代表性的架构选择：数据库 IDE 不再只是多个数据库的统一操作面板，也可以内置一个计算层，把不同连接的数据临时汇合起来。
本文事实主要来自 DuckDB 官方博客对 JetBrains 员工的采访，尚无 JetBrains 公告、代码或第三方材料交叉核验。文中的便利性与技术取舍，应理解为项目团队的陈述。
IDE负责接线，DuckDB负责计算
DataGrip 是数据库 IDE——供开发者连接数据库、编写和调试 SQL 的工作台。它本身不是存放业务数据的数据库。JetBrains 从 2015 年开始开发 DataGrip，同一套数据库功能也以插件形式进入其他 JetBrains IDE。
用户长期提出一个需求：能否在一条查询里连接多个数据源。例如，订单在 PostgreSQL，客户资料在 MySQL，开发者希望直接按客户把两张表合起来。这就是跨数据库查询。它真正困难的地方，不是同时打开两个连接，而是必须把两边的数据拉到某个共同的计算层，再执行连接、筛选等操作。
据 DuckDB 官方博客，DataGrip 原本已经能把查询分别发给各个连接，却没有负责汇总结果的引擎。JetBrains 因而评估了三条路：采用 Apache Calcite；利用 PSI 自己处理查询；或者嵌入 DuckDB。PSI（Program Structure Interface）是 JetBrains IDE 用来表示和理解程序结构的内部机制。团队最终选择 DuckDB，理由是它最容易接入现有系统。
DuckDB 是一种可以直接嵌入应用进程的分析型数据库。它不要求另起一套数据库服务器，擅长在本机扫描和连接批量数据。在 DataGrip 里，它不取代 PostgreSQL、MySQL 或 MongoDB，而是站在这些连接之上，担任跨库查询的执行引擎。
关键不是“能嵌入”，而是“能接上”
JetBrains 看中的决定性能力，是 DuckDB 允许注册 custom table function，即自定义表函数。可以把它理解成一个转换插头：对 DuckDB 来说，这个函数表现得像一张可查询的表；背后真正取数时，它可以调用 DataGrip 已有的查询执行能力，从某个数据库连接获取数据。
这样，JetBrains 不必重写各类数据库的连接和执行逻辑。DataGrip 继续负责与各个数据源交涉，DuckDB 则把返回的数据放进同一条查询中计算。JetBrains 数据库生态负责人 Maxim Sobolevskiy 在 DuckDB 博客采访中称，用户可以把 PostgreSQL、MySQL、MongoDB 或其他受支持数据库的数据放进一条查询，也不用另外部署基础设施。不过，“其他受支持数据库”仍取决于 DataGrip 的支持范围、驱动和数据类型兼容情况。
团队也比较过 H2 等更轻量的嵌入式方案。按采访说法，DuckDB 还提供 projection pushdown 等查询优化能力。所谓 projection pushdown，是尽量只读取查询真正需要的列，避免搬运无关数据。不过，材料只说明 DuckDB 具备这种能力，并未证明当前跨库场景已经实现端到端下推，更没有给出性能数字。其他候选方案则需要原生代码或更复杂的实现，没能同样方便地接入。
它没有把DuckDB藏起来
这套设计还有一个克制之处：DataGrip 明确告诉开发者，跨数据源查询由 DuckDB 执行。
不同数据库对 SQL 语法、函数和类型规则都有自己的扩展，这些差异统称 SQL 方言。既然最终执行者是 DuckDB，开发者写的跨库查询就要遵循 DuckDB SQL dialect。DataGrip 会提示用户正在编写 DuckDB 查询，而不是假装所有数据库天然讲着同一种 SQL。JetBrains 还把 DuckDB 作为独立方言支持，并加入相应的语法高亮。
这避免了一种容易误导人的抽象：界面虽然统一，底层语义却没有消失。函数是否存在、类型如何转换、语法能否执行，仍由 DuckDB 的规则决定。
为什么这个选择值得看
DuckDB 的出发点，本来就是减少使用数据库能力之前的部署负担。据荷兰国家数学与计算机科学研究中心 CWI 的故事材料，研究员 Hannes Mühleisen 曾发现，不少 R 用户宁愿把 CSV 读进内存，再使用自制而缓慢的 dataframe 引擎，也不愿部署传统数据库。他与 Mark Raasveldt 随后借鉴 SQLite 的思路，把数据库做成程序中可直接调用的库，并面向分析场景发展出 DuckDB。
多年后，DataGrip 把 DuckDB 放进 IDE，恰好延续了这条思路：让计算能力来到用户正在工作的地方，而不是先要求用户维护一套新系统。
更重要的是，JetBrains 没有因为需要一项跨库功能，就把自己变成查询引擎厂商。它保留 DataGrip 擅长的连接、编辑和交互能力，把跨源计算交给现成的嵌入式引擎。这是一种清晰的分工，也说明“嵌入式数据库”可以不只是应用的数据存储，还能成为应用内部的本地计算层。
局限与未知
- 这仍是初始版本。团队表示，要先观察用户的实际使用方式，再逐步加入更多 DuckDB 优化，并考虑支持文件型数据源。
- 材料没有披露数据传输方式、类型映射、权限边界、资源限制及失败恢复等实现细节，也没有性能测试，不能判断大型跨库查询的速度与成本。
- 全部专题事实来自 DuckDB 官方博客这一条信源。文中“最容易集成”“无需额外基础设施”等说法带有项目方评价，不宜外推为所有跨库场景的普遍结论。