Databricks Expands into Operational Databases

This pushes Databricks from being the place where companies analyze data after the fact into the place where applications actually run. Lakebase and Neon let a team keep the app database, the analytics store, and the AI workflow in one stack, so a developer can write transactions into Postgres, query fresh operational data in Databricks, and feed the same data into models and agents without shuttling it through separate systems.

• Neon gives Databricks a real OLTP entry point, not just a feature checkbox. Neon had more than 18,000 customers and a serverless Postgres design that separates compute from storage, which is the core trick behind making transactional databases scale more like cloud infrastructure.
  2 sacra 5 cnbc 6 sacra
• The product gap this closes is simple. Databricks historically handled batch analytics, BI, model training, and SQL warehousing. Operational apps still needed a separate system like Postgres or Aurora to handle inserts, updates, and user facing transactions in milliseconds.
  1 sacra 3 databricks 4 sacra
• This also changes the competitive set. Databricks is moving closer to companies like SingleStore and Cockroach Labs that sell databases for live application workloads, while using its lakehouse and governance layer as the wedge to offer both operational and analytical workflows together.
  7 sacra 8 sacra 9 sacra

The next step is turning Lakebase into the default database for AI built on Databricks. If developers can spin up Postgres for an app, connect it to governed lakehouse data, and serve agents on top of the same system, Databricks captures more of the software stack above analytics and becomes harder to displace.