Подскажите СУБД

sqlite

csv

Plain text

Требования какие к производительности, отзывчивости, пожиранию памяти/фс, языку запроса?

В такой формулировке проще в файлах хранить или псевдо-БД а-ля bdb.

Запрос уровня «Подскажите автомобиль для быстрой перевозки пассажиров при умеренном потреблении топлива». Надо более конкретные требования! Если их нет, то csv/plain text по каталогам (это даже не БД) или sqlite. Всё уже перечислили до меня.

хранения текстовой информации

Напрашивается документ-ориентированная БД, например MongoDB.

В общем, нужно запихивать короткие сообщения, а потом доставать их в оффлайне для обработки с периодичностью раз в две недели. Может быть и файл подойдёт, пока кумекаю ТЗ, так что в процессе.

berkeley db? Зависит от того, как ты собираешься доставать сообщения.

Если для пачки заметок, то sqlite попробуй.

Весь хабар в одном файле.

sqlite, h2.

Если сообщения достаточно короткие и не удаляются и порядок не играет роли, то можно в одном CSV-like файле хранить, вида {ключ | сообщение}, как-то так.

А иначе bdb или mongo должно хватить с головой.

если нужна высокая скорость чтения/записи - redis

А можно узнать, что не так с MySQL? Просто это же вроде как мейнстрим, LAMP тот же взять.

А почему не MySQL? Что с ним не так?

устарела морально, по сабжу postgresql

Что значит «устарела морально»? Не модно типа? Ну так это не объективно, должны быть значит какие-то изъяны, верно?

https://habrahabr.ru/post/268949/

Весь хабар в одном файле.

читаю habrahabr.... думаю где взять дамп =)

Жирная сильно для «оперативно». Против Мускула ничего не имею. СУБД как СУБД.

MongoDB не подходит?

Жирная сильно для «оперативно»

Типа много функционала, который не используется? Управлять ей, вроде, не особо сложнее, чем другими СУБД.

Для такой задачи оверкилл.

Изъян один. Когда юзаешь мускл, то смузи сразу становится не вкусным. А реально, мне лично юзать постгрес в разы удобнее и приятнее.

У нас коллеги в этом вопросе нахваливают orientdb