BerkleyDB is now AGPL3[0], which some projects have a problem with. (Of course, you can buy a commercial license. Some projects have a problem with that too).
But the main reason, almost regardless of context, as to "why not BerkleyDB" is LMDB[1]. It works way better than everything else, in just about every practical use that has more reads than writes.
The only downside as far as I can tell, is that right now it relies on memory mapping the entire database, so you're limited to ~1GB overall database size on 32 bit systems. There is no practical limit on 64 bit systems. Also, I recall Howard Chu (main LMDB developer) mentioned that in the near future LMDB will gain the ability to manage memory manually - thus removing this restriction as well (for a performance price if used this way).
It still needs heavier testing before going to mainline. I expect it will only ever be a compile-time option. On 64bit it's pointless, and 32bit is going the way of the dodo.
BerkleyDB is now AGPL3[0], which some projects have a problem with. (Of course, you can buy a commercial license. Some projects have a problem with that too).
But the main reason, almost regardless of context, as to "why not BerkleyDB" is LMDB[1]. It works way better than everything else, in just about every practical use that has more reads than writes.
The only downside as far as I can tell, is that right now it relies on memory mapping the entire database, so you're limited to ~1GB overall database size on 32 bit systems. There is no practical limit on 64 bit systems. Also, I recall Howard Chu (main LMDB developer) mentioned that in the near future LMDB will gain the ability to manage memory manually - thus removing this restriction as well (for a performance price if used this way).
[0] http://www.oracle.com/technetwork/database/database-technolo...
[1] http://symas.com/mdb/