The 40-year-old database rule agents just broke: How LTAP unifies OLTP and OLAP workloads

Summary

LTAP (Lake Transactional/Analytical Processing) addresses the long-standing separation between operational row-oriented databases and analytical column-oriented systems, which traditionally required pipelines and copied data. It uses Lakebase’s stateless, ephemeral compute decoupled from durable lake storage to expose live operational data for analytical queries without moving it or loading the transaction-serving system. The storage layer preserves Postgres data types and physical representation while writing data into Parquet, with a hot row-format tier for operational access and a cooler columnar tier for analytical reads; Apache Spark and SQL can read that representation directly. By separating serverless operational and analytical compute, LTAP allows each workload to use specialized engines and independent capacity, while a unified catalog applies governance across both. The stated motivation is agentic workloads such as fraud detection, where stale copies miss fast events and uncontrolled analytical queries can degrade transactions.

Takeaways

1. 1

   LTAP runs analytical queries against live operational data without moving it or placing analytical load on the transaction-serving system.

2. 2

   The storage layer preserves the exact physical representation of Postgres data while exposing it through Parquet, with row and columnar tiers for different access patterns.

3. 3

   Separate serverless compute for operational and analytical workloads avoids the cost and operational constraints of one engine handling both jobs, while unified catalog policies govern the shared data.