I recently wrote about the emerging category of data platform products that facilitate the deployment of Online Transaction Processing workloads on data lakehouse architecture. Databricks Lakebase is a prime example of this OLTP-on-lakehouse approach, which was added to its Databricks Data Intelligence Platform in 2025 and became generally available earlier this year. At the company’s recent Data + AI Summit in San Francisco, Databricks announced new Lakebase capabilities that enable users to perform operational and analytic processing on the same data using an architectural approach described as Lake Transactional/Analytical Processing (LTAP). The company also announced new real-time data processing and analytics capabilities, as well as significant updates to its agent portfolio.
Databricks was founded in 2013 and was initially built to provide managed services that enable data engineers, data scientists and developers to create and maintain data engineering and machine-learning workloads using Apache Spark. While Spark-based data processing remains at the heart of its portfolio, Databricks has significantly expanded beyond that initial starting point.
Today, the Databricks Data Intelligence Platform provides a combination of services for data engineering, data governance, data warehousing, business intelligence, artificial intelligence and agent development. It is available on Amazon Web Services and Google Cloud, as well as Azure Databricks for Microsoft Azure and SAP Databricks for SAP Business Data Cloud. Databricks Data Intelligence Platform is used by more than 20,000 customers, delivering more than $5.4 billion in revenue, over $7 billion in funding, and a valuation of $134 billion, according to its recent announcement. Databricks was rated as an Exemplary Provider in several 2026 ISG Buyers Guides, including AI Platforms, Data Platforms and AI Agents as well as Real-Time Data and Streaming Analytics.
Databricks has primarily focused on analytic workloads, including data science, data warehousing, BI and AI. The introduction of Databricks Lakebase in June 2025 was significant in addressing the deployment of critical operational workloads. Enabled by the earlier acquisition of Neon, Databricks Lakebase is a serverless PostgreSQL database designed to address many of the emerging requirements for operational databases, including automated scaling and resiliency, as well as database cloning and branching. As I recently described, one of the primary advantages claimed by OLTP-on-lakehouse offerings is the decoupling of the storage layer from the compute layer. This enables the use of relatively low-cost, highly durable cloud object storage as well as independent performance and scaling of compute and storage to meet demand, avoid unnecessary overprovisioning costs and better align costs with usage.
The use of cloud object storage as a shared storage layer for both analytic and operational workloads also facilitates a reduction of data replication requirements by enabling operational and analytic workloads to read and write the same data. Eliminating replication between operational and analytic data platforms has long been a holy grail of the data platform market. As I previously described, a key challenge associated with running both analytic and operational workloads on the same data is ensuring that analytic processing does not impact the performance of operational processing. In fact, the need to protect the performance of the operational workload is precisely why traditional architectures have involved the extraction, transformation and loading of data from the operational data platform into an external data platform, enabling the operational and analytic workloads to run concurrently without adversely impacting each other.
For that reason, there was considerable interest in Databricks’ announcement that it had extended Lakebase with an LTAP architecture designed to unify transactional and analytic processing on a single copy of data, without forcing both workloads into a single engine. With further details, it became clear that while, from the customer’s perspective, there is a single copy of the data, behind the scenes Databricks will manage the complexity involved in replicating data from the operational Lakebase Postgres engine to be stored and governed in Unity Catalog. This process will use columnar table formats such as Delta Lake and Apache Iceberg and made accessible for analytic processing using the new Reyden engine for real-time analytics. Reyden is the core engine behind Databricks Lakehouse//RT, which was also launched at Data + AI Summit and is designed to bring high-concurrency analytics to data stored as Delta and Iceberg tables in the Lakehouse.
The driver for the development of both LTAP and Lakehouse//RT is the adoption of agents that automate the provisioning and management of operational databases and analytic
Databricks is by no means alone in delivering capabilities to unite operational and analytic processing in PostgreSQL. EDB recently launched converged analytics capabilities for EDB Postgres AI, and pgEdge announced pgEdge ColdFront. Snowflake announced in 2025 the open source release of the pg_lake PostgreSQL extensions. Potential adopters are advised to pay close attention to the technical details of these approaches and consider the relative immaturity of these offerings, which are all in the early stages of development. With that caveat, I recommend that enterprises evaluating OLTP-on-lakehouse products include Databricks in these assessments.
Regards,
Matt Aslett