Databricks collapses ETL with mirroring

This pushes Databricks from a system that stores analytics data into a system that can run the live app database and keep the lakehouse current at the same time. In practice, that means a row written into Lakebase Postgres can show up almost immediately in Delta tables for dashboards, model features, and agent workflows, instead of waiting for a separate ETL job or custom connector to copy it over.1 2 3 4

• The important shift is where the sync happens. Older ETL tools like Fivetran mostly pull from APIs or databases into a warehouse on a schedule. Mooncake style change mirroring moves database updates as they happen, which matters when the same data powers an app, an analyst query, and an AI agent in one loop.2 3 4
• This fits Databricks broader move up the stack. By late 2025, Lakebase for serverless Postgres sat alongside Databricks SQL and Mosaic AI as part of a product set aimed at capturing revenue from software built on top of the platform, not just the batch compute underneath it.1 2
• It also attacks a long standing pain point in the modern data stack. Separate connectors are valuable but brittle and expensive to maintain, especially when APIs change or when teams need fresher data than a 15 minute sync. Native mirroring reduces that glue work inside the Databricks product boundary.3 4

The next step is a tighter collapse of database, warehouse, and serving layer into one operating surface. With Lakebase, real time mirroring, and later Lakehouse//RT and LTAP, Databricks is heading toward a world where teams stop stitching together Postgres, ETL, warehouse, cache, and feature store as separate products, and buy one stack instead.1 2