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".
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.
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.
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.
Loved this chapter, great design, well written.
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