FutureX · Database

本期要点

· AWS收购DuckLabs核心团队，MotherDuck同步收购Tower.dev

· ClickHouse发布WalShadow，物理WAL复制延迟约200ms

· Neon后端全线GA：Postgres+存储+Auth面向agent开放

· 4B模型经RL训练，查询计划比Postgres快81%

· Turbopuffer对象存储架构，法律AI检索成本降一个数量级

StarRocks 4.1.3 发布 olap

这个小版本主要在调整行为逻辑：用户执行CTAS（CREATE TABLE AS SELECT）时，如果已经明确声明了VARCHAR(N)列的宽度，系统不会再像以前那样自动把它放宽到默认上限，而是老老实实保留用户写下的长度——下游那些建表脚本的兼容性预期因此会受到影响。这次没有塞进什么大功能。^[1]

LanceDB v0.39.0 转正式版，v0.40.0 连发四个 beta vector

v0.39.0 这次从 beta 状态转成了 GA，但带来了两处不兼容的改动：物化视图的定义里现在会记录来源所属的 namespace，同时 blob 表不再支持 stable row id。与此同时 v0.40.0 也没闲着，从 beta.0 一路迭代到 beta.3，密集加入了 zonemap 索引的构建工具、可命名的 Secrets 与绑定、可按命名空间寻址、把 MetadataEraserExec 公开出来，还有 OAuth2 客户端认证的配置项——可以看出，这套面向 AI 和多模态数据场景的存储层依然在快马加鞭地搭底层设施，离真正稳定还有一段路。^[2]

Neon 后端全线 GA，面向 agent 开放完整原语集 agent

Neon 这次宣布，旗下"lakebase 架构"里的所有后端能力都转正到GA阶段了：数据库本体Lakebase Postgres（走计算和存储分离路线）、对象存储、Functions、托管版的 Better Auth，还有 AI Gateway，这五件套现在都能拿来生产用了。这背后其实是 Neon 给自己重新定了位——它不再只想当一个数据库，而是要把"agent 搭应用所需要的整套后端"拆成一堆可以自由组合的原语。想想看，一个编码 agent 部署 Postgres 是不够的,它通常还得接上对象存储来放上传的文件、跑一些异步任务、处理鉴权、再调用模型;如果这些东西都散落在 Neon 之外各管一段,agent 拼出来的应用就容易出问题,比如分支感知失效、鉴权系统彼此割裂。Neon 押的宝是:agent 其实更擅长拼装它已经理解的那些标准原语——Postgres、兼容 S3 的 API、标准的模型 SDK,而不是去适应某一整套打包好的 BaaS 范式。值得一提的是,这也是 Databricks 收购 Neon 之后,"lakebase"这个定位第一次变成了一条完整的产品线落到地上。^[3]

4B 模型经强化学习训练，查询计划比 Postgres 默认快 81% ai-native

有个独立研究者叫 Rohan Bansal，拿开源的 Qwen 4B 模型做了个实验：先监督微调一遍，再上 agentic 强化学习——具体做法是让模型针对同一个查询生成几套候选执行策略，然后真的丢进 Postgres 里跑一遍看实际耗时,把这个耗时转成标量奖励喂回去更新模型权重,如此反复,模型渐渐学会了给出比 Postgres 自带优化器更快的执行计划。这里有个背景:查询优化里挑连接顺序（join ordering）这件事本身是个 NP-hard 难题,学界这十年来（可以追溯到 Leis 等人 2015 年的工作,后续也一直有跟进研究）一直证明主流优化器留有明显的改进空间;而这个实验之所以能跑通,恰恰是因为"计划好不好"这件事可以直接拿执行时间验证,正好落在强化学习最擅长处理的"可验证任务"这一类里。这条帖子在 HN 上拿到了666个赞、136 条评论,在这波数据库和 AI 的交叉浪潮里,算是少见的、扎实的开源实验,不是厂商在自吹自擂。^[4]

Turbopuffer：对象存储架构让法律 AI 检索成本降一个数量级 vector

做法律 AI 的Legora平台在 AI Engineer 播客上,回顾了自家检索架构走过的四代变迁:一开始只用一个 Elasticsearch 集群,后来因为数据驻留的合规要求,不得不按美、欧、澳三个地区各自复制一整套全栈系统;再往后,银行客户又提出要物理隔离、要自己管密钥（CMEK），逼得他们又一次推倒重来。他们手里的法律研究语料快摸到100 亿条向量了,分布形态很特殊——一小部分辖区极度热门,剩下一大堆是长尾冷数据,呈明显的双峰形状,传统那种全靠内存撑起来的架构面对这种数据形状根本吃不消。Turbopuffer 的 CEO Simon Eskildsen 给出的思路是:别再指望全内存索引扛下所有负载了,转而让对象存储去接下大部分的活。有人评价说,这个架构上的取舍其实是当前 AI 检索基础设施能不能算得过经济账的关键分水岭,而不只是单纯砸更多算力就能解决的事。^[5]

DuckDB 官方发布 Claude Code 技能插件 agent

有了 duckdb-skills 这个插件,Claude Code 就能直接通过 DuckDB 的命令行工具去读数据文件、跑查询、转格式、探索数据集了。这可以算是 DuckDB 生态朝"agent 原生数据工具"这个方向又迈了一步,也正好对上本刊最近一直在观察的那个趋势——agent 越来越倾向于直接连上数据库来干活。^[6]

Apache Iceberg / Hudi 同步进入下一版本候选期 lakehouse

Apache Iceberg 把 1.12.0 的第一个候选版本（rc0）放出来了，Apache Hudi 这边也没落后，同步推进着 1.2.1 的 rc1、rc2。两个开放表格式项目目前都卡在候选发布这个阶段，正式版最终会带哪些特性还没敲定，至少现在还看不出有什么颠覆性的变化要公布。^[9]

ClickHouse 发布 WalShadow：绕开逻辑复制，直读物理 WAL ⚠️ 厂商基准口径

WalShadow 是 ClickHouse 新开源出来的一个 Postgres 到 ClickHouse 的复制引擎，它没有走传统 CDC 那套依赖逻辑复制槽的老路，而是直接去消费 Postgres 本来用于物理备库和故障恢复的那份物理 WAL 流，在源库外面解码完再写进 ClickHouse 原生的数据块里——这样一来，逻辑解码插件、Kafka 中转、JSON 序列化这几道环节全都省掉了。根据 ClickHouse 自己测的数据，Postgres 那边提交一笔事务之后，大约200ms就能在 ClickHouse 里看到，吞吐能跑到每秒28.9 万行，这个速度足够跟上源库的写入节奏；不过因为数据块是并行处理的，到达顺序可能会乱，所以系统靠附加在源端的 WAL 位点（_lsn）来保证顺序，遇到 schema 变更或者截断这类操作还会设个屏障来兜住一致性。这个工具已经开源了，同时也在 ClickHouse Managed Postgres 上放出了私测版本——原因是大多数托管 Postgres 服务本身并不对外开放物理 WAL，只有两头都自己管的 ClickHouse 才有条件把这条路走通。这条帖子在 HN 上收获了 60 个赞和 10 条讨论。^[10]

DuckDB 生态双料并购：AWS 收编核心团队，MotherDuck 补齐管道层

AWS 这次宣布把DuckLabs给收购了——这是 DuckDB 项目背后那支阿姆斯特丹的工程团队，不过AWS 拿到手的是这批人和他们对项目路线图的影响力，代码所有权可不在其中：DuckDB 项目本身还是归独立的 DuckDB 资本会管着，同一份代码在 MIT 许可证下，Azure 和 Google Cloud 照样能免费拿去用，AWS 并没有因此把别人排除在外。有分析认为，AWS 真正想赚的钱其实是"数据引力"这块——围绕引擎周边搭起来的那些增值层，比如 S3 集成、托管运维、安全和计费，而不是引擎本身。差不多同一时间，已经运营 DuckDB 托管云服务四年的独立公司MotherDuck，也完成了它自己有史以来第一笔收购——买下了Tower.dev，这家公司是前 Snowflake 工程师 2024 年在德国创立的，一直专注做 Python 数据管道"最后一公里"的事，比如打包、部署、生产环境运行。靠着这次收购，MotherDuck 才在几周内就上线了"一句提示词就能生成数据管道"的 Flights 功能。这两笔交易的具体金额都没披露，但放在一起看，它们共同标出了一个节点——DuckDB 生态正从纯粹的开源项目走向商业化分层。^[12]

Databricks：新加坡加码 3.5 亿美元投资，同步推数据支出治理工具 cloud

Databricks 表示接下来会在新加坡再追加投资，金额超过3.5 亿美元，用来应对企业级 AI 采用加速之后当地对算力和数据基础设施冒出来的需求；差不多同时，他们还发文介绍了一套面向企业的AI 支出治理能力，说是要帮客户在大规模用 AI 的时候把成本控制住。不过这两件事说到底都是厂商自己在讲战略和产品，具体落地能到什么规模，暂时还没有第三方数据能佐证。^[13]

ClickHouse 深化与 dbt v2 及 dbt Platform 集成 cloud

ClickHouse 又把和 dbt Labs 新一代dbt v2以及 dbt Platform 的集成往深里做了一层，这延续了分析型数据库这几年越来越往数据转换工具链上靠拢的生态大趋势，本质上算是一次常规的生态合作动作。^[14]

FutureX · 记录未来如何发生

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