FutureX · Database

本期要点

· Elastic 称其指标引擎比 ClickHouse 快 8 倍，直接对标 ClickHouse 系可观测场景（厂商口径）

· Google AlloyDB 预览「agent 节点」：秒级拉起、只读、与生产集群物理隔离

· Pinecone BYOC 覆盖 AWS / Azure / GCP，数据面留在客户云账号内

· OceanBase 以 GLM-5.2 提交的 Scout 方案登顶 Data Agent Benchmark，90.62%（自报提交）

· 阿里云云栖发布 Agent Context 与 ApsaraLakebase，称 RDS PostgreSQL 新增实例约 80% 由 Agent 创建

· Pinterest 用量化把向量索引压小，生产服务成本降 20%-30%

Elastic 推出指标平台：在 Elasticsearch 中加入专为指标设计的 column store · olap ⚠️ 厂商口径

在投资者电话会上，Elastic 介绍了 6 月随新财年推出的指标产品。公司说，它已经重构了 Elasticsearch，使其能够承担指标负载：日志和链路由文档存储处理，指标交给 column store，向量数据则由向量存储负责。按照设计目标，产品不限制高基数维度，也就是 unique 维度组合数量很大的数据；查询和存储的成本，则通过维度过滤和存储 codec 的调优来控制。Elastic 表示，基准测试和代码已在 GitHub 开源，结果是比 Prometheus / Mimir 快 30 倍，比 ClickHouse 快 8 倍。这些数字都由 Elastic 自己提供，电话会上没有第三方验证。在兼容性方面，公司称产品与常见 PromQL 仪表盘的兼容度达到 90%，同时提供迁移工具。Elastic 还提到，它已收购专做 agent 根因分析的 Deductive AI；更多可观测产品将在 10 月 8 日的 ElasticON 纽约站发布。对 ClickHouse 系来说，Elastic 是从搜索一侧进入指标和可观测的列存赛道。它讲的故事是"AI 负载让指标量暴增"，而双方实际差距如何，还要靠独立基准来检验。^[1]

SereneDB 推出开源引擎 Krummelanke，可直接在 S3 上做全文检索 ⚠️ 厂商口径

Krummelanke 以 Apache 2.0 协议发布，兼容 Postgres 和 Elastic，把搜索与分析合在同一个引擎里。它针对的问题是这样的：分析引擎读取 S3 上的列存数据，靠的是大块顺序扫描，这与对象存储的延迟特性相符；全文检索依赖倒排索引，则需要大量随机访问。因此，Lucene 系引擎通常把索引放在本地闪存上，可搜索的数据就得多存一份，也就是所谓的"copy-first"。SereneDB 说，公司自研的 IResearch 核心能够原地建立索引，不必复制数据。它还称搜索操作"以纳秒计"、十亿级记录的问答"毫秒返回"，并自称"全球最快的数据库搜索引擎"，这些都是厂商自述，未见第三方基准。该公司 CTO 强调，Cloudian 等厂商的做法是给存储桶挂上元数据搜索，而 Krummelanke 的不同在于搜索引擎本身这一层。^[2]

Snowflake Interactive Analytics 夏季更新：新增 Terraform 资源、dbt 物化类型，并优化扫描 · olap

这次的三项更新都围绕"接入现有工具链"。第一，新增 snowflake_warehouse_interactive Terraform 资源，目前为预览，需要在 provider 中开启 preview 特性；此前用户只能借助 snowflake_execute 绕开，结果丢掉了 plan/apply 和漂移检测。第二，从 dbt-fusion v2.0.0 起，Snowflake 适配器原生支持 interactive_table 物化类型，该功能为 beta，且必须指定 cluster_by。第三，Interactive Warehouse 增加了引擎层面的优化：子串 LIKE、非前导聚簇列的等值条件这类谓词无法依靠 micro-partition 剪枝，重复查询时会白白扫描，优化后这类无效扫描减少了。这些改动完善了 Snowflake 主打低延迟交互查询的配套，也是在对标实时分析引擎。^[3]

Google AlloyDB 推出「PostgreSQL for agents」，临时 agent 节点与生产集群物理隔离 · agent

Google Cloud 在 9 月 24 日发布了预览版，使用需要申请。多个 agent 同时反复查询，会带来突发负载。对此，AlloyDB 能在数秒内启动临时的只读 agent 节点，直接从 Colossus 存储读取最新的生产数据；节点的计算、网络和存储路径都与主集群隔离。任务结束后，节点可以停止，计算资源缩减到零，费用按秒计算。它与传统 read replica 的不同在于：replica 通常要提前配置，并有独立的数据复制；agent 节点则是按需创建的一次性算力，用意是把 agent 负载和线上交易分开。^[5]

Pinecone 的 BYOC 模式扩展到 AWS、Azure 和 GCP · vector

Pinecone 的 bring-your-own-cloud 模式，把数据面部署在客户自己的云账号和区域内。Pinecone 的控制面只负责资源生命周期、认证和服务健康，据称不会存储或处理客户内容与请求载荷。运维操作由控制面通过出站调用下发，并在本地执行，因此不需要 SSH、VPN、入站网络，也不需要长期有效的跨账号 IAM 角色。管理员使用的 API、SDK 和控制面流程，与标准部署完全相同。Toyota Motor North America 是首批生产用户，它把制造知识库保留在自己的环境里。报道还称，Pinecone 正在向本地部署（on-prem）延伸。对合规要求严格的客户而言，这算是补上短板，因为 Weaviate、Qdrant、Milvus 等开源向量库原本就可以自托管。^[6]

阿里云云栖大会发布 Agent Context、ApsaraLakebase，并升级 AIDBS · ai-native ⚠️ 厂商口径

阿里云提出了 Context Engine，把企业数据转化为 Agent 可实时使用的上下文，同时发布两款数据库新品。ApsaraLakebase 以对象存储作为单一数据源，支持 Lance、Apache Iceberg、Apache Paimon 等开放格式，使结构化数据、文件、向量索引、图关系和上下文记忆能在同一体系内使用；昆仑万维的 Agent 平台借助它，支撑了 300 万+ 个 Agent 独立工作空间。Agent Context 提供一个可在不同会话、任务和 Agent 之间复用的记忆与知识层。官方称，它能让 token 使用效率提升 3 倍以上，让复杂知识任务的准确率最多提高 50 个百分点；小红书用它为 3000+ 员工的子 Agent 搭建统一的上下文底座。阿里云数据库负责人表示，过去一年里，RDS PostgreSQL 的新增实例环比增长 400%+，其中约 80% 由 Agent 创建，约 50% 的输入输出流量也由 Agent 驱动。以上数据均为阿里云自行报告，未见第三方数据。就产品形态而言，它与 Databricks/Neon 的 Lakebase 思路相近。^[7]

OceanBase 的方案在 Data Agent Benchmark 中夺得第一，准确率 90.62% · ai-native ⚠️ 自报口径

基准 DAB 由 UC Berkeley EPIC Data Lab 和 Hasura PromptQL 联合推出，涵盖 7 个行业以及 PostgreSQL / MongoDB / SQLite / DuckDB 等多种数据库，考察的是 agent 从理解数据到验证结果的端到端能力，不只是 Text-to-SQL。OceanBase 基于 GLM-5.2 构建了内部代号为 Scout 的方案，并称这是榜单上第一个突破 90% 的方案，成绩高于基于 GPT、Claude 系模型的方案。Scout 先通过 DataLens 做数据画像并规划执行路径，再用证据追踪和答案校验形成闭环，这些能力之后会并入 OceanBase DataPilot。这一成绩来自 OceanBase 自己的提交，榜单方的口径应以榜单为准；它反映的是"模型 + agent + 数据系统"的整体组合，并不代表数据库引擎本身的水平。^[8]

Pinterest 的 Manas 改用量化加 SSD 上的 SPANN，取代内存型 HNSW · vector

Pinterest 的搜索平台 Manas 部署了 80 个集群，服务的嵌入数量达数百亿。在 1 亿条 GraphSage 数据集的离线测试中，HNSW 基线占用 121 GB，Recall@100 为 93.72%。加入标量量化（SQ）后，占用降到 50 GB，召回为 92.92%，吞吐反而升到 305.2 QPS；换用乘积量化（PQ）后，占用为 32 GB，召回则降到 77.25%。SQ 用在 IVF 上时，可压缩到 25 GB，召回为 95.71%。方案上线后，生产服务成本下降了 20%-30%；另外，以 SIMD 实现的线性缩放 SQ，使查询算力减少 10%-15%。在 SSD 服务方面，PQ 版 SPANN 的吞吐是 DiskANN 的 3 倍，延迟只有其三分之一，召回下降约 5%；在 50 亿级向量的评估中，它比全内存 HNSW 节省了超过 40% 的 CPU 时间。团队还在试点 ColBERT 类的多向量 late-interaction 检索。上述数据都是 Pinterest 自己的工程数据，不属于第三方基准，但工程细节交代得完整。^[9]

Tiger Data（TimescaleDB）实测：一条 20 字节的传感器读数，落盘后占 95.6 字节 · oltp

Tiger Data 给出了估算方法。timestamp + tag_id + float 合计 20 字节，再加上 23 字节的 tuple 头、对齐填充和索引，实测每行占用 95.6 字节，约是朴素估算的 4.8 倍；按文中的说法，"看似 12 TB 的方案，实际是 60 TB"。文章测得，在 10 万级传感器规模下，重写表需要持有 ACCESS EXCLUSIVE 锁：1000 万行约耗时 19 秒，据此推算 6310 亿行约需两周。测试环境为 Postgres 16.13、2 核、128 MB shared_buffers；作者自己也说，数字会因环境而异，文章的价值在于方法，即先用真实的行和真实的索引建立 PoC 表，再进行测量。这篇文章出自 TimescaleDB 厂商，同时也是在为自家的时序扩展做铺垫。^[10]

DuckDB 可直接读取 Hugging Face 上的数据集 · olap

DuckDB 官方博客介绍，用户无需先下载，就能直接读取 Hugging Face 上的数十万个数据集。DuckDB 一直被定位为跨引擎的"数据结缔组织"，这一条属于使用层面的扩展。^[11]

Neon 披露：Electric 团队并入后，将为 Neon 开发 realtime 同步 · agent

Neon 的后端已全线 GA，下一步是在平台中加入 realtime / sync，由已加入 Databricks 旗下 Neon 的 Electric 团队负责。Electric 联合创始人 James Arthur 认为，sync 更适合作为 BaaS 平台的一项功能，而不是独立产品，并且 agent 需要更高层的抽象。他还承认，realtime 常常"demo 时表现很好，上了生产就掉链子"，根本的矛盾在于可同步内容的表达力与性能之间的取舍。目前这只是路线图层面的说法，发布时间和产品细节都还没有。^[12]

Aiven 进军印度市场；Snowflake Cortex AI 上线 Kimi K3 · cloud

芬兰的托管数据基础设施厂商 Aiven 宣布进入印度，目标是当地对 AI 和云数据基础设施的需求。同一天，Snowflake 宣布 Kimi K3 在 Cortex AI 上线，平台内可以调用的第三方模型又多了一个。这两条消息都只有标题层面的信息，细节没有展开。^[13]

FutureX · 记录未来如何发生

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