Databricks Converges OLTP and OLAP

Databricks is trying to turn the database layer from a handoff between separate systems into one continuous workflow. Instead of writing app data into Postgres, copying it into a warehouse, then building AI on top, Lakebase keeps Postgres style operational data tied to the same lakehouse foundation used for analytics and model work. That matters most for AI apps, where the same customer event may need to update a record instantly and also feed analytics, retrieval, or model decisions right away.1 2 3

• In practice, OLTP means small, fast reads and writes, like creating an order, updating a ticket, or saving agent memory. OLAP means scanning lots of rows to answer bigger questions, like churn by cohort or fraud patterns. Lakebase is Databricks pushing both jobs into one stack, using Neon based serverless Postgres for the transactional side.1 2
• The old model creates copies and lag. A product team stores live app data in an operational database, runs ETL into a warehouse, then trains models or dashboards on delayed data. Databricks is selling a setup where operational data can also be analyzed in the lakehouse without the same export and sync burden.2 3
• This is also a competitive response. Snowflake has been making the same convergence bet with Unistore and Hybrid Tables, aimed at running transactional and analytical workloads in one platform. The winner gets a bigger share of the database budget because application state, analytics, and AI workloads stop being separate purchases.4 5

The next step is that data platforms look more like application platforms. If Databricks can make developers comfortable building real products on Lakebase, not just dashboards and pipelines, it moves from being a place data teams analyze information to being a place engineering teams run customer facing software and AI agents end to end.1 2 5