2025 retrospective, 1/365
Nah, just kidding.
Howard Chu @ Symas
Howard Chu @ Symas
npub1tt4j...x9ud
CTO Symas Corp., Chief Architect OpenLDAP Project, Musician
Sometimes it's embarrassing to see the kind of inane things people build on top of #LMDB https://xcancel.com/NathanAMeeks/status/2001643709025460531
But it's just a tool, it's neutral. Good or evil comes from who is using it...
From trees to graphs: speeding up vector search 10x with Hannoy - on #LMDB
From trees to graphs: speeding up vector search 10x with Hannoy
This is a walkthrough of a new LMDB-based HNSW Rust vector store with drastically better performances than the previous random-projection-based one...
This was a trivial enhancement that should have been committed a while ago: adding support for 2-phase commit to #LMDB 
It's another feature that BerkeleyDB has had for a long time, used to implement distributed transactions. Of course BerkeleyDB has full blown distributed access support, and its own Tuxedo-compatible distributed transaction manager. LMDB remains single-node only; the calling app will have to deal with actual distributed processing.
GitLab
ITS#9224 lmdb: add support for PREPARE/2-phase commit (!811) · Merge requests · openldap / OpenLDAP · GitLab
Welcome to the OpenLDAP Gitlab instance
Got a set of stainless steel chopsticks from AliExpress. They're great, nothing sticks to them, just a quick rinse and they're clean.
"But wait" you say, "nothing sticks to them? Doesn't that make them harder to use?"
Well actually, they have textured tips, so they're not too slippery.
But... yeah, as soon as they're coated with gravy or any liquids, all bets are off.
VarveDB
A high-performance, embedded, append-only event store for #Rust.
VarveDB provides a persistent, ACID-compliant event log optimized for high-throughput event sourcing. It leverages #LMDB for reliable storage and rkyv for zero-copy deserialization, ensuring minimal overhead.
Lib.rs
varvedb
A high-performance, embedded, append-only event store for Rust
Hm, this comment from 88 days ago is showing in my google alert as 2 days old. Google is srsly messed up.
https://news.ycombinator.com/item?id=45101592
But as to the question: #LMDB doesn't store counts of child nodes in each parent page. Doing so would certainly allow for setting a cursor directly to an Nth record, and redhat even submitted a ticket requesting this feature but it didn't seem important enough at the time, and seemed like too much storage cost for a rarely used function.
