> I think the generalizations around LMDB made by you and others are making this situation worse
Fair enough. For anyone else following, @jasonwatkinspdx is correct that LMDB is not the right (= best available today) choice for certain workloads. I personally used TrailDB for event traces and if I needed prefix compression on keys (like the CockroachDB team), RocksDB would be an arguably better choice.
What I don't agree with is that LMDB's existence or users are causing open source database research to stagnate. Quite the contrary, I think the benefits of LMDB's architecture have not yet been fully realized and I would love to see more research be done to improve/extend it.
Most of the research action today (at least to me) seems focused on making log-structure merge trees and variations thereof less sucky at the margin instead of identifying what makes LMDB's design actually tick and then improving on it. There's still a lot of low-hanging fruit in the LMDB architecture waiting to be explored.
Fair enough. For anyone else following, @jasonwatkinspdx is correct that LMDB is not the right (= best available today) choice for certain workloads. I personally used TrailDB for event traces and if I needed prefix compression on keys (like the CockroachDB team), RocksDB would be an arguably better choice.
What I don't agree with is that LMDB's existence or users are causing open source database research to stagnate. Quite the contrary, I think the benefits of LMDB's architecture have not yet been fully realized and I would love to see more research be done to improve/extend it.
Most of the research action today (at least to me) seems focused on making log-structure merge trees and variations thereof less sucky at the margin instead of identifying what makes LMDB's design actually tick and then improving on it. There's still a lot of low-hanging fruit in the LMDB architecture waiting to be explored.