Собственно сейчас данные лежат просто в json-файлах в папке рядом с приложением. Это как минимум ненадёжно и тяжело поддерживать.
Хочется перевести хранение в какую-нибудь embedded базу и заодно может кто подскажет получше способ хранения данных.

Данные можно представить в виде дерева.
Допустим, это город, у него есть улицы, у улиц дома, у домов помещения.

Набор хранимых данных у всех городов/улиц/... здесь и сейчас одинаков, но периодически туда что-то добавляется и/или удаляется.
Не требуется такого, что вот у этого города хранится численность населения, а у этого - нет. Устроит, что любой атрибут есть у всех или ни у кого.

Каких-то сложных выборок не нужно. Только из серии: получить список городов, для города получить список улиц и т.д.
Часть данных достаточно постоянны и некоторые из них нужны отдельно от остальных. Большинство же информации получается всегда вместе и периодически меняется набор данных.
Например, должна быть возможность получить наименование города без загрузки всей информации о нём. В то же время ничего отдельно не нужно о помещении, можно его в базе хранить единым куском. Через месяц может захотеться хранить текущую численность населения города, а еще через месяц - численность населения по годам.

Пока в мыслях схема таблиц грубо такая:
Город (ИД, Наименование, Данные)
Улица (ИД, Наименование, ГородИД, Данные)
Дом (ИД, УлицаИД, Данные)

Данные - либо какая-нибудь BLOB/текстовая колонка для хранения того же json со всем подряд, либо ИД в отдельной таблице для всех таких данных.
Пока для помещений никаких выборок не нужно, поэтому они могут единым куском лежать в данных дома. Если потребуется, то в БД добавится еще одна таблица для помещений. Соответственно численность населения города лежит в данных города, но если понадобится какой-то отбор по ней, то нужно будет добавить колонку и в программе обновить схему с переносом данных в неё.
Добавление/удаление колонок и таблиц - это что-то сильно редкое и не факт, что вообще понадобится, но нужно предусмотреть. основная же часть периодически переделывается. Где-то типы данных меняются (например, было дробное значение в километрах, а стало целое в метрах), где-то типа как с населением - было одно значение, а стала коллекция по годам и т.п.

Вроде под такую вещь должно хорошо подойти что-то из nosql, но нашёл только LiteDB, который вроде как не очень известен и непонятно что там с надёжностью и т.п.
Пока ковыряю SQLite, т.к. в принципе альтернатив из-за требования embedded не вижу, но может кто чего еще посоветует, а то на файлах велосипедить тоже как-то не хочется.
Сейчас объёмы на json-файлах - что-то в районе 5 ГБ, зависит от конкретного пользователя. С программой из коробки 1 гигабайт идёт, а дальше кто сколько нагенерирует.
Если важно, то разработка под .NET FW 4.5.

Разве? Какие проблемы с этим?

ну, там больше проблема в текущей реализации. Нет никакого контроля за тем, что файл вообще записался, никак не обрабатывается ситуация, когда компьютер внезапно отключился или кончилось место на диске. По сути надёжность зависит от везения сейчас и в любой момент можно из-за любого чиха потерять файл-другой.
Сложность поддержки по сути в том, что нужно изначально костыльный код поддерживать, это даже морально тяжело )))
О том, чтобы реализовать нормально всё на файлах с переработкой структуры хранения, тоже думаю, но как-то не очень хочется так велосипедить и свой nosql создавать.
С другой стороны пока и SQLite не так, чтобы мне здесь нравился.

ъъъъъ, ну, не так, чтобы гарантируют прямо, но даже в том же SQLite есть режим журнала, который хоть от базовых сбоев спасти должен.
Firebird мне казался для этой задачи практически как из пушки по воробьям (много ненужного функционала, который скорее всего только увеличит время обработки, а пользы не принесёт), но пожалуй тоже нужно посмотреть, т.к. выбор не велик. Только когда я его в последний раз видел, в embedded версии он не умел одновременную работу из разных процессов, хотя здесь это и не нужно.

И в какое место оно запишет этот журнал если место на диске кончилось?..

Главное - чтобы не сломалась БД из-за этого. Я надеюсь, что SQLite именно так и поступает.
То, что текущая запись не уместилась/не успела записаться - это нормально.

Спасибо ответившим, посмотрю позже что и как. Только не очень понимаю чем эластик тут должен помочь.
Пока успел посмотреть только sqlite и firebird. Если данные сильно разбивать, то выглядят неплохо, но в текущих реалиях неделимые блоки данных больше 50 мегабайт и скорость работы с ними сильно проигрывает хранению в отдельном файле.
Пока задачу отложили, буду потом еще думать. Или буду стараться еще разбить данные, чтобы не было необходимости хранить в одной ячейке такие объёмы или же использовать БД для индексов, а хранить большие данные в файлах.

Не хотелось это делать вручную просто