Databricks伸手应用层了

数据平台的天花板，是被自己的定位限死的

做了十几年数仓的人都有个体感：数据平台的预算话语权，永远不如业务系统。ERP、CRM、内部工具，这些真正跑在业务一线的应用，从来不是数据平台的地盘。数据平台再强，也只是'给应用供数的后端'。

现在，Databricks 想改写这个格局。它把 PostgreSQL 搬进了自家版图——以 Lakebase 的形态——再拉上 AI 编程平台 Replit，给出了一条从'写代码'到'跑一个受治理的企业应用'的完整链路。素材里的表述很直白：Replit 与 Databricks 的组合，为企业提供了从开发到部署的完整平台。

这不是一次普通的产品合作。这是数据平台向应用层的正式伸手。

🧩 补上OLTP这块缺口，Lakebase不是又一个数据库

每一条产品线的出现，背后都是一个架构上的'缺口'。

Databricks 的基本盘是湖仓：Delta Lake、Spark、以及后来的 AI 栈。但湖仓天然偏分析负载（OLAP）。企业真正每天在跑的业务系统——订单、工单、用户档案、审批流——是 OLTP 的世界，长期属于 Oracle、MySQL 和云上的托管 Postgres。

这造成了一个很现实的问题：企业的数据被切成了'分析侧'和'事务侧'两套体系，中间靠 ETL/CDC 管道搬运。数据平台号称一站式，实际上只管了一站。

Lakebase 的出现，就是来堵这个缺口的。它基于 Postgres 这一 OLTP 事实标准构建，但做了两个关键改造：一是云原生的存算分离，弹性伸缩；二是与 Databricks 湖仓和 Unity Catalog 治理体系打通——事务数据和分析数据在同一个治理域里，而不是隔着一条管道互相张望。

值得注意的是，这条路并非 Databricks 独有。Snowflake 同样在 2025 年押注 Postgres 路线，两大湖仓巨头在同一时间窗口补 OLTP，说明这不是个别公司的产品试错，而是一个行业共识：分析平台如果要成为企业数据的唯一真相源，就必须同时管住事务数据。

从工程师视角看，这个架构最诱人的地方在于'减少搬运'。过去一个业务应用要消费分析数据，得走数据导出、接口开发、权限对齐三道工序；现在事务与分析同域，应用可以直接挂在治理层之下。搬运少了，延迟低了，出错的环节也少了。

🤝 Replit入局：AI编程把'数据应用'的成本打穿了

光有数据库还不够。缺口的另一半，是'谁来写应用'。

过去企业里能做应用开发的人，和懂数据的人，是两拨人。业务部门想要一个数据看板加审批流的小工具，排队排到 IT 部门三个月以后，最后往往不了了之。这是所有企业数字化里最普遍的痛。

Replit 代表的是另一条路：用 AI 编程助手把开发的门槛降下来，业务人员或者半技术人员，用自然语言描述需求，就能生成可运行的应用。这种被业内戏称为 'vibe coding' 的方式，2024 年以来在海外开发者社区里声量极大。

但 Replit 这类平台一直有个软肋：应用可以很快长出来，数据却接不进来。 生成的应用连不到企业级数据，连上了也没有统一的权限和审计。一个随手生成的应用，接的是企业最敏感的客户数据——这在任何一家有合规要求的公司都是不可想象的。

Replit 与 Databricks 的组合，恰好各补各的短板：Replit 负责把应用'写出来、跑起来'，Databricks 负责让应用背后的数据'受治理、可审计'。素材中'开发到部署的完整平台'这一定位，本质上是把过去三支团队（数据团队、应用团队、安全合规团队）的工作流，压缩进了一条链路。

据多位接近海外企业客户的从业者反馈，这类'AI 生成应用 + 受管数据底座'的组合，已经在数据密集型行业的中后台场景开始试点。判断它能不能大规模铺开，关键不在开发体验，而在下一节要谈的东西：治理。

⚖️ 真正的护城河不是生成应用，是受治理的应用

市面上能生成应用的 AI 工具一抓一大把。Databricks 这套组合真正的差异点，是'governed'（受治理的）这个词。

想想企业数据平台的采购逻辑。CIO 批一个数据平台预算，最怕的不是贵，而是数据出平台后失控——影子 IT、口径打架、权限裸奔。所以任何让数据'更容易被消费'的产品，如果不同时让数据'更可控'，在企业市场就是减分项。

Databricks 的打法是反过来做：应用越是遍地开花，治理越是刚需。当业务部门一个月能生成几十个小应用时，谁来管这些应用读了什么数据、写了什么数据、谁来审计？答案只能是 Unity Catalog 这样的统一治理层。应用的爆炸式增长，反而成了治理平台的卖点是它押对了节奏。

这个飞轮的产业含义很深：数据平台的竞争维度，正在从'谁的查询快、谁的存储便宜'，转向'谁能让更多应用安全地长在自己的数据之上'。查询性能是同质化的，治理能力是生态性的。前者拼参数，后者拼多年积累的权限模型、血缘追踪和合规认证——这些东西后来者很难速成。

另外一笔账要算清楚：湖仓 + 事务库 + AI 编程工具，三件套都留在一家厂商的账号体系里，意味着数据和应用的工作负载都沉淀在同一个平台。对厂商来说，这是客单价和续费率的双重提升；对客户来说，则是绑定加深的双刃剑。

⚠️ 冷静看：三条没解决好的问题

骂完了泡沫，也得泼点冷水。这套叙事至少有三个待验证的环节。

第一，AI 生成的应用质量参差。 Demo 阶段的 vibe coding 很惊艳，但企业级应用要考虑并发、异常、版本管理和长期维护。自然语言生成的代码，三个月后谁来接手改造？如果生成出来的应用是'一次性烟花'，这个模式就撑不起企业级采购。Replit 和 Databricks 都还没有给出规模化案例的公开证据。

第二，Postgres 生态的老问题不会因为换了个壳就消失。 高并发核心交易场景下，云原生 Postgres 的极限在哪里、迁移成本有多高，企业客户会拿放大镜看。Lakebase 最可能先吃下的是'中负载业务应用'这一层，而不是去撬 Oracle 的核心交易盘。

第三，生态位竞争会立刻升级。 Snowflake 在 Postgres 路线上同步落子，云厂商（AWS、Azure、GCP）既有自家的 Postgres 托管服务，又有 AI 编程工具。Databricks 想把开发、数据、部署全链路留在自己体内，必然与三朵云产生更直接的摩擦——而它自己又高度依赖云厂商的基础设施。这个三角关系怎么演化，比产品功能更值得盯着。

🇨🇳 对国内数据平台的镜鉴：别只学产品，要学节奏

回到国内语境。这几年国内数据平台圈的声音很杂：湖仓一体、存算分离、Data+AI 一体化，概念一个接一个，但客户的付费动作始终偏保守——企业愿意为'更好的报表'付小钱，很少为'更好的架构'付大钱。

Databricks 这步棋给出一个启发：数据平台要提高客单价，光在分析层内卷没有出路，得往离业务更近的地方走。 往近处走有两条路：一条是往事务层走（Lakebase 这条线），一条是往应用生成走（Replit 这条线）。两条路在治理层汇合，构成闭环。

国内厂商其实手里有类似牌面：既有湖仓产品的公司，也有 OLTP 数据库公司，还有低代码和 AI 编程赛道的玩家。但多数公司的产品线是并列的，没有在治理层真正打通——事务库归事务库，湖仓归湖仓，权限体系各管各的。素材里这套组合最有含金量的不是某个单品，而是'同一治理域'这个架构决定。

另一个可借鉴的是节奏：Databricks 是先用三年时间完成 AI 栈、表格式、事务库的收购拼图，再对外讲一体化叙事。收购在前，故事在后，每个故事都有真实资产托底。国内不少平台是叙事在前、能力在后，这也是'中台'这个词被透支的原因之一。

当然，国内有国内的约束：数据安全与合规要求更细，信创环境下的选型逻辑不同，业务人员的编程素养分布也不同。直接照搬'业务人员自己生成应用'的模式，短期内不现实——但'AI 辅助开发 + 平台托管数据 + 统一治理'这条工程路径，方向上没什么好怀疑的。

结语：下一场竞争，在应用层的地皮上

把时间线拉长看，数据平台的进化路径很清晰：第一代卖的是存储和计算，第二代卖的是分析能力，这一代开始卖'数据之上的应用生态'。

Databricks 用 Lakebase 补事务缺口、用 Replit 补开发缺口、用 Unity Catalog 收口治理——三个动作拼出的，是一张通往应用层的船票。这张票能不能兑现成真实的营收和客户留存，要看未来一两年的规模化落地；但方向本身，已经写在了两大湖仓巨头同期的产品动作里。

对从业者的建议很朴素：别急着评估单个产品的好坏，先想想你的组织里，'写应用的人'和'管数据的人'什么时候会变成同一拨人。这一天到来时，你准备好的架构，就是你的位置。