> До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.Исторически прародитель обсуждаемой "СУБД" создавался для замены BerkeleyDB, в частности из-за неустраняемых проблем в BerkeleyDB с взаимными блокировками и багами в кешировании (могут читаться старые данные и т.д.). Результат получился не только стабильнее, но и существенно быстрее BerkeleyDB. Поэтому многие проекты давно приняли решение об уходе с BerkeleyDB, для примера см абзац в википедии https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berke.... Поэтому вопрос "дорасти до BerkeleyDB" давно не стоит.
По поводу отношения к "СУБД" - ваше мнение сильно не совпадает с терминологией принятой в индустрии, см определение что такое "Встраиваемая база данных" в википедии https://ru.wikipedia.org/wiki/%D0%92%D1%.... Собственно вы вправе иметь любое мнение, но если оно противоречит принятой терминологии, то лучше это как-то обозначать (а то можно подумать что вы не владеете терминологией).
Вторичные индексы, в классическом понимании, требуют некоторого подобия колонок/ячеек, т.е. хранения значений в виде кортежей, с соответствующими ограничениями в виде определяемой схемы.
Таким образом, классических "вторичных индексов" не может быть в классическом key-value, так как value непрозрачно с точки зрения БД и там нечего индексировать. Это ни хорошо и не плохо - просто добавление схемы и вторичных индексов означает отказа от присущих key-value простоты и минимализма.
Тем не менее, дополнительные "пользовательские/вторичные" индексы реализуются "поверх" key-value очень просто. Настолько просто, что использование "движка" key-value де-факто подразумевает использование дополнительных индексов по-необходимости. Поэтому отсылка ко вторичным индексам, на самом деле, обесценивает ваше мнение ибо выдаёт отсутствия опыта разработки с использованием СУБД класса key-value.
Курсоров и транзакций во многих СУБД действительно нет, в частности во многих движках основанных на LSM. Но определяется это целью создания этих СУБД и ограничениями (эффективностью) вследствие внутреннего устройства, а не какими-либо критериями полноты API или критериям соответствия теримину "СУБД".
Кстати, в MDBX есть и курсоры с предельно эффективными операциями поиска и переходов, и ACID-транзакции. А вторичные индексы в явном виде есть в libfpta - это "табличная" СУБД основанная на libmdbx.
