FutureX · Database

本期要点

· Elastic 发布 Serverless 向量数据库，宣称可扩至数千亿向量

· PlanetScale 推出 Neki：分片 Postgres 平台预览版上线

· Apache Paimon 迎来 2.1.0 RC，湖仓表格式迭代收尾

· Tinybird 复盘运维 ClickHouse 近6年踩坑记，HN 172赞

· Neon 上线 Claimable Neon，AI agent 可匿名自助建库

· Google、OpenAI 同期上线数据 Agent，抢自然语言查数据入口

PlanetScale 发布 Neki，分片 Postgres 进入平台预览 · oltp

PlanetScale 花了八年时间运维超大规模的分片 MySQL 集群，如今把这些经验用到了新产品上——他们做出了一款分片 Postgres，取名叫Neki，目前已经进入平台预览阶段。这套系统里每个分片其实都是一个货真价实的 Postgres 实例，采用一主两从的结构，而且分布在三个可用区，不会因为某个区出问题就整体瘫掉。应用这边不需要做任何改动：只要通过标准 Postgres 协议连上 Neki 的路由层就行，原来用的驱动、ORM、连接字符串统统照旧能用。功能上也照顾到了实际运维的痛点，比如可以在线扩缩分片、跨分片做原子事务、还能按 JSON 定义的拓扑来指定分片键；就连 schema 变更、版本升级、故障切换这些操作，也都被设计成在线工作流去完成，不用停机维护窗口。官方透露，在一次压测里，单个集群跑出了118.5M QPS的成绩（用了512个分片，每个分片跑到20万 QPS）——不过这只是厂商自己给出的说法，目前还没看到第三方复现验证过。要说 Neki 跟 CockroachDB、YugabyteDB 这些标榜"Postgres 兼容"的分布式数据库有什么不一样，关键就在于它坚持用真正的 Postgres 内核，而不是自己重新造一套存储引擎，主打的卖点是既要扩展性又不想牺牲原生生态的兼容性。^[1]

Elastic 发布 Serverless 向量数据库 · vector ⚠️ 厂商口径

9月11日，Elastic 推出了Elasticsearch Vector Database，这是建立在 Elastic Cloud Serverless 之上的一款产品，定位是让用户能在几分钟内就用起来、而且可以一路扩展到数千亿级别的向量。这款产品最大的卖点是官方自研的 Better Binary Quantization 量化技术，据称能把向量占用的内存压缩到原来的最多1/32，同时还能保住召回率不掉。除此之外，产品还支持在同一个索引里把文本、图像等多模态向量检索和关键词检索混合起来用；计费方式也比较直白，按数据量和检索容量算钱，不搞什么让人看不懂的"计算单元"黑盒定价。Elastic 本来是做通用检索引擎起家的，这次算是正式杀入了向量数据库这个赛道，直接跟 Pinecone、Weaviate、Qdrant、Milvus 这些专门做向量库的厂商摆开了阵势，它的底气在于能沿用自己原有的 Elasticsearch 生态和大家已经熟悉的运维方式。不过需要提醒一句，压缩倍数和召回率保持这些数字都是官方自己报的，还没有第三方去复测验证过。^[2]

Neon 推出 Claimable Neon，AI agent 可匿名自助建库 · agent

Neon（现在是 Databricks 旗下 Lakebase Postgres 的一部分）推出了新功能Claimable Neon，把 WorkOS 发起的开放协议 auth.md 里提到的匿名注册方式给落地了：像 Replit、v0 这类靠 AI agent 生成应用的场景，现在 agent 不用先注册账号、也不用提供支付信息，就能临时开出一个 Neon 项目，拿到一套权限受限的凭证继续往下搭建。这类没人认领的项目会在72小时后自动过期，容量方面也设了上限，存储 100MB、流量 1GB。等到真的有人登录并认领了这个项目，之前那个预认领用的令牌就会立刻失效，凭证也会同步换一批新的。目前开放出来的能力有三项：Postgres 数据库本身、Data API，以及 Managed Better Auth；至于对象存储、Functions、AI Gateway 这些，还得再等等看后续会不会跟进。这次更新其实是"面向 agent 的数据库"这个方向上一个很具体的落地案例——它把"由谁来创建数据库"这一步也交给了 agent 去做，而不是像以前那样只顾着优化 agent 建好库之后怎么去查询。^[3]

Google、OpenAI 同期上线数据 Agent，抢自然语言查数据入口 · ai-native

Google Cloud 这边推出了Data Agent Kit，把跨系统的数据工作流直接接进了开发者的工具链里；差不多同一时间，OpenAI 也在 ChatGPT Work 里上线了一个叫"Data agent"的功能，它能读取企业内部数据、回答相关问题，还能自动生成看板。有意思的是，这两家公司几乎在同一时间点，都选择把"用自然语言查数据"这件事做成了一个独立的 agent 产品，而不再满足于只做一个 Text-to-SQL 的小功能。这个动向其实和 Databricks、Snowflake 最近力推的"自治数据工程师"路线是一致的（比如之前报道过的 Zeit AI 融资）：可以看出，数据平台厂商正在把"查数据、搭建管道、给出结论"这一整套流程打包交给 agent 去做，不再像以前那样把 BI 工具和数据库连接器分开卖。^[4]

Apache Paimon 2.1.0 迎来 RC1/RC2 · lakehouse

Apache Paimon（前身是 Flink Table Store，主打流批一体的湖仓表格式）这次连续放出了 2.1.0 版本的两个候选版本 RC1 和 RC2，同时 PyPaimon 也跟着同步更新，看样子马上就要定型了。Paimon 的定位比较特别：相比 Iceberg、Delta、Hudi 这些表格式，它是专门针对流式写入和近实时查询做优化设计的，跟 Flink、StarRocks、Doris 这些引擎的生态结合得也比较紧密。眼下这几个候选版本算是正式发布前最后的收尾迭代，具体新增了哪些特性，还得等最终的 GA 说明出来才知道。^[5]

RisingWave 发布 v3.1.0-rc.1 · streaming

流式数据库 RisingWave 放出了 3.1.0 版本的第一个候选版，标志着进入了下一个大版本的迭代周期，具体有哪些变更，还是要等正式版发布说明出来再看。^[6]

Tinybird 复盘运维 ClickHouse 近6年的踩坑记 · olap

Tinybird 一位工程师写了篇文章，回顾了从 ClickHouse 18.4 版本算起近6年的运维经历，期间管理过好几个 PB 级别的集群，这篇文章在 HN 上收获了 172个赞和64条评论，讨论热度不小。文章里直接点出了传统"分片+副本"架构的痛点：团队早期是用本地 SSD 搭的无分片、纯副本集群，靠垂直扩容和多加副本来撑住不断增长的规模；可随着数据量越滚越大，"存算分离、把存储放到云上"这条路慢慢就变成了管理大规模 ClickHouse 集群更现实的选择——作者也坦白说自己其实并不完全认同这个趋势，但他也承认，这么做确实能实实在在降低运维的复杂度和成本。文章里还提到，团队曾经给 ClickHouse 上游贡献过新引擎、分布式 join 之类的性能改进代码。对那些正在纠结要自建还是用托管 ClickHouse（或者考虑 ClickHouse Cloud、StarRocks 这类替代方案）的团队来说，这篇文章提供了一个比较少见的、来自一线的长期运维视角。^[7]

TimescaleDB：一次 Postgres 写入的真实成本 · oltp

Tiger Data（也就是 TimescaleDB 的母公司）发文用实测数据拆解了 Postgres 里"写放大"这个问题：他们在一张带了三个索引的表上做实验，发现哪怕只写入一行仅40字节大小的传感器数据，也会触发四条各自独立的 WAL 记录，提交前日志体积会膨胀约345字节。追根溯源，问题出在每条堆元组都自带一个 24 字节的 MVCC 可见性头（也就是 t_xmin、t_xmax 这些字段），再加上 4 字节的行指针，而且每多加一个索引，写放大的比例就会跟着往上涨——这其实正是很多人遇到过的那种"为了修复慢查询加了个索引，结果两周后 p95 写入延迟反而反弹"的根本原因。文章还给出了在 PostgreSQL 16 默认配置下实测的探测方法，以及四种能降低写放大的具体手段，对想弄清楚高频时序写入场景下 WAL 膨胀和副本延迟之间连锁反应的人来说，是个挺实用的参考材料。^[8]

开源版 Postgres "Durable Objects" · oltp

有个开源项目把 Cloudflare Durable Objects 那套编程模型搬到了 Postgres 上面，让每一个"对象"都能拥有自己独立、可寻址的持久化状态和执行单元。这个项目在 HN 上拿到了 41个赞，还引发了23条讨论，说明社区对"有状态 serverless"这种抽象层的兴趣一直都还挺高的。^[9]

PostgreSQL 核心开发者 Tom Lane 谈30年架构决策 · oltp

Snowflake 官方博客采访了 Postgres 长期以来的核心贡献者 Tom Lane，请他回顾了过去30年里 Postgres 在若干关键架构问题上是怎么做取舍的，这段历史脉络也为理解今天像 AlloyDB、Aurora、Neon、CockroachDB 这些打着"Postgres 兼容"旗号的产品，提供了一个技术起点上的背景参照。^[10]

Google 发布 AlloyDB Omni RPM 编排器 · cloud

Google 宣布，AlloyDB Omni（这是一款兼容 PostgreSQL 的数据库）面向 Red Hat 的 RPM 编排器已经正式可用了，版本号是 18.3.0。在这之前，AlloyDB Omni 已经能支持独立容器和 K8s Operator 这两种高可用部署方式，这次算是把独立 RPM 包和 RPM 高可用编排这两种模式也补上了，主要是面向那些没有容器化的基础设施，适用于数据合规、边缘/本地部署以及 AI 应用等场景。这套编排器内置了一套参考架构，包括负载均衡、Keepalived 做故障切换、PgBouncer 做连接池、HAProxy 负责流量路由；同时还提供了一个独立的控制面（由冗余的集群管理器加上三节点 etcd 配置存储组成），用来实现低停机的版本升级和资源调整，而且支持自动回滚。^[14]

Yugabyte 加码渠道合作伙伴计划 · cloud

做分布式 SQL 的厂商 Yugabyte 宣布要扩大自己的渠道合作伙伴计划，打算通过分销商和系统集成商来触达更多企业客户。这在跟 CockroachDB、TiDB 这些同类分布式数据库厂商的竞争中，算是一个比较常规的动作，目的是扩大商业化的覆盖面。^[15]

IDC 与 WD 报告：AI 推动数据存储需求结构性扩张 · cloud ⚠️ 厂商口径

IDC 和存储厂商 Western Digital 联合发布了一份报告，说过去12个月里有 94.7% 的受访机构因为 AI 的缘故存储了更多数据，存储的经济性正在变成基础设施领域的新焦点。不过要注意，这份报告是有存储硬件厂商参与出品的，样本情况和方法论都没有公开披露，所以这个数字大方向上可以参考，但不太适合直接拿来当作独立的行业定量结论去引用。^[16]

OceanBase AI 数据平台落地医疗行业 · cloud

OceanBase 公布了他们的 AI 数据平台在医疗健康行业的一个落地案例，这延续了此前"在 Omdia 亚太分布式库份额榜单上排名第一"那条报道里的商业化叙事，本次没有新增什么增量数字。^[17]

FutureX · 记录未来如何发生

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