FutureX · Database

本期要点

· Pinot 1.6.0 发布：SQL DDL 建表，向量加 IVF 后端

· Databricks 实时模式进声明式管道并 GA，对标 Flink

· Pinecone 开源 PG 扩展 pg_pinecone

· OrioleDB 在 Supabase 公测，替换 PG 堆存储

· Brotli 漏洞波及面扩至 DuckDB 与 Apache Arrow

Apache Pinot 1.6.0 推出：加入 SQL DDL、多维聚合和 IVF 向量索引 · olap

Apache Pinot 1.6.0 已正式发布，此时距 RC0 进入投票还不到两周。变化最明显的是表管理：用户通过 controller 的 /sql/ddl 端点，就能执行 CREATE TABLE / DROP TABLE / SHOW CREATE TABLE；物化视图同样支持 DDL，并支持单阶段查询改写。过去 Pinot 建表主要依靠 JSON table config 配合 REST 调用，易用性一直不如 ClickHouse、Doris 等原生支持 SQL DDL 的引擎，这个版本补上了这一环。在分析能力上，两套查询引擎现在都支持 GROUPING SETS / ROLLUP / CUBE；多阶段引擎增加了流式 distinct 执行，lookup join 的规划也得到了改进。

除 HNSW 外，向量检索又增加了 IVF_FLAT、IVF_PQ、IVF_ON_DISK 三种后端，同时支持过滤感知检索和半径查询。ClickHouse 的向量相似度索引目前采用 HNSW 方案，而 Pinot 这次同时提供了 IVF 和落盘索引，针对的是内存容纳不下的大规模向量场景。在数据类型上，新增了用于演进型嵌套数据的 OPEN_STRUCT 以及逻辑 UUID 类型；摄取端则支持 Arrow IPC 批量写入和 BSON 输入。升级之前需要留意两点：Pinot 服务端现在要求使用 Java 25 或更高版本，Spark 连接器的默认版本改成了 Scala 2.13。^[1]

Databricks：Spark 声明式管道中的 Real-Time Mode 正式 GA · streaming ⚠️ 厂商口径

Real-Time Mode（RTM）已在 Spark Declarative Pipelines（SDP）中正式 GA。RTM 于去年推出，是 Structured Streaming 引擎的演进版本：数据持续流动，各查询阶段同时运行，上游一有产出就交给下游，不必等微批攒满，端到端延迟因此达到毫秒级。RTM 进入 SDP 以后，欺诈评分、实时告警、实时特征计算这类低延迟场景，也可以使用 SDP 自带的依赖解析、增量处理、故障恢复和数据质量约束。serverless 版本按查询实际使用的核数计费，用户既无需选型，也无需配置集群。

Databricks 的意图很清楚：让客户不必在 Spark 之外再维护一套 Flink。它拿客户的特征计算负载做了对比，宣称 RTM 比 Flink 快最多 92%，并公开了数据集和查询仓库。但这是厂商自行运行的基准，目前没有第三方复现。^[2]

Supabase：OrioleDB 存储引擎向全部套餐开放公测 · oltp ⚠️ 厂商口径

OrioleDB 已向 Supabase 的所有套餐开放公测，用户建项目时可以选用，计费方式与标准 Postgres 一致，官方明确表示它暂时不适合用于生产环境。OrioleDB 借助 Table Access Method（Postgres 存储引擎的插件接口），取代了默认的 heap 存储。heap 的问题在于，每次更新都会写入新的行版本并留下 dead tuple，未改动的列上的索引通常也要新增条目，之后还要由 autovacuum 清理，所以更新密集的表容易膨胀。使用 OrioleDB 时，连接串、RLS 和客户端库都不必修改。这次公测的版本是 OrioleDB beta19 + Postgres 17.11。

性能数据来自 Supabase 自建的开放基准站 DBArena。其负载衍生自 TPC-C，因此不能与官方 TPC-C 成绩相比较，代码和原始结果均已公开。在数据量为内存 4 倍的场景下，OrioleDB 在所测的每一档规格上，单位成本吞吐都是最高的；在 8XL（32 vCPU / 128 GiB）实例上，它每分钟处理的事务数约为堆存储 Postgres 的 1.8 倍。^[3]

Supabase：Multigres 进入私有 alpha，Postgres 三节点可自动故障转移 · oltp

Multigres 出自 Vitess 原班团队，今年 6 月以 Apache 2.0 许可开源了 v0.1。这次是它第一次在 Supabase 平台上运行，目前处于私有 alpha 阶段，只接受付费组织申请。启用之后，项目会在三个可用区中各运行一个 Postgres 节点，并自带连接池和自动故障转移。Multigres 不 fork Postgres，只在外围负责路由、复制、故障转移和备份。设计上的关键取舍，是把故障转移当作共识问题来处理：它在同步复制之上实现了通用共识协议，写入要复制到足够多的节点之后才向应用确认，提升新主节点之前，也要先确保该节点拥有全部已确认的提交。切换期间，网关可以先暂存请求，而不是直接向应用返回连接错误。^[4]

LanceDB v0.41.0：嵌入配置默认不再信任，MemWAL 改名为实时引擎 · vector

LanceDB v0.41.0 稳定版建立在 Lance 14.0.2 之上，包含较多破坏性变更，延续了 v0.40 系列 beta 频繁调整接口的做法。最值得关注的是安全方面的迁移：SentenceTransformerEmbeddings.trust_remote_code 的默认值改为 False。从表元数据还原远程代码模型或自定义 endpoint 时，必须在进程级别明确批准，否则计算嵌入就会抛出 UntrustedEmbeddingConfigError。此外，原来的 LSM 接口先改名为 MemWAL，随后又改为 RTE（realtime engine）；物化视图一律改为全量刷新；新增了授权 API；多个列表接口改成惰性迭代器。本地 SQL 计算列和物化视图仍是实验特性，官方 Python/Node 包默认不启用。^[5]

EDB 预览 Postgres 分片横向扩展，计划 2027 年 2 月 GA · oltp ⚠️ 厂商口径

EDB 为 EDB Postgres AI Distributed 推出了横向扩展预览。它通过分片，把事务写入分散到多个 shard group，每个 group 沿用现有的复制、自动故障转移和可配置持久性，目的是突破单机的写入上限，并计划在 2027 年 2 月 GA。目前这项功能仍处在预览和路线图阶段。^[6]

Pinecone 开源 pg_pinecone，将自家向量索引移入 Postgres · vector ⚠️ 厂商口径

Pinecone 是独立向量数据库的代表厂商，它以 Apache 2.0 许可开源了 Postgres 扩展 pg_pinecone。该扩展直接作用于 pgvector 已有的向量列，要求使用 PostgreSQL 17/18，并已安装 pgvector。在本地运行时无需 Pinecone 账号和外部 API，也可以切换到 Pinecone 托管云执行检索，Postgres 仍是主数据库。在技术上，它不采用 HNSW 的图结构，而是先对向量聚类再压缩存储，并在检索过程中施加过滤；pgvector 的 HNSW 通常在检索之后才过滤，过滤条件严格时容易漏掉召回。

Pinecone 的自测数据显示，100 万向量的索引为 136 MB，pgvector HNSW 则为 4.1 GB；建索引耗时 45 秒对 79 秒；召回率 99% 时延迟为 2.3ms 对 6.7ms。这与 Tiger Data 本月开源的 pg_vectorsearch 方向一致，后者以分区索引 PRISM 替代 HNSW；Andy Pavlo 不久前也评论过，向量数据库的护城河只是一个索引。如今专业向量库厂商自己把索引做成 Postgres 扩展，并把托管云作为升级路径，"Postgres 内向量检索"的竞争重心，正落在索引结构本身。^[14]

Bridgewater 内部知识库：在 4.5 亿向量上做权限感知检索 · vector ⚠️ 单方口径

对冲资本 Bridgewater 的产品工程负责人 Aaron Linsky 与 turbopuffer 的 CTO Nikhil Benesch 在播客中披露，Vault 中存有 1 亿份文档，每份文档都有各自的访问权限，首版检索在文档不断增加后很快失灵。Benesch 分析了两种常见做法各自的失败方式：后过滤先取出近邻，再剔除无权访问的文档，权限范围较窄的用户得到的结果会变少，甚至为空；前过滤只在用户可见的子集里比对，等于对大片语料做暴力扫描，向量索引形同虚设。turbopuffer 的解法是围绕访问控制重建索引结构，并称其生产系统在 4.5 亿向量上做到了 P90 120ms。这些数字出自播客口述，尚未见到公开基准。^[15]

AlloyDB AI：在库内完成嵌入模型的零停机升级 · vector ⚠️ 厂商口径

更换嵌入模型，通常要全量重新生成嵌入、重建索引并迁移 schema。Google Cloud 介绍了在 AlloyDB AI 内部完成整个流程的做法，示例是把 text-embedding-005（768 维）换成 gemini-embedding-001（3072 维）：模型端点管理负责在库内调用模型，auto embeddings 在后台生成新向量（宣称最高 3000 条/秒）；再配合并发建索引、集合返回函数和原子列重命名，就能以蓝绿或金丝雀的方式完成切换。官方还称，ScaNN 建索引比开源 HNSW 快 10 倍。^[16]

腾讯灯塔 AI 对外开放：以自然语言问数，直连 ClickHouse / StarRocks · ai-native ⚠️ 厂商口径

腾讯内部的 BI 平台"腾讯灯塔"已升级为 AI 数据分析套件并对外开放，功能包括用自然语言生成看板、归因分析、指标监控与推送。它支持的数据库和数仓有 MySQL、StarRocks、PostgreSQL、ClickHouse，也能通过 MCP 接入企业内部系统。隐私设计值得关注：大模型推理时只会接触字段名、类型等元数据，真实数值通过占位符回填，不交给模型读取。至于"运营看板从 4-6 个工作日缩到 2 小时内"这类效率数字，都是腾讯自述的案例。^[17]

MiniLake：在笔记本上模拟 Databricks API，由 DuckDB 执行 SQL · lakehouse

开源项目 MiniLake 能在本地模拟 Databricks REST API，databricks-sdk、CLI、Terraform 和 Asset Bundles 只要指向 localhost 就能使用，既不需要账号，也不会产生云账单。它并不是返回假数据的桩：SQL 在 DuckDB 上真实执行，每个 catalog 对应一个 DuckDB 库文件；外部表以真正的 Parquet 文件加 _delta_log 的形式写出，写操作通过真实的 Spark 作业完成，读取则走 DuckDB 的 delta_scan()；Spark 借助官方的 UCSingleCatalog 连接器解析表名。项目还内置 67 个 MCP 工具供 agent 调用，对超出支持范围的接口，会明确返回 501。它在 HN 上获得了 94 分。^[18]

TimescaleDB 自适应整数压缩 AIC：为读取路径重新设计整数编码 · olap ⚠️ 厂商口径

Tiger Data 介绍了即将取代 DeltaDelta 的 Adaptive Integer Compression（AIC）。DeltaDelta 保存相邻差值的差值，再用 Simple8bRLE 打包成 64 位块。它适合平稳递增的时序整数，但真实的表中还有状态码、外键、多来源交错写入的数据和小批次数据；而且 64 位块容纳的值太少，无法使用 SIMD，解压因此偏慢。AIC 针对每块最多 256 个值，从 6 种编码中选择其一，候选范围只限于解压快的编码。官方测试测得，数据库整体小约 10%，典型查询快约 50%。AIC 在 2.31.0 中以预览形式提供并默认关闭，计划在 2.32.0 改为默认开启。^[19]

Brotli 解码器漏洞波及面扩大：DuckDB、Apache Arrow 也在其中

针对 CVE-2026-111497 的后续排查发现，捆绑有漏洞 Brotli 代码的项目，除 ClickHouse 外，还有 DuckDB、Apache Arrow、MuPDF、libjxl 等。研究演示了只需一个恶意请求，就能远程打崩 ClickHouse；Arrow 则会陷入死循环，造成拒绝服务。此外，攻击者经由 JPEG XL 元数据也能触及该漏洞，攻击面从 Web 流量延伸到了文件处理流程。凡是会自动解压外部内容的数据管道，都应核对所用依赖的版本。^[20]

LIGHT：以动态图注意力实现 learned join order 选择

期刊 Data Science and Engineering 上的一篇论文提出了 LIGHT。它把查询建模成图，以表为节点、以连接谓词为边，再用动态图注意力来捕捉表与表之间的依赖。Balsa、RTOS 等强化学习优化器存在奖励波动大、容易陷入局部最优的问题，LIGHT 正是针对这一点做的改进。作者称，它在 JOB 和 TPC-DS 上的执行性能优于 PostgreSQL 原生优化器及多种 learned optimizer，但报道没有给出具体的加速倍数。^[21]

KineDB 获 85 万欧元 Pre-seed 融资 · oltp

芬兰数据库初创公司 KineDB 完成了 85 万欧元的 pre-seed 融资，由 Superhero Capital 领投，NGL Ventures 和多位天使投资人跟投。该公司正在开发一款通用数据库，同一个引擎既可以嵌入应用、在本地离线运行，也可以部署在后端云端，因此不必再把系统拆成离线库和云端库两套。首批目标是网络不稳定的行业，例如井下采矿作业：离线时在本地记录，联网后再同步。这笔资金将主要用于招聘数据库、存储与查询引擎方向的工程师。^[22]

Databricks 为 serverless 补上成本管控功能 · cloud

Databricks 表示，其 serverless 计算的用量在过去一年增长超过 3 倍。公司现在把 SQL 和 Model Serving 已有的成本管控，扩展到了 notebook、作业与管道。classic 计算通过节点数和集群策略来控制费用，serverless 则改为按人员和工作负载来控制。在三件工具中，用于成本归属的计算标签处于 Beta 阶段，基于系统表的预算告警和成本看板已经可用，第三项尚未上线。随着 serverless 的渗透率提高，平台团队对账单可预测性的要求也在提高。^[23]

FutureX · 记录未来如何发生

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