Смотря что подразумевать под этим "как".

Согласно википедии (https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berkeley_DB) последнее время наблюдается массовый переход с Berkeley DB на LMDB, поскольку второе меньше глючит и работает быстрее. Ну и плюс изменение лицензии.

За вычетом лицензии, наверное, главная проблема Berkeley DB в кешировании: большие накладные расходы, глюки и деадлоки - всё с момента появления этого кеширования.

Тем не менее, в Berkeley DB есть немало фичей отсутствующих в LMDB (тут не добавляли не затребованного). Эти фичи кому-то могут быть крайне важны, но одновременно превращают Berkeley DB в монструозный легасу-комбайн.

---

Ну и соответственно MDBX - это "улучшенная" LMDB. Но важно что кроме "улучшений" в libmdbx устранено достаточно багов (пример проявления https://github.com/ledgerwatch/turbo-geth/issues/1473).

Это разные движки, с принципиально различным внутренним устройством, т.е. теплое и мягкое.

> Понятно что leveldb не самая надёжная и устойчивая к поврежденями, кроме того у неё значительные футпринт и оверзхэд в рантайме, но помимо этого?

Дедушку levedb конечно пора отпустить, если только нет противопоказаний (например) от RocksDB.

Если же сравнивать MDBX (b+tree и ACID поверх MVCC за счет page shadowing) и RocksDB (LSM tree с "бантиками"), то минусы каждого из движков могут с запасом перекрыть плюсы в зависимости от сценариев и условий использования.
Т.е. если вам нужен "утюг", то подойдет одно, а если "подушка" - то другое.

При этом, для желающего понять как внутреннее устройство MDBX и RocksDB, так и для каких сценариев использования они (не)подходят - в Сети полно информации.

> А то lmdb что-то совсем никуда не годится.

ТТХ и поведение LMDB отлично соответствует целевым сценарием использования этого движка.

Поэтому оно очень даже годится с двумя оговорками:
1) в LMDB ребусный стиль кодирования, (как следствие) высокий порог вхождения и относительно малое кол-во людей готовых что-либо поправить с SLA.
= в MDBX это осталось, ибо иначе нужно "переписать".

2) в LMDB отсутствуют полноценные тесты и средства проверки целостности БД, (как следствие) баги приводящие к повреждению БД и/или потерям данных
= в MDBX это полностью устранено.

Не знакомы с иньективными отображениями и примитивами/миксерами хеш-функций?

Но я подскажу вам где действительно стоит критиковать - см. код функции mdbx_update_gc().
Это действительно то, что Howard Chu не стал осиливать ;)

А если "понравится", то начните с https://github.com/LMDB/lmdb/tree/mdb.master/libraries/liblmdb/mdb.c

Если данные помещаются в ОЗУ и чтения существенно больше чем записи, то MDBX может быть очень неплохим вариантом:
- чтения будут неблокируемыми, OlogN и со скоростью доступа в память, и на каждом ядре CPU.
- редкие пишущие транзакции можно делать no-sync и сбрасывать на диск асинхронно (вызывая mdbx_env_sync из отдельного треда).

RocksDB также стоит примерить, особенно если какая-либо фича может вам помочь (например фильтр Блума).

Но в целом может подойти очень многое и надо внимательно смотреть на все остальные аспекты.

Одобрямс. Надо лицензию придумать чтоб копрорации не имели право использовать код, есть идеи ?

Не понял что вы хотели сказать.
В код кому-то гадить крайне сложно, нужны явные разрешения и некое понимание кода.

Ну и никакой особой разработки на github нет, это просто удобная и общеизвестная площадка, которая используется для:
- раздачи кода.
- взаимодействия с пользователями библиотеки и накопления "ачивок" (гитхабовых звездочек).
- прогона CI-тестов на условиях "для open source".

А после блокировки Крыма основным репо считается https://abf.io/erthink/libmdbx, о чем добавлены примечания.

Есть еще и "t1ha", так что лучше не пейте (тем более стаканами).

API существенно расширено и в паре мест принципиально изменено (время жизни и требования явно закрывать курсоры, время жизни DBI хендлов).
Но всё такие изменения (включая причины) описаны в доке.

Поэтому биндинги на 95% получаются путем замены префиксов.

Кроме этого, в README есть ссылки на существующие привязки. Там есть и для Явы, хотя порядком протухшие.
Есть от чего оттолкнуться.

Насколько мне известно, там не переход, а добавление еще одного драйвера хранения.

Тем не менее, история такая:

1.
До каких-то последних версий (если не ошибаюсь, в январе этого 2021 года) libmdbx внутри Miranda NG использовалась некорректно, из-за чего пользователи теряли данные.
Пользователи считали что причина проблем в MDBX, ругались и активно просили добавить еще один драйвер хранения.

Суть проблемы была в том, что БД явно и намеренно открывалась в небезопасном режиме (без гарантий сохранности данных при системном сбое, выключении питания и т.п).
Это неоднократно было пояснено разработчикам, но они считали что риски мизерны и долго не могли сподвигнуться на переделку своего кода.

Следы этих обсуждений и моих пояснений/комментариев есть как в https://github.com/miranda-ng/miranda-ng/issues, так и на форуме Miranda NG http://forum.ru-board.com/topic.cgi?forum=5&topic=34402

2.
Примерно за год до этого (до февраля 2020 года), в драйвере Miranda NG были какие-то баги, из-за которых в БД записывались неверные данные.
Подробностей я не помню, но они есть в истории коммитов Miranda NG и в issues проекта на github.

3.
Еще примерно за год до этого (до февраля 2019 года) было две неприятности именно в libmdbx:

- Из-за моей оплошности в миранду (и далее к пользователям) исходно попала "девелоперская" версия, которая намерено делалась несовместимой по формату БД с релизами (чтобы в production не попадали экспериментальные фичи).
Эту проблему огораживали как могли, но пользователей она конечно злила.

- Был обнаружен и устранен унаследованный из LMDB баг, который мог приводить к повреждению БД.
Возможно этот баг также затронул пользователей миранды, но субъективно проблемы были от описанного выше.

--

В libmdbx при этом много чего было сделано для лучшей поддержки Windows, включая даже поддержку Windows 2000/XP и работу под Wine.

- изначально хотели таки на SQLite, но не было идей, как сделать его достаточно быстрым для нужд Миранды. Поэтому, взяли то, что было уже быстрым, а потом за годы неспеша реализовали поддержку курсоров и, в целом, достаточно ускорили работу SQLite.

- под SQLite есть тонна внешних утилит для работы с базами, пользователи это очень хотят