Не буду пользоваться, пока так не сделаете. :-D

Windows(TM) в такие имена не может?

  CC           =cc
  CFLAGS_EXTRA =
  CFLAGS       =-std=gnu11 -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributes
  CXX          =g++
  CXXSTD       =-std=gnu++2a
  CXXFLAGS     =-std=gnu++2a -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributes

  LD           =ld
  LDFLAGS      =-Wl,--gc-sections,-z,relro,-O1
  EXE_LDFLAGS  =-pthread
  LIBS         = -lrt

  MDBX_BUILD_OPTIONS =-DNDEBUG=1

## Assortment items for MDBX_BUILD_OPTIONS:
##   Note that the defaults should already be correct for most platforms;
##   you should not need to change any of these. Read their descriptions
##   in README and source code (see src/options.h) if you do.
  MDBX_DISABLE_GNU_SOURCE
  MDBX_OSX_SPEED_INSTEADOF_DURABILITY
  MDBX_ENV_CHECKPID
  MDBX_TXN_CHECKOWNER
  MDBX_TRUST_RTC
  MDBX_ENABLE_REFUND
  MDBX_ENABLE_PGOP_STAT
  MDBX_ENABLE_MADVISE
  MDBX_DISABLE_PAGECHECKS
  MDBX_PNL_PREALLOC_FOR_RADIXSORT
  MDBX_DPL_PREALLOC_FOR_RADIXSORT
  MDBX_WITHOUT_MSVC_CRT
  MDBX_ENVCOPY_WRITEBUF
  MDBX_FORCE_ASSERTIONS
  MDBX_ASSUME_MALLOC_OVERHEAD
  MDBX_DEBUG
  MDBX_USE_VALGRIND
  MDBX_HAVE_C11ATOMICS
  MDBX_LOCKING
  MDBX_USE_OFDLOCKS
  MDBX_USE_SENDFILE
  MDBX_USE_COPYFILERANGE
  MDBX_USE_SYNCFILERANGE
  MDBX_CPU_WRITEBACK_INCOHERENT
  MDBX_MMAP_INCOHERENT_FILE_WRITE
  MDBX_MMAP_INCOHERENT_CPU_CACHE
  MDBX_64BIT_ATOMIC
  MDBX_64BIT_CAS
  MDBX_UNALIGNED_OK
  MDBX_CACHELINE_SIZE

ardb умеет использовать LMDB.
Скорее всего, после небольшой доработки mdbx тоже сумеет.

Потом (вроде-бы) по мотивам этого PoC сделали https://github.com/LumoSQL/lumosql.
Сам не пробовал, но теоретически оно рабочее и за пару дней можно пересадить с LMDB на MDBX.

Еще есть https://github.com/PositiveTechnologies/libfpta с табличками, колонками, индексами..., но без SQL.

RocksDB - это ДЫЬ (https://ru.wikipedia.org/wiki/LSM-%D0%B4%D0%B5%D1 с дополнительними читами и фичами.

MDBX - это B+Tree (https://ru.wikipedia.org/wiki/B%E2%81%BA-%D0%B4% со своими читами и фичами.
Отличий как в плюс, так и в минус, очень много чтобы писать здесь, но в Сети есть масса информации.
Можете начать с https://github.com/erthink/libmdbx#comparison-with-other-databases и https://www.opennet.dev/openforum/vsluhforumID3/121987.html#43

> Можно ли использовать как storage backend для SQL или Object базы данных?

Да можно, если что-то "прикрутить", см https://www.opennet.dev/openforum/vsluhforumID3/124185.html#15

Если вычесть ожидание дисковых операций (например запустить в /dev/shm или на RAM-диске), то MDBX/LMDB как-правило оказываются быстрее, ибо
- OlogN от b+tree;
- очень мало лишних действий (оверхеда);
- zerocopy и неблокируемое чтение с масштабированием по ядрам.

С учетом дисковых операций всё в них родимых и упирается. При этом у MDBX/LMDB амплификация записи в точности равна высоте дерева, т.е. тоже OlogN.

Соответственно, принципиальных изменений в бенчмарках нет, так как не меняются эти слагаемые и их пропорции.

Во-первых, на всякий (чтобы не упрекали в читерстве): 20-30% получается если оценивать скорость работы самих движков (без учета дисков) и отключить в MDBX дополнительный контроль (корректности операций и данных в БД).

В новых версиях нет ничего, чтобы позволяло LMDB становиться быстрее.
Буквально там примерно следующее:
- поддержка чтения больших БД на 32-битных системах (MDB_VL32), что существенно замедляет движок, так как требуете поддерживать кеш "окон отображения" файла БД в ОЗУ.
- поддержка шифрования, что требует дополнительных затрат на поддержку кеша прочитанных/расшифрованных страниц БД.
- добавление txn_id в заголовок страниц для определения их "грязного" статуса, но в MDBX txn_id был добавлен давным-давно.

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

80% ответа есть в https://github.com/spacejam/sled?#known-issues-warnings

Остальные 20% примерно такие:

1) В сценариях с интенсивным чтением превосходство будет у MDBX, ибо оверхеда и блокировок примерно 0.

2) В MDBX нет WAL - это принципиальный осознанный архитектурный выбор (унаследованный от LMDB) со своими минусами и плюсами.
Поэтому MDBX будет ожидаемо проигрывать в одних сценариях  и выигрывать в других.
Соответственно, вопрос тут не в том "кто круче/быстрее", а насколько некий (условно ваш) сценарий использования соответствует свойствам/назначению того или иного движка.

3) Авторы sled пускаются во все тяжкие с lockfree, rw-локами и atomic-операциями ради более-менее параллельного выполнения читающих и пишущих транзакций..., и всё это поверх смеси b-tree с lsm, приправленное массой дополнительных фишек и фичей.
Теоретически такое можно отладить, довести до production стабильность и производительность.
На практике же буду баги, время воспроизведения которых в разы больше времени жизни соответствующей версии кода.

Другими словами, sled = концептуально интересно и действительно может дать существенный "выхлоп", но есть существенные риски что проект никогда не дойдет до production-готовности (см https://github.com/spacejam/sled/issues).

RTFM https://github.com/erthink/libmdbx/blob/master/README.md#libmdbx

- в 1-ов пункте: "Allows a swarm of multi-threaded processes to ACIDly read and update several key-value maps and multimaps in a locally-shared database.", т.е. с много-процессностью всё также хорошо как и с много-поточностью.

- в 5-ом пункте: "Enforces serializability for writers... affords wait-free for parallel readers without atomic/interlocked operations, while writing and reading transactions do not block each other", т.е. все пишущие транзакции выполняются строго последовательно, а читающие не блокируются.

Курсоры есть, а вторичных ключей в key-value не бывает (для этого есть https://github.com/erthink/libfpta).

Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".

> Так что вангую, что с GH вас рано или поздно выкинут,
> а вместо врнды придётся довольствоваться реактосью. В прочем это к лучшему,
> наконец-то реактось до юзабельного состояния допилят.

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

;)

Юрий там очень хорошо всё рассказал.