帮被投公司开了个Lakebase，顺手和别扭都说说

我投的一家做Agent的早期公司，创始人上周找我，说后端要炸了。产品侧的分析跑在Databricks上，用户侧的事务数据在另一个Postgres里，中间靠一堆定时任务搬。加个字段要动三处，上个月有次同步延迟，用户看到的余额是旧的。

这场景我见得太多了。所以我让他别急着加中间件，先去Databricks工作区里开一个Lakebase试试。这个创始人我认识两年，执行力没问题，就是容易在架构上想复杂。

先说Lakebase是什么。它是Databricks推的完全托管Postgres，跑在湖仓上面。Postgres就是那个开源关系型数据库，大家都熟。Databricks原来主打分析，行话叫OLAP，跑报表、跑训练数据；Lakebase补的是另一块，叫OLTP，也就是用户在App里下单、改状态这种一笔一笔的事务。把Unity Catalog挂上，就是Databricks那套权限和数据目录，直接复用。

准备阶段比我想的简单。在工作区里建项目，选自动缩放那个版本。这里有个背景，早期有个Provisioned版本，固定规格、手动扩容，官方说那些实例都已经升级到自动缩放平台，名字也简化成Lakebase了。我这边开的是新的，没碰到老版本。

Lakebase沿用PostgreSQL处理事务，目标是满足长期保存数据、按负载启动扩缩和关闭计算、从已有数据库状态创建独立测试分支、分析引擎在独立资源上读取共享数据这四项需求。

这是那篇PVLDB论文里的说法，我读完的感受是，后两条才是它跟普通云Postgres真正拉开差距的地方。

上手第一件事，连。连接串给得很标准，psql直接能连。它内置了PgBouncer连接池，官方说能撑到一万个并发客户端连接，对那种开一堆短连接的无服务器函数很友好。我这边压不到那个量级，但短连接场景确实没报错。

然后试数据API。这是跟PostgREST兼容的REST接口，库里有表，它就自动生成增删改查的端点，不用自己写后端。创始人最烦的就是给每张表手写一套接口，看完这个眼睛亮了。不过部分操作还在Beta，别一上来就往生产上放。

踩坑来了。连接池那块需要原生Postgres的密码认证，OAuth角色走不通。我们一开始用OAuth配的，连不上，折腾了快一个小时才反应过来。文档里写了，我没细看，典型的「不看文档就撞墙」。

第二个是分支。Lakebase能从一个数据库状态直接拉一个独立的测试分支出来，这个我用得最爽。给Agent做prompt迭代时，拿生产数据的分支去跑，跑脏了直接扔掉，不碰主库。但分支不是免费的，你得想清楚哪些要留着。

第三个是搜索。它把向量和关键字搜索做进了Postgres。我拿一个小数据集试了下，本地文件缓存的大小要跟向量索引差不多大，热数据才留得住，不然延迟就上去了，候选池怎么过滤也影响召回。这块我没深挖，感觉是给已经懂向量检索的人准备的，新手直接上会有点懵。

结论。推荐给已经在Databricks上跑分析、又要补事务库的团队，数据不用搬来搬去，权限直接复用，这个省的事是实打实的；还有那种做Agent、需要频繁拿生产数据开测试环境的团队，分支这个功能值钱。不推荐给单纯想要一个便宜云Postgres的人，它的价值在湖仓集成上，不用Databricks那套，为它绑上去不划算。对延迟极度敏感又不想调缓存和索引的团队，也得掂量。

前后断断续续弄了一周多。以后运营库和分析库中间那层ETL会越来越薄，数据库分支会变成AI应用的标准开发流程，就像现在没人直接在主干上改代码一样。