如果你平时会折腾本地数据分析，大概率听过 DuckDB 这个名字。最近半个月，这只鸭子在数据圈被提起的频率明显变高，原因有两个。
8 月 5 日，DuckDB 的 GitHub 星数突破了 40,000。这个数字放在开源数据库圈是什么概念？知乎上一篇深度调研给了个直观对比：MySQL 12,000 星，PostgreSQL 18,000 星，DuckDB 一家超过了两大关系型数据库的总和。知乎同期它每个月有 800 万人访问官网，扩展每天被下载 700 万次。另一边，社区正在集中讨论另一件事：DuckDB 2.0 定档今年秋季发布。微博知乎这不是常规小版本迭代——2.0 是 DuckDB 诞生以来的第二个大版本号，也是它第一次从「单机工具」往「数据平台」迈步。今天就把它讲清楚：2.0 到底改了什么、谁值得等、谁完全不用等。
2.0 最大的变化：鸭子要当服务器了
多数人对 DuckDB 的印象是「嵌入式」：pip install 一下，import 进来，直接对本地 CSV、Parquet 跑 SQL，没有服务、没有端口、用完即走。
2.0 会改变这个默认印象。它引入了 Quack 远程协议，DuckDB 实例既可以作为客户端，也可以作为服务端被其他 DuckDB 或工具访问，多个客户端能连到同一个实例做并发读。翻译一下：以前一个 .duckdb 文件是「一个人抱着跑」，现在一只鸭子可以「一个团队围着查」。嵌入式数据库能通过 Quack 协议变成标准客户端-服务器数据库，这一步在 5 月协议 beta 时就已在社区传开。微博
Quack 协议其实在 1.5.2 里就已经以 beta 形态出现，2.0 会把它推到稳定。别小看这一步——DuckDB 此前最常被吐槽的短板之一就是没法共享，数据文件躺在本地，谁拿到谁才能查。团队场景一旦打开，它就是从「个人分析利器」变成「团队分析引擎」。
第二个变化：查网络存储的数据，终于不卡了
经常对 S3、OSS 这类对象存储跑查询的人，会等到 2.0 里一个实打实的硬核升级：异步 I/O。
DuckDB 目前的 I/O 是同步的——查询在等磁盘或网络返回时，整条执行流水线就停在那儿干等。异步 I/O 上线后，DuckDB 在等 S3 返回数据时可以切到别的任务继续算，让 I/O 并发度独立于 CPU 并发度扩展。知乎这个需求在官方 GitHub 上讨论了好几年，湖仓查询场景下最大的瓶颈就是网络带宽，这次算是正面回应。
查询优化器和执行引擎也一并全面增强：部分聚合下推到 Join 之前、递归 CTE 引擎重写、聚合算子支持磁盘溢写。官方给出的递归图查询测试里，新版本拿到了 40 倍的性能提升。知乎现有 SQL 不用改一行就能吃到性能红利，这种「升级即白赚」的部分永远最实在。
一个必须留意的破坏性变更：lambda 写法直接报错了
如果你已经在用 DuckDB 的 lambda 表达式，这条要记下来：旧的 `x -> x + 1` 写法，在 1.5 里只是警告，到 2.0 会直接报错，需要统一换成 Python 风格的 `lambda x : x + 1`。知乎这属于典型的「新功能介绍里一笔带过、升级当天让你抓狂」的变更。线上代码里 lambda 用得多的，建议趁现在还在 1.5 就提前排查替换，别等 2.0 装上的那一刻再满屏找报错。
几个值得关注的加分项
除了上面三件大事，2.0 还有一些特定人群会很兴奋的功能：
触发器（Trigger）：DuckDB 一直以来都不支持触发器，2.0 补全了完整功能，比如拿来做审计日志。
NEAREST 连接查询：把向量搜索里的 top-k 相似查询变成原生 SQL 能力，对玩 RAG、本地向量检索的人来说意义不小。
MATCH_RECOGNIZE：对标 SQL 标准的模式匹配语法，专用于时间序列里的事件检测，常被拿来和 ClickHouse 的类似功能对比。
VARIANT 类型补全链路：1.5 引入的 VARIANT 半结构化类型，2.0 补齐压缩存储、查询下推、Parquet 读写，做日志、埋点分析的值得重点看。
自研新 SQL 解析器：替换了沿用多年的 PostgreSQL Parser，扩展首次可以注册自己的 SQL 语法，生态的玩法会变多。
那么现在，我该装哪个版本？
可能有人还没注意到，DuckDB 从 1.4 开始就有 LTS（长期支持）版了。把当前选项捋一遍：
求稳、跑生产：用 1.4 LTS，代号 Andium（安第斯鸭）。这是 DuckDB 首个长期支持版，AES256 加密、Git 式 upsert、Iceberg 写入这些重磅能力都是在 1.4 落地的。想尝鲜、做本地分析：用 1.5.x。最新的 1.5.5 在 7 月 22 日发布，带来了全新设计的命令行客户端、处理半结构化数据的 VARIANT 类型，还有内置的几何类型支持。哔哩哔哩值得等 2.0 的，是这三类人：想把一个分析实例共享给团队用的、重度查 S3/OSS 对象存储数据的、以及想用原生 SQL 做向量 top-k 检索的。
说得更直白一点：如果你的场景还是「本地文件跑 SQL」，现在的 1.5 就完全够用，不必等；如果你的目标本来就是团队共用、数据在对象存储上，那这两个月的等待是值得的。
泼盆冷水：这几种情况别碰 DuckDB
社区里这几天满是「DuckDB 正在变得不可阻挡」的声音，但越热的时候越要提边界。这个工具的短板和它的优点一样清晰：
多用户并发写，不行。DuckDB 支持多进程并发读，但它的 MVCC 是为单写者优化的，多人同时写同一个实例不是它的设计目标。知乎流式高吞吐写入，也不行。ClickHouse 轻松扛 10 万+ 每秒插入，DuckDB 的插入性能从来没往这个方向优化。数据超过 2TB，别硬上。DuckDB 的上限大概在单机 2TB 以内，再往上就该交给 Snowflake、BigQuery 或 ClickHouse 集群了。1000+ 并发用户的实时大屏，同样不是它的目标场景。
用值得买的话术总结：DuckDB 值得买，但不是万能药——它解决的是「数据没大到要上集群、但 Pandas 又真的扛不住」这段最尴尬的区间。这段区间里的体验，目前确实没有对手。
接下来值得盯什么
最后给几条持续关注的线索：
第一，2.0 的正式发布时间。官方口径是今年秋季，可以顺带看看版本代号会不会继续用真鸭子的学名命名——从 1.0 开始这是保留节目。第二，Quack 协议稳定版落地后的实际体验：客户端工具、权限模型能不能跟上，决定它进团队场景的成色。第三，生态动向：lakehouse 开放格式 DuckLake 已经在今年 4 月进入 1.0，围绕 DuckDB 的新 ETL 项目也在快速升温，比如三个月就攒下 1157 星的 Duckle。知乎这条赛道肉眼可见地热闹起来了。
还在犹豫要不要学 DuckDB 的话，我的建议是：现在入场正好。1.5 足够成熟，2.0 的预期足够清晰——这只鸭子，值得跟。
