"Ali Ghodsi wants to rebuild the stack itself," writes Victor Dey for Forbes. For 40 years, every data stack has carried the same split: one set of systems to run the business, another to analyze it. The real bottleneck for agentic AI isn't model intelligence. It's that divide. At #DataAISummit, we introduced LTAP (Lake Transactional/Analytical Processing): both transactional and analytical engines running on a single copy of data, in an open format. One data, zero compromises, zero copies. It's built on Lakebase, our serverless Postgres database. Across the platform, agents now create roughly 80% of databases. "Our primary user is already the agent," says Databricks co-founder and CEO Ali Ghodsi. Read the full story: https://lnkd.in/g-cH4wxG
The lake is the problem, not the solution. If you are still building your architecture around a Lakehouse, you are 15 years too late. Just like distributed computing overtook the single server, trying to consolidate all of your data into a “lake” doesn’t scale and doesn’t solve the business problems of global organizations.
Fascinating perspective from Ali Ghodsi and a great write-up! The statistic that agents are already creating 80% of databases via Lakebase shows a massive paradigm shift in our industry. As data enthusiasts, we see a near future where data professionals transition from managing basic infrastructure to orchestrating these intelligent agents over a unified data layer. Do you think the traditional ETL pipeline is finally nearing its end with the rise of LTAP architectures?
For those wondering whether low latency OLTP workloads can be served directly from columnar data: you are absolutely right, they can't - and that's why that's not what Databricks introduced this week. If you look at the 2:45:46 timestamp in the keynote, linked below, you can see the answer: there are two entire services, Safekeeper and Pageserver, serving OLTP workloads. What is new is that these services (previously idle and I/O bound) now also serve as live (but async) translation layers with columnar persistent storage formats, providing a zero-pipeline interface to OLAP and reducing I/O through compression. As usual, the answer is a layer of indirection - which was already there to begin with in Lakebase technology. A clever re-use of existing and previously idle capacity to create a new quality of its own. https://www.youtube.com/watch?v=Qux8E-L1mk8&t=2h45m46s
Unifying database management is the way forward. I'm eager to try out Lakehouse//RT to see how it performs. I'm especially curious as to how they got the latency to be sub second and how much data crunching can be done with it. Once the industry will have a SQL engine with C like performance, there will be real questions as to what to do with the rest of software engineering. Why bother with frontends when a UI is one select... from <HMI> away? Why bother with N- tier applications backends or *gasp* microservices when all of your applications are hosted on a federated data platform and governed with a meta-catalog, it's just more SQL instead of dead by design back-end implemented business rule code? Seems to me that the industry is a few innovations away from fundamental changes unrelated to AI but that will make AI significantly more usable because building an entire ecosystem will have become radically simpler.
Great insights from Data + AI Summit! As organizations accelerate their AI journey, the focus is shifting from isolated pilots to scalable, secure, and business-driven AI adoption. Systech Solutions, Inc, we see strong data governance, operational intelligence, and automation as key enablers for unlocking real enterprise value from AI. Looking forward to seeing how these innovations shape the future of digital transformation.
The "Agentic Era" is exposing just how brittle and outdated our legacy data plumbing really is. Moving data from an app database to a lakehouse via continuous replication pipelines introduces cost, complexity, and a latency gap that blinds AI agents operating in real time. By making the operational database (Lakebase) write natively to open lakehouse formats, Databricks is effectively cutting out the data-movement middleman. While SaaS API ingestion and semantic transformations (dbt/DLT) will always be necessary, this LTAP approach poses an existential threat to vendors that exist solely to move internal operational data. The plumbing layer is about to get squeezed hard.
Great to see the industry moving in this direction. SingleStore has been delivering this for years, with millisecond performance and enterprise scale. Looking forward to seeing how it performs
LTAP sounds like it fixes the 40-year problem. But the problem was never just OLTP vs OLAP. It’s latency, concurrency, and context under real-world load. One copy of data doesn’t solve: stale pipelines slow decisions systems that break when agents scale AI fails when the data layer can’t keep up. The real shift isn’t fewer systems. It’s eliminating the gap between data → decision → action. Anything less is just a cleaner stack diagram.
Here’s the part I’m genuinely curious about 🤔 LTAP unifies the storage format — row for writes, columnar for reads, handled automatically. Brilliant. But it unifies the format, not the data model. OLTP lives in 3NF for a reason — integrity, clean writes, no update anomalies. OLAP lives in star schemas, denormalized tables and pre-aggregates for a reason — fast, cheap reads. So in a single LTAP world, how does the modeling actually play out? Do my normalized Postgres tables just get mirrored as-is, leaving the dimensional layer to be rebuilt as gold tables / views on top? Or does the analytics experience suffer if nobody denormalizes?