Lars Madsen: ok 
Thanks for taking the time to explain it
Andy Rusterholz: Sorry to keep this thread going – just a few things I’m still not grasping here:
> Furthermore, to avoid doing too much I/O, it will try to batch the memtables, waiting for a minimum of them it can merge into a single SST file.
I’m unclear on why there is a minimum here or why there is any concern about Zeebe doing “too much I/O,” especially if it is asynchronous. I would much prefer for Zeebe to aggressively flush to disk, both for lower memory usage and for greater consistency/reliability (if a broker process falls over and we are restarting it based on the data on disk).
> flushing with small memtables may happen when taking snapshots, further fragmenting your LSM into multiple files. Then on opening the DB, it will replay the WAL and since you’re not doing much will probably flush this as well, causing further fragmentation.
Why does having smaller memtables or buffers (or having less load) require more files on disk? This is totally counterintuitive to me. Does RocksDB require one SST file per memtable? I would think that having lower load would result in fewer entries appended to the WAL and therefore give Rocks a GREATER ability to compact files and remove unused SST files.
Either way we will eagerly await the release of the work under #4002. Do you know if that is slated for 0.27, or if not, what version can we expect that in?