Databricks Merges OLTP and OLAP
Databricks
This shifts Databricks from being a place where teams analyze yesterday’s data to a place where they can also run the live app itself. In the old setup, an app wrote transactions into Postgres or MySQL, then copied that data into a warehouse for dashboards, model training, or batch jobs. With Lakebase and Neon, the same platform can handle app writes, stream changes into Delta Lake, and make fresh operational data available for analytics and AI without the usual handoff between separate OLTP and OLAP systems.
-
The practical win is fewer moving parts. Instead of running a transactional database, ETL pipelines, and a warehouse as separate systems, a team can keep the application database and the analytical store tightly connected. That matters most for AI products where the model needs both long term history and the latest user action in the same workflow.
-
This is also a competitive land grab upstream of the warehouse. Databricks bought Neon for about $1B in May 2025, and Snowflake moved similarly into Postgres through Crunchy Data. Both moves reflect a simple fear, if the next generation of apps starts on the application database layer, the warehouse vendor that does not own that layer risks getting bypassed.
-
There is precedent for this architecture, but also a reason it is hard. SingleStore spent years selling one database for both transactions and analytics, yet larger enterprises often still preferred specialized systems. Databricks has a stronger shot because it is not replacing the lakehouse, it is attaching Postgres to a data and AI stack customers already use.
The next step is a data stack where application code, analytical queries, and AI inference all sit on one control plane. If Databricks executes, operational databases become another attach product inside the account, and the company captures more spend every time a customer builds an internal AI app, customer facing copilot, or agent that needs live state and historical context together.