数据平台开始下场造应用了

过去十年，数仓厂商反复强调自己是分析的终点；现在，Databricks 想成为应用的起点。当 Replit 的 AI 编程入口、Lakebase 的 Postgres 事务层和湖仓一体平台被串成一条线，数据平台的边界被重画了一次：分析平台开始下场造应用，而这可能才是序幕。

🧩 一块补了很多年的短板

数仓厂商不缺分析，缺的是写入。

先说一个数据工程师都熟悉的场景。报表体系搭得再漂亮，业务方迟早会提一个要求：能不能做个小应用？让区域经理录入门店库存、修改审批状态、给异常订单打标。这时候数据团队通常两手一摊——数仓不做双向写入，你得找应用开发组排期，另起一套 MySQL 或 PostgreSQL，再写 ETL 把数据搬回数仓。一条业务需求，被切成两个项目、两套技术栈、两个团队。

这条缝，Databricks 决定自己缝上。Lakebase 是其推出的托管 Postgres 服务，面向事务型负载和 AI 应用的状态存储；底座来自 2025 年对 Postgres 公司 Neon 的收购，天然带存算分离的弹性架构。更关键的是它长在湖仓一体平台上——Unity Catalog 的权限体系可以直接管到应用层。

把这条链路画出来，就是下面这张图：

产业逻辑很清楚：分析与事务之间那道人为的墙，在 AI 应用时代正在被重新缝合。Agent 写出来的应用需要状态库，而分析平台手里握着最重的数据引力——用户和数据在哪，应用就会长在哪。补 OLTP 不是不务正业，是顺势收口。

我的判断是：未来两年，『应用数据库与湖仓的打通成熟度』会成为数据平台选型的硬指标，其权重会超过单点查询性能。

🤖 写应用的写法变了，入口也变了

写应用的门槛降到了说话，可分发应用的门槛一点没降。

场景切到业务侧。一位运营同学打开 Replit，用自然语言描述：给各区域经理做一个库存预警面板，超阈值自动发邮件。Replit Agent 生成代码、配置依赖、连上数据、直接部署上线——这在两年前是两周的需求排期，现在是一个下午的自助操作。

Replit 是浏览器端的 AI 编程平台，Agent 覆盖从开发到部署的完整链路。与 Databricks 的集成点在于：Agent 生成的应用可以直接连接受治理的企业数据，应用自身的用户、会话、业务状态则落在 Lakebase 上。也就是说，AI 不只是『帮你写代码』，而是『帮你把应用安全地接到企业数据上』。

据多位接近企业客户的架构师观察，客户对这类集成最真实的诉求，往往不是『代码写得更快』，而是『别再让我为一百个 AI 应用各开一百套账号权限』。这句话值得玩味：供给爆炸之后，稀缺的从来不是应用，而是能被信任的应用。

产业判断是：vibe coding 把开发供给侧的产能放大了几个数量级，瓶颈整体后移到了『数据接入与治理』环节。谁提供『生成—连接—治理—部署』的闭环，谁就占据新的入口位。开发工具如果只停在个人创作者和中小团队市场，天花板肉眼可见；接入企业数据平台，才是从玩具走向生产的关键一跃。

🔐 治理才是真正的门槛，也是真正的卖点

没有治理的 AI 应用，在企业里活不过一次安全审计。

CIO 视角的场景是这样的：业务部门兴冲冲提申请，说要用 AI 工具直连生产库做应用。第一反应通常是拒绝——权限怎么控？数据出了边界算谁的？出了事故查谁的日志？过去一年，多少企业的『AI 赋能试点』死在这一问上。

素材标题里那个词值得逐字读：governed enterprise apps，受治理的企业应用。它的含义是权限、血缘、审计由 Unity Catalog 统一承担，应用层不再自建账号体系，数据访问从开发第一天就在治理框架内。把传统链路和新链路摆在一起看：

产业逻辑在这里发生了一个反转：治理从『绊脚石』变成了『卖点是护城河』。在数据要素流通、合规要求持续收紧的大背景下，可审计、可追溯的数据访问是企业级采购的硬前提。判断很明确：治理平面会下沉为所有 AI 应用的基础设施。独立的应用开发平台若不接入企业治理层，就只能停留在个人市场；反过来，谁先把治理做顺，谁就能承接住那波被 AI 放大的应用需求。

⚔️ 牌桌上人多了一圈，筹码却还是企业数据

竞争的维度变了：从谁的 SQL 更快，变成谁离应用更近。

这不是 Databricks 一个人的动作。Snowflake 同样在 Postgres 能力和应用生态上加码，三大云厂商手里本来就攥着自家数据库和低代码工具。把这条演进线放在一起看更直观：

三类玩家的牌面各有形状：

据多位接近厂商的人士观察，这轮军备竞赛的驱动力高度一致：单纯卖计算和存储的空间被压薄，平台都想往离客户决策更近的应用层挪一步。但有一块筹码谁都绕不开——企业数据在哪里，治理在哪里，应用的根就扎在哪里。

我的判断是：接下来的胜负手不在模型能力，而在『AI 应用直连治理数据』这条管道的成熟度和开放度。谁把自己变成所有 Agent 的数据后端，谁就赢下下一个平台周期。

💰 给国内数据团队的三个落地判断

别急着换工具，先问你的数据能不能被安全地摸到。

看了这么多热闹，落到工程侧给三条务实建议。

第一，架构上分清楚什么该进 Lakebase。事务型负载、应用状态、高频小读写进 OLTP；历史明细、大规模分析留在湖仓。Postgres 实例的单位成本远高于对象存储上的湖，全量照搬等于烧钱换心安。两条链路打通靠平台能力，不靠把数据搬成一个副本。

第二，治理先行，集成在后。先在 Unity Catalog 这类治理平面里把应用访问的权限模型、审计口径定义清楚，再放开 AI 工具的接入。顺序反了，回头清账的成本是十倍。

第三，组织边界要重画。『数据团队只管报表、应用团队只管写码』的分工正在失效，两边会在 AI 应用这个交界处撞在一起。提前设一个既懂数据模型、又懂应用治理的数据产品角色，比事后扯皮划算得多。

选型评估表上，建议新增一行：AI 应用直连治理数据的打通成熟度。这一行，未来比 TPCC 分数重要。

🧭 小结

Replit 加 Lakebase 这套组合拳，表面是两个产品集成，实质是 Databricks 对自身定位的一次改写：从分析的终点，变成应用的起点。OLTP 补齐、AI 入口接入、治理贯穿——数据平台的竞争由此进入应用层。下一步值得盯的，是这套范式能否催生真正的企业级应用分发生态，以及国内平台何时跟进同一张牌桌。