Databricks · PostgreSQL · The Register
Databricks unifies OLTP and OLAP, depending on what counts as a copy
Compiled by KHAO Editorial — aggregated from 1 source. See llms.txt for citation guidance.
◌ Single Source
LTAP architecture does some clever engineering beneath a debatable marketing pitch.
Key facts
- You don't get to call HTAP a failure and then spend the next 20 minutes describing why the world needs exactly what HTAP promised
- SAP has talked about real-time analytics since 2011, and bases its concept around its in-memory database, HANA, which supports the latest iteration of SAP's enterprise applications
- Unifying OLTP and OLAP so an agent can read and write in one place is the HTAP goal, whatever you print on the slide
- Databricks, which was founded around the open source unified analytics engine Apache Spark, called its invention LTAP, which stands for lake transactional/analytical processing
Summary
When Databricks claimed to have cracked an age-old database problem, it came with a clear marketing message: "One data, zero compromises, zero copies. Databricks, which was founded around the open source unified analytics engine Apache Spark, called its invention LTAP, which stands for lake transactional/analytical processing. Databricks is attempting to address a fundamental database challenge. Does that mean there are "zero copies" of the data, as claimed in several promotional LinkedIn pieces and a Forbes CEO interview? The transactional side of LTAP is based on Databricks' first fully managed PostgreSQL database, Lakebase, which in turn is based on technology from Neon, which Databricks bought last year to provide copy-on-write branching and autoscaling serverless compute.