По ряду причин BDB "померла" лет 10 назад, а лет 5 назад закончились обсуждения этого факта в профессиональных кругах.
Сразу отмечу, что под "померла" тут понимается __только__ нулевая вероятность выбора BDB в качестве движка хранения в новых проектах, где есть возможность такого выбора.--
Причин "смерти" BerkeleyDB примерно две или четыре:
1. BDB стала ненужной, ибо лучшее враг хорошего.
1а. Техника стала мощнее, и памяти стало сильно больше.
Поэтому 99% проектов стали предпочитать SQL (включая sqlite), а не заморачиваться с key-value.
1б. Среди оставшихся, 0.99% проектов, где noSQL действительно нужен (из-за специфических требований или ограничений), искали и __находили__ что-то более подходящее: удобное, быстрое, надежное, простое и т.д.
2. Смена лицензирования.
2а. Многие существующие проекты вынуждены были отказаться от BDB, так как были поставлены перед выбором: либо оставаться на неподдерживаемой версии, либо переходить на AGPL, либо покупать лицензию.
2б. Во многих новых проектах принципиально не хотели мириться с ограничениями от Oracle, особенно при доступности кучи альтернатив.
В сухом остатке, на DBD остались только какие-то legacy-проекты и домашние/персональные проекты разработчиков привыкших к BDB, ну или кому книжка по BDB попалась...
--
При этом, несомненно, BDB является большой вехой в "истории индустрии" и существующие версии могут просто работать.
Тем не менее, меряться тут чем-то с BDB достаточно абсурдно:
- это специфический legacy комбайн, разработка которого остановлена, а поддержка только платная.
- для всех сценариев использования можно найти альтернативы, которые будут лучше по тем или иным критериям.
- в целевых для libmdbx сценариях у BDB нет шансов, одновременно у BDB есть фичи/возможности которых точно нет (и не будет) в libmdbx, т.е. тут вопрос __выбора__ инструмента отвертка/молоток, а не их сравнения.
