Look, this announcement seemed exciting, but I'm significantly less excited when I come across a completely unrelated tie-in to AI.
It breaks the illusion, and I'm reminded that it's just another PR announcement, and this is probably not going to impact my life at all in any way ever. So I'm off to the next article instead of reading any more.
What makes you say it’s unrelated? At my job currently the core bridge between AI and data goes through ChatGPT and databricks. Even before opening the article my first thought when seeing the title was “I wonder if this is useful for our AI”.
From the sound of it this is just another slight point of friction being removed and we’ll be able to run applications directly against “Postgres in databricks” with no need for ETL between the data and our business chat layer.
Nothing revolutionary, sure. But I have to admit I’m still getting used to the fact that we don’t need anyone developing analytical dashboards or designing sql queries for reports or investigations because you can just ask to get exactly the insights you want and everything gets done by AI, and this is just another step supporting that as the default desire path when building on databricks.
I'm sure as hell going to be using agents to analyze all data, but that doesn't help me understand what is going on with Databricks here, and focusing on "agentic" merely adds noise to that understanding.
> No performance tradeoffs, for any workload: Transactional workloads run in standard Postgres with full ACID semantics. Analytical workloads run across the full Lakehouse at any scale and concurrency. Each scales independently, and because there's no data movement between systems, operational and analytical results are always in sync — with no copies or shadow infrastructure.
How can there be no performance trade-off if storage is handled by PostGres and there is no data movement to convert it to columnar ?
This deserve a technical explanation because this seems impossible.
Curious how is the final format of the data in LTAP storage - is it columnar? If so then what happens to OLTP performance - the blog and all info speaks to OLAP performance but what about your app
Hey I mean we've been using a fairly basic mssql box for years in a organisation of about 300 and it humms along nicely - granted we have 2 'materialised' aggregate tables/views (done in Python) but the TCO is tiny, and there is very little learning curve.
> The New Data Foundation for the Agentic Era
Look, this announcement seemed exciting, but I'm significantly less excited when I come across a completely unrelated tie-in to AI.
It breaks the illusion, and I'm reminded that it's just another PR announcement, and this is probably not going to impact my life at all in any way ever. So I'm off to the next article instead of reading any more.
What makes you say it’s unrelated? At my job currently the core bridge between AI and data goes through ChatGPT and databricks. Even before opening the article my first thought when seeing the title was “I wonder if this is useful for our AI”.
From the sound of it this is just another slight point of friction being removed and we’ll be able to run applications directly against “Postgres in databricks” with no need for ETL between the data and our business chat layer.
Nothing revolutionary, sure. But I have to admit I’m still getting used to the fact that we don’t need anyone developing analytical dashboards or designing sql queries for reports or investigations because you can just ask to get exactly the insights you want and everything gets done by AI, and this is just another step supporting that as the default desire path when building on databricks.
I'm sure as hell going to be using agents to analyze all data, but that doesn't help me understand what is going on with Databricks here, and focusing on "agentic" merely adds noise to that understanding.
> No performance tradeoffs, for any workload: Transactional workloads run in standard Postgres with full ACID semantics. Analytical workloads run across the full Lakehouse at any scale and concurrency. Each scales independently, and because there's no data movement between systems, operational and analytical results are always in sync — with no copies or shadow infrastructure.
How can there be no performance trade-off if storage is handled by PostGres and there is no data movement to convert it to columnar ? This deserve a technical explanation because this seems impossible.
Probably it's based on similar architecture as SAP HANA? With a main store and an in-memory delta store.
https://dl.acm.org/doi/10.1145/2213836.2213946
Curious how is the final format of the data in LTAP storage - is it columnar? If so then what happens to OLTP performance - the blog and all info speaks to OLAP performance but what about your app
Lakebase + Lakehouse = Lake
I want a lakehouse. Cant afford.
Warehouse for you
Hey I mean we've been using a fairly basic mssql box for years in a organisation of about 300 and it humms along nicely - granted we have 2 'materialised' aggregate tables/views (done in Python) but the TCO is tiny, and there is very little learning curve.
I'm warehousing since 2010s, need to buy appliances
Shein or temu?
No benchmarks, no pricing, no examples..
Exactly, like SAP HANA stores everything in memory, you get great analytical and transactional performance but good luck financing that at scale