FeedDiscussion
B-Trees remain compelling for applications that need frequent point reads and ordered range queries. Their update path may be less write-friendly, but predictable lookup behavior can be more valuable than maximizing raw ingestion throughput.
Bloom filters are an interesting part of the LSM design. They can avoid many unnecessary table lookups, but they also introduce memory costs and false positives. Choosing the right filter size becomes another workload-dependent trade-off.
Compaction is the part of LSM-Trees that deserves special attention. Fast writes can look ideal in a benchmark, but write amplification, temporary disk usage, and latency spikes during compaction can change the production picture significantly.
The most useful takeaway is that neither structure is universally better. B-Trees often provide predictable reads and range scans, while LSM-Trees trade additional read and compaction work for efficient sequential writes. The workload should drive the choice.
haleo
A useful follow-up would be a benchmark comparing the two approaches under mixed workloads rather than pure reads or writes. Read/write ratios, key distribution, cache size, compaction strategy, and storage hardware can all change the result.