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 的主要卖点是在同一套 Paxos 三副本架构里同时跑 OLTP、HTAP 和纯分析负载，再加上库内 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：读回的 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 并行开发时，各自从 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]

来源链接

[1] 〔2 方报道〕Yellow.com；Cryptopolitan ｜ 10月9日 https://yellow.com/zh/press-releases/oceanbase%E5%8F%91%E5%B8%83evolvingx%EF%BC%9A%E9%9D%A2%E5%90%91%E2%80%9C%E6%B0%B8%E4%B8%8D%E5%81%9C%E6%9C%BA%E2%80%9D%E6%80%A7%E8%83%BD%E4%B8%8E%E6%97%A0%E7%BC%9D%E6%89%A9%E5%B1%95%E7%9A%84%E6%96%B0%E4%B8%80%E4%BB%A3%E6%95%B0%E6%8D%AE%E5%BA%93%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88 https://www.cryptopolitan.com/zh-cn/oceanbase-launches-evolvingx-a-database-solution-for-always-on-performance-and-seamless-growth/

[2] 〔来源〕DuckDB ｜ 10月9日 https://duckdb.org/2026/10/09/agent-mode.html

[3] 〔来源〕Databricks ｜ 10月9日 https://www.databricks.com/blog/lakebase-and-agentic-sdlc-branching-databases-coding-agents

[4] 〔来源〕Databricks ｜ 10月9日 https://www.databricks.com/blog/load-terabytes-data-minutes-lakebase-postgres

[5] 〔来源〕github.com ｜ 10月8日 https://github.com/duckdb/ducklake

[6] 〔来源〕TimescaleDB ｜ 10月9日 https://www.tigerdata.com/blog/measuring-how-fast-iiot-queries-degrading

[7] 〔来源〕arXiv https://arxiv.org/abs/2610.10282

[8] 〔来源〕arXiv https://arxiv.org/abs/2610.11563

[9] 〔来源〕arXiv https://arxiv.org/abs/2610.11230

[10] 〔来源〕arXiv https://arxiv.org/abs/2610.12300

[11] 〔来源〕Dealroom ｜ 10月9日 https://app.dealroom.co/news/note/infino-exits-stealth-with-7-5m-seed-to-unify-data-search-for-ai-agents

FutureX · 记录未来如何发生

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