#lmdb — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #lmdb, aggregated by home.social.
-
Always interesting to read how other companies leveraged #OpenLDAP and #LMDB
https://www.linkedin.com/pulse/rehabilitating-lightwave-age-ai-krishna-ganugapati-trdhc -
When I first started floating the idea of putting #OpenLDAP's slapd config into an actual slapd database, most people resisted the idea. As a compromise, we created back-ldif: a tree of plaintext LDIF files that's managed as a hierarchical LDAP database. But nowadays it's commonplace for other apps to store their own configs in #LMDB. Funny how the world works sometimes. https://github.com/stagas/rtdiff/commit/a1104d9bfcdeb22a627f805254cabbe95bea0e55
-
Git in Postgres https://nesbitt.io/2026/02/26/git-in-postgres.html
It's interesting to me because it could probably be done more efficiently in #OpenLDAP. And there was a lot of work done to store git refs in #LMDB several years back, which ultimately never got merged. Using OpenLDAP also makes more sense for the federation usecase, since it has native replication, which is still a separate bolton for postgres.
-
I see the nano project finally wised up and is going to adopt the table the same table scheme #OpenLDAP and #Monero use with #LMDB https://xcancel.com/patrickluberus/status/2020380249952030768
-
Funny, nothing like this ever happened before Cloudflare switched from #LMDB to #RocksDB. Just sayin...
https://blog.cloudflare.com/introducing-quicksilver-configuration-distribution-at-internet-scale/
https://www.archynewsy.com/cloudflare-quicksilver-multi-level-caching-billions-of-requests/
-
Here's a take on #HNSW from the redis guy, antirez https://news.ycombinator.com/item?id=45887466
Seems like DiskANN on #LMDB already does better
-
#DiskANN and #HNSW (Hierarchical Navigable Small World graphs) appear to be trending again. First popped onto my radar 2 years ago, using #LMDB. https://xcancel.com/search?f=tweets&q=%23DiskANN&cursor=DAADDAABCgABGnlm6BXbcfcKAAIY9_luAhchywAIAAIAAAACCAADAAAAAAgABAAAAAAKAAUbmx1GGMAnEAoABhubHUYYv9jwAAA
A lot of the more recent noise seems to be on M$ infrastructure. For those with more money than brains...
-
Looks like Arweave is adopting #LMDB now? https://github.com/permaweb/HyperBEAM/pull/309/commits/dde0a79d52643fe043b40adfa81e0c7290a446a3
It's amusing to me to see them adopting this code now, since they were the first project to adopt #RandomX. Early to adopt my recent work, late to adopt my early work. Also interesting to see that they use #Erlang - I first tried to develop an erlang wrapper for LMDB years ago to use in #riak, but all of that was abandoned.
-
Low-Level Memory Management in Scalable Distributed Architectures:
Approaches to Improving Reliability and Performance of Digital
Services
Terletska KhrystynaLviv Polytechnic National University, 79013, Ukraine, Lviv
The study includes
practical examples from #RocksDB and #LMDB
https://ijrpr.com/uploads/V6ISSUE4/IJRPR42112.pdf -
SAE paper comparing #LMDB, #RocksDB, and #MongoDB. If automotive engineers are evaluating RocksDB or MongoDB, you should be afraid. Very afraid. https://saemobilus.sae.org/papers/comparative-analysis-rocksdb-lmdb-mongodb-a-performance-evaluation-2024-26-0331
-
@almibe they did a pretty good benchmark report too https://github.com/lmdbjava/benchmarks/blob/master/results/20160710/README.md
-
And this one, OMFG.
https://x.com/baotiao/status/1853889937063760316
"RocksDB has a more simple API. LMDB doesn't seem designed specifically as a KV storage engine"
This guy has absolutely no friggin idea what he's talking about. #LMDB is the most fundamentally distilled essence of a transactional KV storage engine. #RocksDB is a Rube Goldbergian Frankenstein's monster that even its authors admit they don't know how to tune or optimize correctly.
-
An amusing part - their benchmark results show that #LMDB trounces #RocksDB and #MongoDB in both read *and write* performance, yet they still write in their conclusion "RocksDB is optimized for high-performance operations, especially for write-intensive workloads, making it suitable for applications requiring fast data ingestion and low latency."
Completely ignoring their own data.
Have to wonder if an AI wrote this paper.
-
I didn't submit a talk to #Fosdem this year but will probably be attending. Ping me if you're interested in chatting about #LDAP, #OpenLDAP, #LMDB, #SymasCorp, #Monero, #RandomX, or whatever else comes to mind. #fosdem2024
-
If you're using #RocksDB instead of #LMDB in your project, you're probably Doing It Wrong.
Higher reliability, greater efficiency, lower write amplification with LMDB https://lobste.rs/s/vgfvfi/what_are_you_doing_this_week#c_d5d5sp