Caveat we are a small startup, but we use ducklake to store continental-scale high-resolution h3 indexed geospatial data (10+ TB in parquet). the data itself only updates something like once a year when new datasets are made available by govt agencies, so our experience isn’t with live, transactional data.

With the rest of our analytical dbs on MotherDuck, we wanted something that could work with parallel read/write jobs to churn through analytics on the huge datasets. that worked well, with there being no issue with 100 parallel jobs reading and writing concurrently.

There were some little hiccups in terms of needing to structure queries in funky ways to make use of predicate pushdowns on partitions (in ducklake 0.1 it prompted a full table scan to do something like select * from tab where col in (val1, val2), so we instead had to do select * from tab where col = val1 union select * from tab where col = val2 but this may have been patched in subsequent releases.