The Architecture of Open Source Applications (Volume 1) Berkeley DB (aosabook.org)

I wanted to love berkeley db; it was available everywhere, seemed simple, was fast when tested. In practice it never worked well though, with pretty frequent corruption under load, and license confusion from oracle. It has a lot of features you're never going to use, and if you try, you'll be disappointed

There's no shortage of embeddable key-value stores with C bindings like leveldb, rocksdb, or even gdbm, and all of them have worked better for me.

Many years ago I was obsessed with Berkeley DB and its performance.

But when I discovered Tokyo Cabinet and Tokyo Tyrant I almost literally fell in love. We used it for things that would have been impossible without it at the time.

Still worth checking it out: https://github.com/hthetiot/Tokyo-Cabinet

Berkeley DB is one of those things everyone respected, for some reason, but that didn't actually work if you threw a bit of data at it. And not just for us. I remember talking to companies that paid them lots of money to work on reliability, and it never got better.

But I do remember reading much of the source (trying to figure out why it didn't work) and thinking "this is pretty nice code".

Loved this chapter, great design, well written.

I love the aosa book. I learned a lot about systems design from it. Ironically, I usually fail the Systems Design interviews at fancy companies because they only ask about LBs, sharding, obscure data structures like CRDTs, and what not.

Back in 2003, implemented a Win32 profiler using Berkeley DB for offline indexing and visualizing profiler data.

https://github.com/mechanicker/cramp

Later in ~2011, used BDB for indexing filesystem metadata at a large storage vendor for enhancing data management in a storage cluster.

Clean API with language bindings makes it easy to integrate with different languages.

The db that was the cause of redhat rpm db corrupting itself