Its kind of strange, because both Postgres and MSSql have long had OLAP columnstore on top of OLTP (and OLTP indexing on columnstore), and it seems a lot of what people are trying to achieve in Delta Lake, etc is the same thing, starting with OLAP/Parquet.
I am not entirely sure I'm reading this correctly, but I am imagining it is a single way sync back from your lakehouse to a postgres, so a managed postgres instance, with serverless compute and... management-lite reverse-etl? Is that basically it?
This world still tends to treat auditable change data as either of 2 things : archaic data Lake function or a product problem based on need.
Even here (without having read into the lakebase enough yet - take my opinion with a grain of salt) I feel like an oltp sync to Delta will rely on Delta versioning for audit (and it never lives forever) instead of baking it in as type-2 managed change data!
How does it compare to foreign catalog feature?
Its kind of strange, because both Postgres and MSSql have long had OLAP columnstore on top of OLTP (and OLTP indexing on columnstore), and it seems a lot of what people are trying to achieve in Delta Lake, etc is the same thing, starting with OLAP/Parquet.
I am not entirely sure I'm reading this correctly, but I am imagining it is a single way sync back from your lakehouse to a postgres, so a managed postgres instance, with serverless compute and... management-lite reverse-etl? Is that basically it?
This world still tends to treat auditable change data as either of 2 things : archaic data Lake function or a product problem based on need.
Even here (without having read into the lakebase enough yet - take my opinion with a grain of salt) I feel like an oltp sync to Delta will rely on Delta versioning for audit (and it never lives forever) instead of baking it in as type-2 managed change data!
What do you think?