Hacker News Reader

It's really just a matter of tradeoffs. B-trees are great, but are better suited for high read % and medium/low write volume. In the opposite case, things like LSMs are typically better suited.

If you want a comprehensive resource, I'd recommend reading either Designing Data Intensive Applications (Kleppman) or Database Internals (Petrov). Both have chapters on B-trees and LSMs.

If your application is write intensive LSM is better than Btree.

But you'd rarely need it. We mostly have write intensive counters. We just write to redis first then aggregate and write to postgres.

This reduces number of writes we need in postgres a lot

See my comment in the main thread for an example. In a worst case scenario, some data is simply too "frizzy" to index/search efficiently and with good performance in a B-tree.

For pure write throughput, LSM trees tend to beat btrees.

+1