Rendered at 13:48:58 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
epistasis 18 hours ago [-]
> 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.
klustregrif 8 hours ago [-]
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.
mathisd 2 hours ago [-]
> 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.
saxenaabhi 2 hours ago [-]
Probably it's based on similar architecture as SAP HANA? With a main store and an in-memory delta store.
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
geophph 17 hours ago [-]
Lakebase + Lakehouse = Lake
debarshri 17 hours ago [-]
I want a lakehouse. Cant afford.
geophph 17 hours ago [-]
Warehouse for you
Incipient 13 hours ago [-]
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.
debarshri 16 hours ago [-]
I'm warehousing since 2010s, need to buy appliances
debarshri 16 hours ago [-]
Shein or temu?
drchaim 17 hours ago [-]
No benchmarks, no pricing, no examples..
zurfer 17 hours ago [-]
Exactly, like SAP HANA stores everything in memory, you get great analytical and transactional performance but good luck financing that at scale
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.
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.
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.
https://dl.acm.org/doi/10.1145/2213836.2213946