Couple of corrections:
* LadybugDB has revamped the Kuzu WAL design. It shouldn't be hard to build WAL based replication
* 19ms vs 39us - like the author says these are vastly different systems and the benchmark methodology may not be comparable.
We've mostly focused on query plan optimizations, not so much the micro query operator optimizations.
The 0.20.x end of the month release should have some interesting optimizations.
* Prepared statements will cache query plans and result vectors. So you don't pay malloc costs
* SIMD optimizations for filter. More to come in the next release.For those into the `pip install ...` flow and kuzu, is gfql: we started around the same time in a non-VC-funded oss manner with overlap in key architectural ideas:
- cpu columnar vectorized engine + optionally the only open source gpu engine mode for bigger graphs / faster queries
- removes the need for a database / file: pure compute-tier engine you can write to parquet/json if you want, plays with parallel reader/writers in simple ways b/c that, and TBD iceberg
- adds full graph analytic pipeline support, eg, for feature engineering in real-time fraud & memory pipelines
- also millisecond/submillisecond times on small graphs like that small 100K edge graph benchmark
Main box not formally checked is streaming. Funny enough, we're designed for GPU firehose workloads, so would be fun to demo and see what gaps are left.