I have prepared a preliminary changelog, too. This all has been a bit of work, you could say.

github.com/fjall-rs/fja...

I rewrote the entire write buffer, and journal backpressure system to be a more robust queue + messaging system. Also, now no more threads are started and stopped in the background on the fly. There is a single thread worker pool now (adjustable, at least 1), and that's it.

I didn't know what I was in for

And because less data is written to disk, it frees up availabe IOPS and increases SSD endurance.

With key-value separation, blobs are written at least twice (journal + blob file). So if a blob is compressible (let's say by 40%), we will still incur a write amp of 1.6x.

Journal compression uses more CPU, but because less data is transferred to OS and disk, it can actually be faster.

Yesterday or so I ran a benchmark over night, and v3 scales much better for extremely large (100+ GB) databases

Thanks 😭

Without having numbers (right now), LMDB will probably read absurdly fast, while not so much space- or write efficient.
Most, if not all data, fits into RAM here. Would be interesting to benchmark 100s of GBs.

But I found redb to be slower (sometimes much slower) than LMDB, pretty much always.

And here's another read-heavy bench with 4K values, 5% sync random updates and 95% Zipfian reads.

ReDB uses 4x more disk space, and writes 6x slower. Interestingly, it's also ~5x slower in point reads - I think ReDB is not handling large values well; haven't read too much into its implementation.

Synchronous writes (fsync) I might add

**slightly slower in reading

*bench tool

sled (bloodstone) is not in the bench too rn, because you can't compile it next to sled w/ compression; plus it's super unstable - in general I found it to be faster in writing, smaller on disk, but similar or slightly slower in writing than sled 0.x...

Hopefully I will have results in 6 hours 👀

Noo 🥲

I wanted to expand it to a 1-hour run but it crashed because of a bug in the workload (I think), in the middle of the night.