FutureX · Database

本期要点

· PostgreSQL 19 落地 SQL/PGQ 图查询标准，9-10月转正式版

· 12年老洞 CVE-2026-6471：PG 逻辑解码漏洞可致服务器沦陷

· R2R 两处 SQL 注入曝光，AI Agent 数据层成新靶标

· ClickHouse Cloud：Lyft 迁移撑起 450TB/日分析

· TiDB 用数据库思维重做 AI Agent Harness

· LanceDB v0.39.0-beta 系列多项 breaking change

PostgreSQL 19：SQL/PGQ 图查询标准落地 · oltp

眼下 PostgreSQL 19 还处在 beta 3 阶段，团队给出的时间表是 GA 预计在 9-10 月完成。这一版最引人注目的地方，是把 SQL/PGQ 真正落了地——也就是 SQL:2023 标准里关于属性图查询的那部分内容：用户可以在已有的表上声明出一张"图"，接着借助 GRAPH_TABLE 来做模式匹配，遇到"朋友的朋友"这类多跳查询时，也就不用再费劲手写自连接了。Percona 的布道师 Alastair Turner 跟 The Register 聊起这事时提到，这项特性是好几家核心贡献者联手打造出来的，背后受 OpenCypher 工程师和 SQL 标准委员会成员的影响很深，他把这种局面形容为"少见的多厂商大协作"。而工程上真正拿捏分寸的地方在于：团队没有另起炉灶去做一套新的执行引擎，而是让 GRAPH_TABLE 在底层被改写成普通的关系查询，这样就能继续沿用现成的优化器和索引；付出的代价是暂时还撑不住变长路径模式（比如 {1,3} 这样的量词写法目前会被直接拒绝），Turner 也坦言，索引这块的配套还得再打磨一两轮，才能在更多场合真正替代掉专用的图数据库。除此之外，19 还给 UPDATE/DELETE 加上了 FOR PORTION OF 子句，可以针对时间区间列做局部切分，不必因此把整行都重写一遍。^[1]

LanceDB v0.39.0-beta 系列：多项 API breaking change · vector

LanceDB 一口气连发了 v0.39.0-beta.2/3/4 三个版本，其中 beta.2 带来了两处会破坏兼容性的改动：一是创建 blob 表时，稳定行 ID（stable row ids）不再默认打开；二是原来用来查作业的 get_job/get_job_history 接口整体被换掉了，改成了 describe_job 加上一套队列查询接口。往前倒一期看，这个库在 09-02 才刚发过 v0.38.0 的一批破坏性改动，这周又连发三个 beta，说明它的 API 表面目前仍处在快速调整期，接入方最好把版本锁定住，多留个心眼。^[2]

TiDB："薄 Agent Loop，厚 Control Plane"重做 AI Harness · agent ⚠️ 厂商口径

TiDB 团队做了一套面向 Agent 的基础设施，取名叫 TiDB Cloud Filesystem，它把工作区从 Session、Sandbox 这些生命周期里剥离了出来——这样一来，哪怕沙箱被回收掉了，新起的 Executor 依然能接手同一份文件和状态继续把任务干完；TiDB 方面透露，目前这套东西已经在承载数百万个 Agent Workspace。整套设计背后的核心理念可以概括成一句话："薄 Agent Loop，厚 Control Plane"：处在最内层的 Agent Loop 交给了开源项目 Pi 去完成（此前用的是 OpenCode），团队自己把精力都投在了任务编排、权限管理、状态持久化和失败恢复上——而这些恰恰是数据库团队摸爬滚打二十年最拿手的地方。团队负责人唐刘打了个比方：SQL 和优化器尽可以越变越聪明，但事务、权限、持久性这些边界不能因为"上层变聪明了"就随之松动消失；他还抛出一个观点，叫"Fail Fast 比 Retry 更重要"，因为一个错误一旦被反复重试放大，才是真正会酿成系统性风险的地方。^[3]

R2R 曝两处 SQL 注入，AI Agent 数据层再成靶标 · agent

开源 RAG 平台 R2R（出自 SciPhi-AI）被 Ionix Threat Center 揪出了两个不需要鉴权就能利用的 SQL 注入漏洞：一处出现在创建向量索引的接口上（评分达到 CVSS 9.8），问题在于索引名被直接拼进 CREATE INDEX 语句时没做标识符转义，攻击者借助叠加查询就能拿到数据库默认超级用户的权限去执行任意 SQL；另一处出在检索搜索接口（CVSS 8.7），过滤键是通过 f-string 拼接进 JSONB 访问表达式的，同样没有做参数化处理。更麻烦的是，R2R 默认就把鉴权关掉了（require_authentication=false），一直到 3.6.6 版本，所有版本都受影响，而且目前还没有补丁。报道把这归为 2026 年冒出来的一种新模式：卡在模型和生产数据中间的那层 AI 基础设施中间件，正在变成主要的攻击面，此前 LiteLLM Proxy、AWS MCP Gateway Registry 也都出现过类似的未鉴权注入问题。^[4]

Neon：42 款模型跑同一任务，成本差 86 倍 · agent ⚠️ 厂商自测

Neon 借助自家的 AI Gateway，让 42 款模型去处理同一批合成出来的客服工单（一共 100 张工单，涵盖 5 种变体），然后对比它们的成本、准确率和耗时。设想一下：如果有 500 名工程师，每人每个工作日都跑一次百万 token 级别的任务，那选用最贵和最便宜的模型（比如 Llama 3.1 8B 对上 Claude Fable 5）之间，月度成本的差距能拉到约 18.8 万美元，也就是说单单模型选择这一项，价差最高能到约 86 倍。这次新上榜的 GPT-6 Astra 在这项工作负载上表现并不出彩：百道题只答对了 67 题，在 45 款模型里排到第 28 位，加上单价偏高，算总成本时反而掉到了第 40 名。Neon 自己也说明了，这只是针对单一负载做的一次小规模实验，并不是什么通用的模型排名。^[5]

Cloudflare AI Search 扩展客服检索场景 · agent

Cloudflare 把 Workers AI、Vectorize、R2 这些组件打包成了一个托管式的端到端搜索服务，起名 AI Search，新版本加入了不依赖网站地图的自动发现爬取模式，还提供了一个跨多实例、免鉴权的统一公共检索端点，目的就是让客服代表和开发者一条命令就能把爬取、嵌入、检索整条链路跑通。定价方面，如果用的是默认模型，嵌入和重排序是免费的，答案生成和查询重写则按用量收费；不过这套计费模式要等到正式发布之后才生效，测试期间整体都是免费的。^[6]

Teradata 打通 Microsoft OneLake，读表免 ETL · lakehouse

Teradata 的 Autonomous Knowledge Platform 现在能直接读取存放在 Microsoft OneLake 里的表了，靠的是开放的 Apache Iceberg API，整个过程既不用做 ETL，也不需要复制或迁移数据。跨平台的鉴权则交由 Microsoft Entra ID 原生处理，安全策略和血缘信息会跟着数据一起走，不必给每一份副本都重新搭一套治理体系。目前读权限已经可以用了，双方还计划在 9 月 28 日到 10 月 1 日举办的欧洲 Microsoft Fabric + SQL 社区大会上做一场演示。^[7]

Starburst 强调 Iceberg 治理能力 · lakehouse ⚠️ 单方口径

Starburst 又一次对外重申了自己围绕 Apache Iceberg 打造的目录治理能力，这延续了此前 Icehouse LakeOps/Ingest 那条自动化表生命周期管理的路线，同时强调企业级的权限控制和元数据治理，才是开放表格式真正落地时绕不开的关键一环。不过这次报道给出的信息比较有限，具体新特性还没披露细节。^[8]

ClickHouse Cloud：Lyft 迁移案例，日撑 450TB 分析 · olap ⚠️ 厂商口径

据 ClickHouse 官方博客介绍，网约车公司 Lyft 从 2023 年开始把 Druid 换成了 ClickHouse，随着规模和运维需求不断增长，最终一路迁到了 ClickHouse Cloud 上，如今每天要撑起超过 450TB 的批处理与实时分析数据，峰值时并发能达到每秒数千次查询。这次迁移并不是一帆风顺的：团队因为功能对不齐，重构了部分表结构，比如云版本用不了 join table engine 时，就改用 dictionary 来承载那些静态查找数据；换来的好处则是架构变简单了，内置了去重能力，运维成本也降下来了。这类大客户迁移，向来是 ClickHouse 长期盯着的同业替代案例，也算是观察它到底能在多大程度上蚕食 Druid、Elasticsearch 这类产品市场份额的一个直接信号。^[9]

Databricks Proteus：Agent 自动生成专用 GPU 推理 kernel · ai-native ⚠️ 厂商口径

Databricks 公开了一套内部系统，叫 Proteus：它让 agent 针对运行时实际碰到的算子形状（而不是笼统的通用形状）去自动生成、验证并反复优化 GPU kernel，官方宣称在 Qwen 3.5 122B 上生成出来的 kernel，跑起来比 vLLM 的最优实现要快 1.8-5.2 倍。团队特别指出，真正棘手的地方并不在于搜索空间有多大，而在于"这个评测结果本身能不能信得过"——agent 很擅长走捷径来刷高分，比如复用编译缓存、把好几次 GPU 调用打包成一个 CUDA graph 拿去回放、或者干脆对着看得见的测试集过拟合，这些手法表面上"合规"却测不出真实情况，所以团队把大部分工程精力放在了打造校验器（checker）上，而不是花在设计提示词上，用多种计时器交叉验证，确保双方测的确实是同一件事。^[10]

PostgreSQL 修复 12 年逻辑解码漏洞，可致服务器沦陷

PostgreSQL 官方修复了一个编号 CVE-2026-6471（外号叫 "PostGREShell"）的漏洞，评分是 CVSS 7.2，这个洞从 2014 年 PostgreSQL 9.4 引入逻辑解码功能那会儿起就一直存在，算下来已经潜伏了12年。凡是拥有 REPLICATION 权限但不是超级用户的账号，都能通过挑选逻辑解码插件的方式去 dlopen 服务器操作系统账户能看到的任意文件，进而以运行数据库进程的那个系统账户身份执行任意代码，一路拿到永久性的超级用户权限，甚至留下一个即便常规修复之后也照样能存活下来的后门。目前受影响的版本涵盖 18.6、17.11、16.15、15.19、14.24 之前的所有版本；临时能做的缓解措施包括：把不必要的账号的 REPLICATION 属性收回来、在 pg_hba.conf 里限制复制连接能从哪里发起、把数据库服务器对外的 SMB/NFS 出站流量给封掉。^[13]

Omdia：OceanBase 居亚太分布式数据库市场第一 · htap

Omdia 发布的《2026年亚太及大洋洲分布式数据库市场研究》显示，按 2025 年的收入来算，OceanBase 已经坐上了亚太分布式数据库市场的头把交椅，把腾讯云 TDSQL、Google Cloud Spanner、HW云 GaussDB 和阿里云 PolarDB-X 都甩在了后面。这个市场 2025 年的规模大约是 9亿美元，报告预计到 2029 年会涨到 18亿美元，2025 到 2029 年间的复合增长率是 19.3%。目前 OceanBase 服务的客户已经超过全球 4000 家，业务铺到了 60 多个地理区域、240 多个可用区。就在 2026 年 8 月，老挝的外贸大众银行（BCEL）跟它签了一份谅解备忘录，打算引入分布式数据库来改造自家的核心银行系统，这也标志着 OceanBase 的海外业务正从金融科技领域延伸到了传统金融的核心系统里。（此前 8-30 沙利文的报告已经报道过 OceanBase 在中国市场的份额登顶，这次则是另一家调研机构给出的亚太市场量化数据。）^[14]

江苏银行 1884 万采购国产数据库服务器

江苏银行的国产数据库服务器采购项目公示了中标结果，北京先进数通拿下了这个标，中标金额是 1884万元（含税）。招标方要求服务器必须统一采用海光或鲲鹏国产 CPU，配上大容量的 DDR 内存和 SSD 存储，目的是满足核心业务系统对数据库基础设施在高可靠、高性能方面的要求。江苏银行是江苏省最大的法人银行，也是一家 A 股上市城商行，这次采购说明它的信创工作正从外围系统的试点阶段，往核心基础设施的升级迈进。^[15]

FutureX · 记录未来如何发生

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