DuckDB v2.0 预览版代号为“Cyanoptera”，预计在今年秋季正式发布。这个版本不是一次普通的功能迭代：自 v1.5 发布以来，项目已经积累了超过 10,000 个 commit，并同时推进 SQL 解析器、存储格式、C API 和查询执行路径等底层能力。
对使用 DuckDB 做本地分析、嵌入式数据处理或复杂 SQL 查询的开发者来说，v2.0 值得关注的地方不只是新语法，而是数据库内部若干长期基础设施的替换。预览版也意味着兼容性和最终行为仍需经过正式发布前的验证。
一次面向底层能力的大版本升级
v2.0 预览版包含几个会影响开发者判断的核心变化：
- 全新的 SQL 解析器。
- 新的默认存储格式。
- 重写后的 C API。
- 少量经过筛选的破坏性变更。
- 异步 I/O 相关能力。
- 递归查询性能的大幅提升，标题信息提到最高可达 40 倍。
这些变化分别作用于不同层面。SQL 解析器决定查询文本如何被理解，存储格式影响数据文件和迁移策略，C API 影响嵌入式集成，异步 I/O 则关系到数据读取和执行过程中的等待行为。它们被放在同一个大版本中，说明项目正在重新整理数据库的基础边界，而不是简单增加几个 SQL 函数。
需要注意的是，“40 倍”应当被理解为特定递归查询和测试条件下的性能结果，不能直接外推到所有 SQL。真实收益仍取决于递归深度、数据规模、连接关系、过滤条件以及磁盘和内存环境。
递归查询为什么值得关注
递归 CTE 常用于组织层级、依赖关系、图遍历和路径展开。例如，下面的查询从根节点开始，逐层找出所有下游节点：
WITH RECURSIVE descendants AS (
SELECT
1 AS node_id,
0 AS depth
UNION ALL
SELECT
e.child_id,
d.depth + 1
FROM descendants AS d
JOIN edges AS e
ON e.parent_id = d.node_id
)
SELECT node_id, depth
FROM descendants
ORDER BY depth, node_id;
递归查询的难点在于，它不像普通聚合那样只扫描固定关系。执行器需要不断产生新的一层结果，并判断是否还有待处理的节点。数据存在大量分支、重复路径或较深层级时，递归部分很容易成为查询瓶颈。
可以这样用 Python 和 DuckDB 构造一个最小可运行示例。运行前安装 Python 包：
python -m pip install duckdb
保存为 recursive_demo.py 后执行：
import duckdb
con = duckdb.connect()
con.execute("""
CREATE TABLE edges(parent_id INTEGER, child_id INTEGER)
""")
con.executemany(
"INSERT INTO edges VALUES (?, ?)",
[
(1, 2),
(1, 3),
(2, 4),
(2, 5),
(3, 6),
],
)
rows = con.execute("""
WITH RECURSIVE descendants(node_id, depth) AS (
SELECT 1, 0
UNION ALL
SELECT e.child_id, d.depth + 1
FROM descendants AS d
JOIN edges AS e ON e.parent_id = d.node_id
)
SELECT node_id, depth
FROM descendants
ORDER BY depth, node_id
""").fetchall()
for row in rows:
print(row)
这个例子展示的是 SQL 语义和验证方法，并不代表 v2.0 预览版的具体基准结果。要评估升级收益，应该使用业务中真实的层级或依赖数据，在同一硬件、同一数据集和相同查询参数下对比 v1.5 与 v2.0 预览版。
新解析器和新存储格式带来的迁移问题
SQL 解析器属于看不见但影响面很广的组件。大多数简单的 SELECT、连接和聚合查询可能不需要修改，但边界语法、错误提示、扩展语法或依赖解析细节的工具都可能受到影响。使用 DuckDB 作为其他程序的 SQL 执行引擎时，建议把解析失败、参数绑定和结果类型都纳入回归测试。
新的默认存储格式同样需要谨慎处理。对于临时分析任务，文件格式变化通常只影响数据库文件的生命周期；对于需要长期保存 .duckdb 文件、在多个版本之间交换文件，或将数据库文件作为构建产物发布的项目，则应明确记录版本和迁移策略。
一个可以落地的验证流程是：
# 在隔离环境中安装待验证的预览版本
python -m venv .venv-duckdb-preview
. .venv-duckdb-preview/bin/activate
python -m pip install --upgrade pip
python -m pip install duckdb
# 运行项目已有的 SQL 回归测试
python -m pytest tests/sql
这里的安装命令只表达验证思路。预览版的实际包版本和发布渠道应以项目发布说明为准。不要直接用预览版覆盖生产环境中的数据库文件，也不要在没有备份和回滚方案的情况下执行格式迁移。
C API 重写：嵌入式用户要重点检查
DuckDB 的 C API 重写对直接进行 C/C++ 集成、自己管理连接和结果集生命周期的项目影响更大。即使业务 SQL 不变，以下部分也值得逐项检查：
- 头文件和库文件的版本是否匹配。
- 连接、查询结果和错误对象的释放方式是否发生变化。
- 字符串、数值和日期类型的取值方式是否需要调整。
- 编译脚本、动态库加载路径和跨平台构建配置是否仍然有效。
- 旧 API 是否被移除、重命名或改变返回值语义。
对于 Python、R 或其他高级语言用户，C API 的变化通常会先由绑定层吸收，但绑定层版本也必须和底层 DuckDB 版本保持一致。升级时应避免只替换动态库而保留旧的客户端绑定。
现在是否适合采用
v2.0 预览版适合用来做兼容性测试、递归查询基准、SQL 解析边界验证和 C API 迁移准备。对于生产环境，是否采用应取决于项目对存储文件兼容性、嵌入式 ABI、预览版稳定性的容忍程度。
可以用下面的清单安排升级评估：
- 固定一组真实 SQL，覆盖递归 CTE、连接、聚合和参数绑定。
- 为关键查询记录执行时间、结果行数和结果类型。
- 备份并复制测试数据库文件，不在原始生产文件上实验。
- 检查使用 DuckDB C API 的构建和资源释放逻辑。
- 对新旧版本分别运行回归测试和数据一致性校验。
- 等正式版发布后再次确认存储格式、API 和破坏性变更清单。
DuckDB v2.0 预览版的价值，在于它展示了一个嵌入式分析数据库如何继续向更强的 SQL 能力、更高效的 I/O 和更深的工程集成演进。对开发者而言，最稳妥的做法不是只看单个性能数字，而是尽早拿自己的查询、数据文件和客户端代码进行验证。