B-trees (especially Copy on Write B-trees) tend to be limited by the disk seek performance. The write performance of a virgin B-tree will also vary substantiall

B-trees (especially Copy on Write B-trees) tend to be limited by the disk seek performance. The write performance of a virgin B-tree will also vary substantially depending on the keys that are being inserted. Random keys will lead to a lot of splitting of the tree which can be slow as it requires a lot of locking and allocation. Sequential keys will amortise the expensive part of building the structure of the tree. This test uses a 10GB test size which is very small compared to the size of RAM available for the page cache. This will hide the seek penalties that the B-Tree takes on reads. Over a much larger test one would expect the write performance of a well written LSM to flatten out to a constant, indefinitely sustainable, rate. A (COW) B-tree would be expected to gradually degrade over time as it gets more fragmented and takes more seek penalties for writes and range reads. The seek penalty is relevant for SSDs as there are still only a finite number available: you can expect on the order of 100K/s rather than the 100/s you might expect from a conventional disk. You still want to be mostly operating those things in streaming read mode where possible.