I still don’t see how this is different from iceberg? You don’t need a catalog to use it, atomic replace of metadata.json plus deletion vectors seems to be exactly the same thing.
I know Iceberg has this same issue, but you state deletion in this way (recording tombstones) is sufficient for GDPR compliance - but is it really? The 'deleted' data is still trivially readable.
I still don’t see how this is different from iceberg? You don’t need a catalog to use it, atomic replace of metadata.json plus deletion vectors seems to be exactly the same thing.
S3 is a HTTP API, does it mean that this database would be very slow? Especially if they use immutability and create copies of large files?
Yeah, it mentions in few areas - compared to OLTP or similar workloads, this will definitely be slow
The sequence diagram seems to have a mistake, the second writer somehow seems to know to create v124, only having observed v122.
Fun fact -- try to search for "124" there.
For some reason they thought hard-positioned top-to-bottom SVG is somehow better than adding "white-space: pre" once in CSS ¯\_(ツ)_/¯
Thanks! looks like i messed up some css on my last frontend refresh a bit.
Wow fast, now it's much better!
given that it’s parquet, deletes are nice, but what about inserts?
I know Iceberg has this same issue, but you state deletion in this way (recording tombstones) is sufficient for GDPR compliance - but is it really? The 'deleted' data is still trivially readable.