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

FutureX · Database

本期要点

· PostgreSQL 19 推迟到约 11 月 19 日 GA，撤回 8-10 项重要功能，SQL/PGQ 也在其中

· 撤回的直接原因是 LLM 辅助代码审查：一次查出约 40 个缺陷，核心开发者来不及在发布前修完

· DuckDB v2.0-dev 在 NVIDIA Vera 上跑 TPC-H SF1,000，比 Intel Xeon 6 基线高 46%（官方自测）

· Snowflake 新一代复制引擎 GA，RPO Assurance 把恢复点目标写进 SLA

· Apache Pinot 1.6.0 RC0 进入投票，可以直接用 SQL DDL 建表、删表

▎ 版本与产品发布

PostgreSQL 19 的发布推迟到 11 月，有 8-10 项功能被撤回 · oltp

此前 PostgreSQL 19 计划在 9 月底至 10 月初发布，眼下预计推迟到约 11 月 19 日 GA。全球开发组决定撤回 8 到 10 项重要功能，并把它们顺延到明年的 PostgreSQL 20。被撤回的功能里有 SQL/PGQ，这是 2023 年写入 SQL 标准的属性图查询，用户可以在关系表上直接使用图语法，查询节点与边之间的关系。

核心 committer Peter Eisentraut 任职于 EDB，担任副总裁。他在博客中说明了两层原因。第一，部分功能的架构存在较大缺陷，beta 期间很难迅速修复。第二，LLM 辅助代码审查一下子查出许多边界情况问题，这些问题单看都不严重，换作过去，往往要在发布后的五年内才被陆续补上。他的原话是：“你会盯着一份 40 个缺陷的清单，哪怕平均每个只需改三行，处理每一个都有固定开销，然后时间就用完了。”

他特别指出，这次撤回与 “vibe coding” 没有关系。这些功能大多写成于 LLM 审查成熟之前，问题在于功能提交之后，质量门槛被提高了。他预计，只要 LLM 审查能力继续以目前的速度提升，后续的开发周期就会逐步恢复正常。对下游而言，Aurora、AlloyDB 等托管 Postgres，以及各类 wire 兼容的分布式系统，跟进 19 的时间表也会随之后移。[1]

Apache Pinot 1.6.0 RC0 进入社区投票，可用 SQL DDL 管理表 · olap

Apache Pinot 推出了 1.6.0 的第一个候选版本 RC0，目前已进入社区审查和投票阶段，离正式版只差一步。最突出的变化是 SQL DDL：用户可以直接通过 CREATE TABLE / DROP TABLE / SHOW TABLES / SHOW CREATE TABLE 来管理表的元数据。官方文档说明，这些语句由 controller 上独立的 DDL 端点处理，不走 broker 的查询接口，还支持只做编译校验、不写入数据的 dry-run。在此之前，Pinot 建表主要靠提交 JSON 格式的表配置和 schema。

发布说明还附有一份相当完整的验证清单：30,211 个单元测试和 1,772 个集成测试全部通过、没有失败，滚动升级与降级检查也已通过，最终二进制包则在两套查询引擎上都运行成功。Pinot 与 ClickHouse、Druid 同在实时 OLAP 赛道。DDL 补齐之后，Pinot 的上手门槛和 SQL 原生体验又向 ClickHouse 靠近了一步。[2]

其他版本动态：
· ClickHouse 在同一天推送了四个维护版本（v26.9.20.23-stable、v26.8.29.10-lts、v26.7.32.7-stable、v26.3.53.4-lts）
· YugabyteDB 的多个分支集中回补修复，内容主要围绕向量索引，包括修复 ybhnsw 索引上 CREATE INDEX 会挂起的问题、让 xCluster 跳过向量索引的 schema 变更，以及新增 verify_vector_index 校验工具
· TiDB v8.5.8 的每日构建修复了 JSON 格式化问题和语句清理中断问题
· Materialize 则发布了 v26.47.0-rc.1。[3]

▎ 湖仓 · 开放表格式 · HTAP

Atlassian 在 Databricks 上以 OCSF 统一安全日志，每天处理 440 亿条事件 · lakehouse

Atlassian 的安全日志管道每天要接收 440 亿条事件。公司多年来经历多次收购，各系统留下的日志格式互不相同，时间戳和 schema 也不一致。团队把全部日志统一到开放的 OCSF 框架（Open Cybersecurity Schema Framework）之下，并在 Databricks 上搭建了自助式的安全湖仓，目前这套湖仓已支撑 500 多个威胁检测信号。

团队之所以在 OCSF 与 ECS、UDM 之间选了 OCSF，是因为它有强类型校验，而且完全开放。OCSF 的定义多达约 4 万个字段，看上去冗长，语义却因此保留在了数据里：五个漏洞扫描器的结果可以合并成一个数据集，一条查询就能跨越多个数据源。工程上，团队有意采用在传输途中完成转换的 ETL，而不是 ELT，目的是支持实时检测。分区再加上 Z-ORDER，使代表性查询的耗时从约 45 秒降到 2-3 秒；改用 Graviton + Photon 之后，查询成本和耗时都下降了约三分之二。可观测与安全日志场景从 SIEM 迁往湖仓，Atlassian 是又一个大规模样本，而这个场景同样是 ClickHouse 系的主战场之一。[4]

Databricks 的 Lakehouse//RT 开始支持空间 SQL（Beta） · olap ⚠️ 厂商口径

Databricks 的实时数仓 Lakehouse//RT 现已支持空间 SQL 和空间 join，目前处于 Beta 阶段。官方以 SpatialBench 为基准，与一款未点名的“传统云数仓”作比较，称平均快 3 倍，单个查询最多快 20 倍，在 50 并发下最多快 38 倍；不过这一比较只统计了对手能够跑完的查询。官方的说法是，有低延迟需求的空间应用从此不必再单独维护一套 PostGIS。[5]

▎ 技术 · 架构 · 性能基准

DuckDB 介绍如何把表中的 JSON 文本列直接转为类型化列 · olap

现实中不少 JSON 并不是以文件形式存在，而是作为文本列放在表里，比如 Postgres 中保存的事件 payload。以往常见的做法是先用 COPY 导出成文件，再通过 read_json 读回来。DuckDB 官方博客介绍了一种纯 SQL 的做法，一共三步。第一步，用聚合函数 json_group_structure 合并出整列的结构；表很大时可以只抽样 1 万行，代价是有可能漏掉极少出现的键。第二步，用 json_merge_patch 只修改需要调整的字段类型，例如把时间戳从 VARCHAR 改为 TIMESTAMP。第三步，用 json_transform 配合 unnest，把数据展开成普通列。这样一来，JSON 只在导入时解析一次，后续查询面对的是按列存储并压缩的数据，不必再接触 JSON。相比之下，若逐个字段用 ->> 提取，每取一个字段都要把 JSON 重新解析一遍。[6]

性能 · 基准

· DuckDB v2.0-dev × NVIDIA Vera：DuckDB 团队与 NVIDIA 合作，使用预览版 1.6.0.dev379 运行了完整的 TPC-H SF1,000。测试不限于只读查询，还包含更新流和并发吞吐测试，结果取三次运行 QphH 的中位数。Vera 平台配备 88 核 Olympus，内存带宽最高 1.2 TB/s，并限定单路运行，成绩比 96 核的 Intel Xeon 6 基线高出 46%。团队认为，高内存带宽、低延迟和大缓存对 join 与聚合哈希表有帮助，这是优势的来源；他们还表示，两套平台如果送交官方审计，都有望进入 SF1,000 性能榜的前三名。这次测试由 DuckDB 自行完成，没有经过 TPC 审计。⚠️ 基准口径 [7]

学界 · 研究前沿

· ConStore（arXiv 2610.21676）：研究者在百万到十亿级的向量语料上做了实测，发现 top-K 取值较大时，从 SSD 取回内容所需的延迟可能与向量检索本身相当，甚至更高。论文据此提出一种“边检索边预取”的内容存储引擎，所针对的是 RAG 端到端延迟中经常被忽视的一环。[8]

· Amora（arXiv 2610.21174）：这项研究在云端向量库上实现隐私 ANN 检索，查询向量不会暴露给服务器。论文把 SimplePIR 应用到分区图索引上，让一次 PIR 查询可以分摊到多个顶点，从而降低现有 SOTA 方案 Pacmann 的通信开销。[9]

· DataKernelBench（arXiv 2608.25061）：这个基准考察 LLM 能否为 GPU 数据库手写查询 kernel。在 H100、TPC-H SF10 的条件下，最强的整查询 CUDA 配置在全部通过正确性校验的前提下，比 PyTorch 基线快 2.11 倍。提速主要来自 kernel 融合和执行策略的调整；此外，向模型提供负载上下文比提供硬件上下文更有帮助。[10]

· TraHist（arXiv 2610.22310）：这项工作为轨迹数据设计了直方图基数估计方法，弥补查询优化器处理时空数据时的不足。[11]

▎ 融资 · 并购 · 商业化

RapidCanvas 完成 B 轮融资，金额约 2900 万美元 · ai-native

总部设在奥斯汀的 RapidCanvas 完成了近 2900 万美元的 B 轮融资，由 Vertex Ventures 与 Hitachi Ventures 联合领投，估值没有披露。公司借助 agent 和无代码界面，自动完成从数据准备、特征工程、模型选择到部署的机器学习中间环节，服务对象是企业的数据科学团队，而不是编写代码的开发者。外界流传“可自动化 75% 数据科学工作”的说法，一手报道中并未出现，不宜采信。[12]

▎ 云厂商 · 生态 · 监管

Snowflake 新一代账户复制进入 GA，RPO Assurance 被写入 SLA · cloud

Snowflake 的 Optimized Refresh 与 RPO Assurance 已转为 GA，二者共用一套全新的复制引擎。官方表示，预览阶段的客户感受到的复制速度比上一代快 1.6 倍到 20 倍以上，具体幅度取决于负载，这属于厂商口径。Optimized Refresh 提供“尽力而为”的低 RPO，适用于大多数负载。RPO Assurance 的分量更重：官方文档称，Snowflake 对符合条件的复制对按 SLA 承诺 RPO 目标，若未能达标，客户可以申请服务抵扣。这等于把灾备 RPO 从运维目标变成了合同条款。复制的范围除数据库外，还包括用户、角色、授权与网络策略，因此故障切换之后不必重建权限。现有的故障转移组默认仍留在旧引擎上，官方建议迁移。[13]

Stripe 数据管道可实时同步到 Postgres，Neon 成为直连目标 · oltp

Stripe Data Pipeline 新增了实时同步到 Postgres 的能力，整个过程由 Stripe 端到端托管，用户无须再自建 API 轮询或 webhook 管道。Neon 用户可以在 Stripe 控制台中一键直连，支付、订阅和客户数据会直接写入应用所在的同一个 Lakebase Postgres 库，因此判断“是否付费用户”只需做一次 join。表结构与 Stripe API 的对象一一对应，每张表另外带有一个 _raw_data 列，用来保存完整的 JSON。[14]

达梦数据支撑期货行业首个 CTP 核心系统完成数据库切换 · oltp ⚠️ 厂商口径

前海期货 CTP 综合交易平台的核心系统已完成数据库切换并上线，使用的是达梦数据守护集群 DMDW，对外称这是期货行业的首例。CTP 连接国内六大期货交易所，涵盖交易、风控和结算。系统上线之前，累计进行了 2900 万笔报单测试，业务侧无需改动代码。达梦援引 IDC 报告称，公司以 14.6% 的份额在中国本地部署事务型数据库市场排名第一，这属于厂商援引的口径。[15]

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

FutureX · 记录未来如何发生

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