来源：https://duckdb.org/library/what-next-for-duckdb/
《开发者之声》访谈总结：DuckDB的崛起、扩展与AWS收购
一、DuckDB的初心与成功之困
DuckDB是一款本地单文件分析型数据库，核心定位是"SQLite for Analytics"------极快、极简、可直接查询CSV/JSON/Excel等文件而无需预先定义Schema。两位创始人汉内斯·米勒森与马克·拉斯维尔特自八年前从零开始构建，出发点是用户友好优先，打破数据库学术界与实践脱节的局面。
然而成功带来新问题：海量功能请求、社区PR涌入、企业客户需求涌现。汉内斯坦言，最坏情况是被迫远离技术、转而去管理销售和营销团队。为此，他们构建了扩展机制，把非核心功能（如图处理、Excel读取）交给社区插件维护，保持核心精简。
二、重要技术演进
1. 客户端-服务器协议Quack
汉内斯曾坚决不做客户端-服务器，但社区自行开发了至少五六个RPC封装，需求明确。于是他"食言"推出Quack，并表示"一致性被高估，解决问题更重要"。Quack完全重写了数据库线路协议------他们曾发论文指出Postgres协议每行都带类型头、效率极低，而Quack从零设计，更适配分析场景的大批量数据传输。
2. 扩展机制的深化：可插拔解析器
为免于被海量语法需求淹没，DuckDB重写了SQL解析器。旧版基于Postgres的LALR(1)解析器有2万行语法、需在词法分析阶段合并"ORDER BY"等双词关键字、无法处理注释注解，且不可扩展。他们改用PEG解析器（递归下降、支持运行时动态加载语法规则），并自研了PEG解释器。此举使扩展可自定义SQL方言，甚至禁用部分语法以强制流式执行。
3. 异步IO与Parquet优化
为支持Iceberg远程文件读取，DuckDB在2.0中引入异步IO线程池，避免网络阻塞，该优化惠及所有Parquet读取场景。
三、Iceberg、Avro与DuckLake
Iceberg是数据湖上的表格式，解决Parquet文件变更管理问题。因连续两年成最常被请求功能，DuckDB由企业赞助实现完整支持。汉内斯对Iceberg底层格式Avro颇有微词：无Schema无法解码、压缩块导致点查需解压整块、元数据用JSON冗余。更让他不满的是Iceberg"拼命不用数据库"------变更元数据放在Avro/JSON文件里，最终却不得不在REST目录服务后挂Postgres。
于是他们推出DuckLake，直接用数据库管理元数据，查询计划简化为一次SQL查询，底层Parquet文件与Iceberg兼容（可互导）。该扩展下载量已追平Iceberg扩展，被真实企业用于生产。
四、企业化与AWS收购
DuckDB用户从个人笔记本扩展到Spotify（为每位用户临时实例化DuckDB做AI问答）、大型药企（从Spark迁移节省数亿美元）等企业级场景。公司DuckLabs从自筹资金的学术团队扩至30余人，月下载量超百万。但汉内斯明确拒绝走"销售驱动开发"路线------他咨询过其他数据库创始人，结论是销售最终会决定工程方向。
因此，DuckLabs将被AWS收购（保留子公司身份），但关键制约条件是：
- DuckDB基金会（非营利）保持独立，类似Tabular卖给Databricks但Iceberg仍属Apache；
- AWS承诺长期支持基金会项目，且不干涉技术路线；
- 收购将为DuckDB带来真实工作负载反馈（过去无遥测，全靠GitHub报障，无法判断优先级），这是闭源竞品（如Snowflake）的核心优势；
- 更多人力与计算资源，同时汉内斯坦言要重新适应"有老板"和绩效评估，但AWS给予他的上级是合作多年的熟人，令他安心。
五、2.0及未来规划
DuckDB 2.0将于2026年10月发布，亮点包括：
- 可插拔PEG解析器正式上线；
- 触发器支持（呼应"服务器年"战略）；
- 后续将实现存储过程（PL/SQL风格，由专攻编译优化的博士负责）；
- 以上功能均编译至Wasm，可在浏览器中运行。
六、核心理念
汉内斯反复强调一条哲学："不是告诉用户他们应该怎么用，而是解决他们实际遇到的问题。" 为此他们宁可收回"不做客户端-服务器"的誓言，也要推出Quack；宁可重写整个解析器，也要让扩展能改变语法。他视被AWS收购为避免沦为销售导向公司、保持技术驱动的最佳路径，并期望DuckLake能推动整个数据湖生态转向更合理的元数据管理方式。