━━━━━ 正文从此处全选复制 ━━━━━

FutureX · Database

本期要点

· DuckDB v2.0 的 CLI 加入 agent mode：识别出调用方是编码 agent 后改用紧凑输出，agent 读回的 token 少了 59%，但总成本几乎没降

· Infino 结束隐身模式，获 750 万美元种子轮，由 Bessemer 领投，主打用一个引擎同时做全文检索、向量检索和 SQL

· Databricks 把 Lakebase 的批量导入交给 Spark 执行，避开 OLTP 主节点，称导入 1 TB 用时不到 5 分钟

· 一篇论文给出 join ordering 的确定性算法，复杂度降到 O*(2.9997ⁿ)，首次严格低于长期存在的 3ⁿ 界

▎ 版本与产品发布

OceanBase 推出面向数字资产平台的 EvolvingX 方案 · oltp ⚠️ 厂商口径

OceanBase 国际业务在新加坡举行的 TOKEN2049 大会上推出了 EvolvingX。它并非新的数据库内核，而是基于自家分布式引擎打包而成的行业方案。目标客户是交易所之类的业务，这类业务的撮合、行情、风控和账本系统都要全天候 7×24 运行。据厂商公布的数据，3 节点（每节点 32C128G）能够持续承受每秒 15 万笔写入，P99 写入延迟在 1ms 以内，P99 查询延迟在 20ms 以内；在 6 节点的测试里，各节点 CPU 利用率保持在 14%-22%；异构实例换成同构集群之后，月度基础设施成本最多可降低近 70%；覆盖 8 大类 30 个场景的 MySQL 兼容 PoC 也全部通过。这些结果都是厂商在自己的配置下测得的，没有经过第三方复测。就定位而言，OceanBase 的主要卖点，是让 OLTP、HTAP 和纯分析负载在同一套 Paxos 三副本架构中运行，并辅以库内 AI 和混合检索，以此取代分库分表加独立分析库的组合。此次借加密行业大会的机会，它进入了新加坡市场。[1]

其他版本动态：
· ClickHouse 的三条维护线接连发布补丁，分别是 v26.9.14.10-stable、v26.8.22.13-lts 和 v26.3.46.2-lts（10月9日）
· 前一天则已经发布了 v26.9.13.15、v26.8.21.10、v26.7.25.6 和 v26.3.45.3。 YugabyteDB 的 2025.2.8.0、2026.1.3.0、2024.2.12.0 三条线发布了多个回移构建，其中一个构建修复了 DocDB 线程池中的 heap-use-after-free 问题。 Weaviate v1.39.11 修复了队列、备份和关停流程中的可靠性问题，同时补上了一个 zlib 的 CVE。 LanceDB 在同一天发布了 v0.41.0-beta.1 至 beta.3，这三个版本都包含破坏性变更（惰性迭代器、远程 API 实体名校验统一等）。 TiDB 发布了 v26.3.19。 Apache Doris 发布了 4.1.5-rc01。 Materialize 发布了 v26.46.0-rc.1。 Apache Paimon 2.1.0（含 PyPaimon）已进入 RC4 投票。

▎ 数据库 × AI

DuckDB CLI 新增 agent mode：agent 读回的 token 减少 59%，总成本却基本不变 · agent

DuckDB v2.0 的 CLI 能自动判断调用方是否为编码 agent。要同时满足三个条件才会进入 agent mode：环境中设置了 Claude Code、Codex、Cursor 等 agent 会写入的环境变量之一，stdout 不是终端，命令行上也没有指定输出格式。进入该模式后，表格不再使用加边框、补空格对齐的样式，而是换成紧凑的 Markdown；结果被截断时会明确告知，失控的查询会被提前终止，错误信息以 JSON 返回，较长的查询在开始运行之前会先报告预计开销。这项改动要解决的是一个具体的问题：默认渲染器在截断大结果时，只在中间放一行省略号，再在页脚注明“(40 shown)”。模型很容易略过这一行，进而把没有看到的数据当作完整结果去推断。

官方实验的做法是：让 Claude Code 用自然语言回答 TPC-H SF100 的 22 道题，开启和关闭 agent mode 各运行三遍，132 次结果全部正确。agent 读回的 DuckDB 输出由 12.36 万 token 降到 5.08 万。官方同时写出了对这一结果不利的部分：每一轮对话都要重新读入系统提示词，其篇幅远大于查询输出，因此省下的 token 只占总输入的约 0.5%，总成本和耗时都看不出差别，开启之后对话轮数还从 224 增加到 237。由此可见，在 agent 场景里，压缩数据库输出的主要好处是减少模型对截断结果的误读，对账单的影响很小。[2]

Databricks Lakebase 让每个编码 agent 各用一个独立的数据库分支 · agent

Databricks 公布了一套参考工作流，并配有 GitHub Actions 示例仓库。在多个编码 agent 并行开发的情形下，每个 agent 都从 Lakebase Postgres 拉出自己的分支，在分支上做 migration 和测试，用完就丢弃。这些分支基于 copy-on-write，官方称无论数据库多大，都能在一秒内建好，只有数据出现分歧以后才会多占存储；空闲的分支可以缩容到零，因而不产生计算费用。文章还建议从脱敏后的种子库而非生产库拉分支，以免泄露 PII。分支功能在 Neon、Supabase、pgEdge 等 Postgres 厂商那里早已是标配，所以这篇文章并没有带来新的能力；真正的变化是，Databricks 开始把它当作 agent 开发流程中的默认环节来推广。[3]

▎ 湖仓 · 开放表格式 · HTAP

Lakebase 通过 LTAP 把批量导入交给 Spark，不再占用 OLTP 主节点 · htap ⚠️ 厂商口径

Databricks 将这套架构称为 LTAP，意思是事务引擎和分析引擎直接读写湖上的同一份数据。在原生 Postgres 中，批量导入的每一行都得由承载线上流量的主节点生成 heap 页、更新索引并写入 WAL，主节点因此成了唯一的瓶颈。Lakebase 的改法是由 Spark 并行生成 heap 页，主节点就不必再承担导入负载。公司给出了一个 beta 客户的案例：该客户每天通过 Synced Tables 导入约 10 亿行，原先耗时 8 小时以上，这段时间里 CPU 和内存被占满，只能大幅超配 OLTP 资源。按内部基准的说法，导入 1 TB 用时不到 5 分钟，不过这个数字只统计建 heap 页的时间，不含建索引，并行建索引的功能仍在开发。本刊 9 月 29 日报道过 Lakebase 的两个搜索扩展，而这是它在 Postgres 之上补充的另一项能力，让大规模导入与线上服务不再互相争抢资源。[4]

DuckLake 仓库登上 HN，收获 232 个赞 · lakehouse

DuckLake 是 DuckDB 团队推出的湖仓格式，它把元数据存放在一个 SQL 数据库中，把数据存成 Parquet 文件。它不像 Iceberg 那样采用层层嵌套的元数据文件设计，所以一直被视为 Iceberg 路线的对照。今年 4 月，它随 DuckDB 1.5.2 发布了 v1.0 规范，并把删除缓冲区改存为与 Iceberg 兼容的 Puffin 文件。这次登上 HN 并没有新版本发布，热度来自社区持续的关注：本刊 10 月 8 日报道过 DuckDB 官方演示的“纯视图库文件作为共享目录”，而 DuckDB v2.0 也定在本月发布。[5]

▎ 技术 · 架构 · 性能基准

Tiger Data 提出为 IIoT 查询的变慢趋势拟合曲线，推算何时超标

Tiger Data（TimescaleDB 背后的公司）发布了一套可以直接操作的方法。它的思路是：对建有索引的点查，成本随 log(n) 增长；而时间窗口随表一同变大的聚合查询，成本随 n 线性增长。因此加索引只能把曲线的起点压低，斜率却不会变。具体做法是用 pg_stat_statements 定期记录查询的延迟和行数，据此拟合出曲线，再推算这条查询在哪一天会超出延迟目标。示例数据取自一支拥有 5000 个传感器、每 10 秒采样一次的车队：每天新增 4300 万行，基数为 10 亿行。这种方法论文章对时序和可观测场景的容量规划有参考价值，ClickHouse 用户同样可以使用。[6]

学界 · 研究前沿

· Truly Sub-3ⁿ Min-Sum Subset Convolution and Join Ordering（arXiv 2610.10282）：论文先把 min-sum 子集卷积归约为 min-plus 矩阵乘，再利用 Alman 与 Vassilevska Williams 最近提出的亚立方算法，得到期望复杂度为 O*(2.9987ⁿ) 的 Las Vegas 算法，以及复杂度为 O*(2.9997ⁿ) 的确定性算法。join ordering 动态规划长期存在的 3ⁿ 界因此被严格突破，但这属于理论上的进展，距离优化器能够实际采用还很远。[7]

· Grant（arXiv 2610.11563）：该工作研究多个属性同时带有范围过滤条件的 ANN 检索。已有研究大多只支持单个属性或等值过滤，而通用的先过滤或后过滤做法效率很低，这也是向量库处理混合查询时常见的痛点。[8]

· CORAL（arXiv 2610.11230）：这是一种用于跨模态检索、由 GPU 加速的图向量索引。它在 GPU、CPU 和磁盘之间分层管理内存，并支持动态更新，要解决的是当查询向量与库中向量分布不一致（OOD）时，常规索引性能大幅下降的问题。[9]

· Compact and Efficient Indexes for Learned Sparse Retrieval（arXiv 2610.12300）：论文在 SEISMIC 的基础上，用 medoid（以一篇现有文档来代表一个块）取代每个块的稀疏向量摘要，同时压缩前向索引，使学习型稀疏检索的内存占用大幅缩小，检索效率却没有损失。[10]

▎ 融资 · 并购 · 商业化

Infino AI｜种子轮｜750 万美元 · agent

Infino AI 宣布走出隐身模式，并完成了 750 万美元种子轮融资，领投方为 Bessemer Venture Partners。CEO 是 Ekechi Nwokah；The New Stack 报道称，创始团队来自 OpenSearch。公司把产品定位为“agent 检索层”：数据以 Parquet 格式存放在对象存储中，同一个引擎直接在这些数据上完成全文检索、向量检索，以及 SQL 的过滤、join 和聚合，以此取代由搜索引擎、向量库、数仓加 ETL 拼成的方案。核心引擎以 Apache-2.0 协议开源，托管的 Infino Cloud 则是商业版本。公司称其成本比传统搜索基础设施低约 10 倍，但这是公司自己报出的数字，没有经过独立验证。和 turbopuffer、LanceDB 一样，它走的是“以对象存储为底座、按需叠加检索能力”的路线。[11]

文中 [N] 为来源编号，全部来源链接请点文末「阅读原文」查看。

FutureX · 记录未来如何发生

素材来源多方媒体/网络新闻