Berkeley DB is an embedded database with no network story, let alone distributed story, so it isn't really a complete solution compared to the k-v stores people talk about. It can be a building block though, e.g. memcachedb uses it.
ASN.1 is hideously complex, part of the appeal of all those new wire protocols is simplicity.
SQLite is Berkeley DB's main competitor... it's actually funny that NoSQL on the server is all the rage, but SQL use is now really popular client side.
> Berkeley DB is an embedded database with no network story, let alone distributed story
True, true and not really. It can be easily distributed - replication works great with them. Yes, it's not good for everything, but it's great for example for simple web api servers. Skip the connections if you don't really need it and write/read k-vs at a ridiculous speed locally.
> ASN.1 is hideously complex
Yeah... I guess this is more of a personal preference, but I never found it that bad. Write a wrapper that can (de)serialise your native objects once and you don't have the problem anymore.
ASN.1 is hideously complex, part of the appeal of all those new wire protocols is simplicity.
SQLite is Berkeley DB's main competitor... it's actually funny that NoSQL on the server is all the rage, but SQL use is now really popular client side.