Quack 协议：DuckDB 正在吃掉数据库中间件
alitrack约 3 分钟不只是远程查询：Quack 协议正在让 DuckDB 吃掉数据库中间件
5月12日，DuckDB 团队发布了 Quack——一个基于 HTTP 的客户端-服务端协议。两个月过去，社区涌现了一批让人眼前一亮的真实应用。它们共同指向一个趋势：DuckDB 正在从"单机分析引擎"变成嵌入式数据库 + 可选网络服务的通用数据层。
从"必须停服"到"边跑边看"
HN 用户 steve_adams_86 分享了一个典型场景：他用 Deno 服务器把传感器数据持续写入 DuckDB，想看数据时必须关掉服务器才能用 duckdb -ui。Quack 彻底解决了这个尴尬——CALL quack_serve(9494) 之后，另一个终端直接 ATTACH 'quack://localhost:9494'，数据照写不误，查询同步进行，零停机。
浏览器直接连数据库
Quack 基于 HTTP 而非 gRPC，有一个被严重低估的好处：DuckDB-WASM 原生支持。Hannes Mühleisen 在 AI Council 2026 现场演示了浏览器 tab 里的 DuckDB 直连 EC2 实例——不需要 WebSocket、不需要代理、不需要任何中间件。
这意味着一个静态 HTML 页面 + DuckDB-WASM，就能给团队一个实时数据看板。后端只是一个 duckdb --quack 进程。
DuckLake 的 Catalog 从 Postgres 换成 DuckDB 自己
DuckLake（DuckDB 的 lakehouse）之前必须依赖 Postgres 或 SQLite 做元数据 catalog。Quack 发布当天社区就在问：能不能让 DuckDB 自己做 catalog？答案是能，而且只用了 6 天就实现了（ducklake#1151，5月12日合并）。
DuckDB 开发者 Pedro（pdet）在 HN 上解释了三重优势：无类型错配（DuckDB 读 DuckDB 不需要 VARCHAR→TIMESTAMP 映射）、更快（DuckDB 扫描自己的 catalog 比 Postgres scanner 快）、零往返重试（高竞争写入的事务重试全在服务端完成，不走多轮 Postgres round-trip）。
列式电子表格：消掉整个 HTTP 层
microflash 在 HN 上说："我在做一个 Excel 风格但列式的电子表格应用，之前不得不用传统 HTTP 层自己造客户端。Quack 直接消掉了这一层。"
这个场景的意义在于：任何需要多用户协作 + SQL 分析能力的本地应用，现在可以不加 Postgres 依赖，直接让 DuckDB + Quack 承担全部后端数据层。 所有你需要的 SQL 能力，DuckDB 都有——窗口函数、CTE、空间查询、全文检索、向量搜索——而且不用部署、不用运维。
30GB 二进制数据库文件当应用后端
whalesalad 的团队把数据流水线产出 30GB 的 .duckdb 文件放到 S3，应用监听 etag 变化自动拉取——得了 ClickHouse 级别的查询性能，月账单是零。Quack 之后，这个模式的下一步顺理成章：多客户端并发写入同一个 DuckDB 实例，不再需要"下载→本地查"的离线模式。
驱动生态已在跟上
- ADBC 驱动
：GizmoData 发布了 adbc-driver-quack，返回 Arrow RecordBatch，支持 bulk ingest - JDBC 驱动
：同一团队同步发布 quack-jdbc - TypeScript SDK
： @quack-protocol/sdk（npm v0.2.0）已支持完整的查询、流式读取、事务、Arrow 结果、连接管理，浏览器和 Node 双可用
范式判断
Quack 和传统数据库的客户端-服务端有一个根本区别：它是嵌入式 by default，翻一个开关变服务端。 不是"先部署一个数据库集群，再写应用"，而是"先写应用，需要多用户共享时跑一个 quack_serve"。
如果 DuckDB v2.0 按计划在秋季发布，Quack 将从 beta 毕业。届时一个 Docker 容器跑 duckdb --quack，就能替代相当一部分"Postgres + Redis + 消息队列"的中间件组合——不是因为它能全部替代，而是因为大部分场景根本不需要那么重。
GizmoSQL 的 Philip Moore 是最早把 DuckDB 做成客户端-服务端的先行者。HN 上有个评论总结得最到位："不是 DuckDB 想变成 Postgres，而是它正在变成现代数据工具栈里的 SQL 执行层——嵌入到工具里，需要时翻出来当服务器用。"