The idea seems like it should work but it is questionable what cases will it be better in. B+tree and LSM-tree are very developed and are kind of optimal. They

The idea seems like it should work but it is questionable what cases will it be better in. B+tree and LSM-tree are very developed and are kind of optimal. They are also fairly easy to beat for a given specific use case. I guess they have a concrete case that has benefitted from this design or this was an attempt at doing that. Would be interesting to read about that specific case they had. I just skimmed the paper, so I'm sorry if they explained it in the middle somewhere. Also I tried some other databases that claim to be better than rocksdb but it just is miles better than other databases when I needed large scale (couple billions of 32byte keys mapped to 8byte values). I tried MDBX(LMDB), sled (also claimed read AND write optimized). Tried sharding and all configuration options with both. Reading papers about database research unfortunately feels like reading LLM output because I have to sift through a lot of fluff, and I have to know exactly that the thing is about and the surrounding ideas. I am not super knowledgeable in this field so this might be just a skill issue, but I would recommend seeing it this way. This paper also writes about variable sized pages so it might be relevant to understanding what the trade-offs might be. https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf Also another thing I highly recommend is to always judge by hardware limits vs db measurement instead of looking at graphs in paper. If something is doing 1GB/s write on an ssd that can do 7GB/s than it is bad at writes. It doesn't matter if it looks cool on a graph. This is kind of a crude way of seeing it but it is at least reliable.