DuckDB官方博客扔出一篇标题很像"发布公告"的文章:v2.0要在今年秋天上线,代号叫"Cyanoptera",要做服务器、要加触发器、要让VARIANT类型转正、要上异步I/O,功能列了满满一屏。但翻一遍DuckDB自己的发布日历会发现一件有点尴尬的事:这篇预告发出来的时候,最新稳定版还是三周前刚发的v1.5.5,下一个小版本v1.5.6定档9月中旬,v2.0那一栏写的只有"fall 2026",没有月份,也没有版本号锁定。这不是发布通知,是路线图画饼——画得挺好看,离交付还有距离。
名字对不上、日期没锁死
"Cyanoptera"这个代号,除了这篇博客本身,没有在DuckDB其他官方页面或代码仓库里找到独立出处——目前唯一的信源就是它自己。这类"自证"命名在开源项目里不算新鲜,但放进一篇通篇用肯定语气写"v2.0 will be named..."的文章里,值得多看一眼。
真正决定这篇预告成色的,不是代号叫什么,而是它列的功能里,哪些已经在真实测试里跑出过数字,哪些还停留在"don't hold us to it"的口头承诺。
Quack的32倍,是怎么跑出来的
quack扩展是这次"服务器化"的主角:一个DuckDB进程执行CALL quack_serve开放服务,另一个DuckDB用CONNECT连过去,查询在服务器端执行,结果流回来。官方给出的对比数字确实抓眼球——60,000,000行结果传输,Quack耗时4.94秒,比Arrow Flight SQL(17.40秒)快约3.5倍,比标准PostgreSQL协议(158.37秒)快约32倍。
但这场测试的赛道是DuckDB自己选的:单表、无索引、无行竞争,测试机之间延迟低到0.28毫秒。写入端的数字更说明问题:8个并发线程写单表,Quack做到5,434 tx/s,比PostgreSQL的4,320 tx/s快约1.26倍——差距明显小了很多——而且DuckDB过了8线程就撞上同表插入的扩展瓶颈,PostgreSQL反而还能往上走。
跑分跑赢的,往往是最不像生产环境的那一种。
- 风险.Quack目前仍绑定单一计算实例,副本读扩展和故障转移都还是"未来工作",鉴权、监控、备份也要自己搭,拿它当PostgreSQL的直接替代品还为时太早。
服务器化,吃的是谁的蛋糕
DuckDB这次想抢的位置很具体:中等并发、只追加写入、分析为主的场景。CONNECT语句甚至可以直连PostgreSQL和MySQL,把查询下推过去而不是把整张表拉过来——这部分能力如果稳定,确实能省掉不少ETL管道。但目前能查到的官方文档里,描述远程连接用的还是ATTACH quack:...这种旧写法,CONNECT语句更像是这篇预告文章里率先亮相的新语法,是否已经定型还不确定。
真正的竞争坐标系是这样的:PostgreSQL和MySQL守着高并发事务和成熟运维生态,ClickHouse守着分布式和超大规模日志分析,MotherDuck卖的是存算分离和多租户托管。Quack现在能打的,是中间这块"轻量分析服务"的空白地带,离取代任何一方都还差得远。
哪些改动已经钉死,哪些还是预告
真正已经钉死、现在就该记下来的,是这几条:lambda表达式的旧写法x -> x + 1在v1.5里只是警告,v2.0默认直接报错,得改成lambda x: x + 1;项目同时从C++11迁移到C++17,新的PEG解析器会成为默认解析器。这些是实打实的技术债清算,嵌入式部署的团队升级前最好先跑一遍回归测试,而不是看到功能列表就直接冲。
存储格式不必太紧张——官方并没有放弃"新版本能读旧文件"的兼容策略,老数据库想固定格式版本,用参数手动锁就行。
反倒是异步I/O这部分测得比CONNECT扎实:同样在S3上跑Parquet查询,从v1.5.5的8.230秒降到v2.0开发版的2.844秒,这是能复现的工程测试,不是营销话术。
DuckDB这几年一直在做加法,从嵌入式分析引擎加到湖仓、加到半结构化类型,这次干脆把"服务器"也加了进去。方向没问题——in-process数据库的天花板本来就是单机单进程。但秋天能不能如期发布不是重点,Quack能多快补齐副本读、鉴权、故障恢复这些"未来工作",才是它能不能从演示走进生产的分水岭。