Their benchmarks show significant gains compared to RocksDB.
> https://github.com/spdk/rocksdb
But what I'd really like to see is a comparison against RocksDB using SPDK
> https://dqtibwqq6s6ux.cloudfront.net/download/papers/Hitachi... Based on these results, SPDK performs significantly better than the kernel requiring only 1-2 cores to saturate IOPS on an NVMe SSD (compared to the kernel requiring 16)
First, the IO threads in RocksDB are a thread pool that assume they perform blocking operations. That doesn't jive with SPDK's async model (nor io_uring's). We're having to message pass to an async thread and block on semaphores in the IO threads.
Second, RocksDB was heavily reliant on the kernel page cache to make it fast.
Both of these things could have changed since we last worked on the integration. I haven't kept up with RocksDB development recently.
source: am SPDK maintainer
Is there a maintained version of SPDK RocksDB? Or SPDK any DB?
[0] https://news.ycombinator.com/item?id=10511960
[1] https://news.ycombinator.com/item?id=22266503
However, there's still lots of reasons to use SPDK. Performance is still significantly better[0], and you can directly access all the of the NVMe features on the device without going through any abstraction layers.
The potential of using io_uring with eBPF in Linux will makes any HPC enthusiast drooling :-)