Давайте попробуем выбрать аппаратно-программное решение.

В день добавляется 250 тыс. сообщений.
Средний размер сообщения - 200 байт.
В мегабайтах - 60.
Это наиболее суровая ожидаемая нагрузка.
Если предположить, что 70% сообщений добавляется в период 9-18 часов (70% = 175000 штук), получим 324 сообщения в минуту = ~5 сообщений в секунду.

Но скорость не важна, т.к. добавляться в базу они должны пачками, штук по 100-1000 сразу и супербыстрое отзывчивое добавление не важно.

Через месяц в базе будет 7750000 (7.7 млн) сообщений, 1.8 гигов сырых данных.

Через год - 93 млн. сообщений, 22.2 гига данных.

Вопросы хардварно-софтварные:
1. Полнотекстовый поиск в 93 млн сообщениях средней длины 200 байт.
2. Аппаратное обеспечение для предложенной платформы.

Обычная задача многокритериальной оптимизации: чем дешевле, тем лучше и чем быстрее поиск, тем лучше. Поиск фраз состоящих из 1, 2, 3 слов должен идти, например, за секунду. Сортировка по свежести сообщений, по категории (С++/психология/путешествия).

Какая это должна быть DMBS? Какая архитектура (один сервер или несколько дешёвых компов на ATOM, партиционирование, репликация, шардинг). Как лучше всего организовать таблицу с 93 млн сообщениями, при условии того, что наибольшая нагрузка на неё идёт в режиме чтения последних 250000 сообщений (последние сутки), но хотелось бы добираться до сообщений за весь год (возможно, медленнее). Это называется репликация, как я понимаю - по ночам скидываем все данные на слейв-серверы, на мастер-сервере оставляем только последние несколько суток. Какая для этого поддержка есть в MySQL, Postgres? Как будет выглядеть операция "переместить пол-таблицы с наиболее старыми записями на другой сервер" на уровне языка SQL и процедур конкретных систем DMBS?

Вопросов бесконечная куча, но основные заданы. Не занимаюсь DBA, раньше разрабатывал in-memory NoSQL-решение на большом толстом сервере, но здесь бюджет не тот, чтобы покупать профессиональное оборудование. Бюджет на эти эксперименты позволяет поиметь максимум несколько недорогих обычных компов с толстыми сигейтами.

iljyAndron.Vazov,

5 записей в секунду для подавляющего большинства современных СУБД нагрузка копеечная. Прикиньте бюджет и сконфигурите сервак с приличным количеством памяти, чтоб полнотекстовый поиск в памяти шел, и будет нормально.
Для хранения 22.5 гигов чистых сообщений с учётом служебных структур должно ли хватить 32 гиг озу?
Сколько может стоить рублей такая железка "начального" уровня?

Не могу сориентироваться в market.yandex.ru по ОЗУ - максимальное ОЗУ для матерей там не указывается, а только количество слотов.

SignOffAndron.Vazov,

Извини, а обязательно в БД запихивать ? Нельзя ли на диске тупеньк по рабоче-крестьянски соханять - и там проиндексировать ?
Совсем не обязательно, хоть в голый раздел HDD. Но это ж ведь тогда все B-деревья руками на C++ кодить придётся.

iljyAndron.Vazov,

а вам все эти сообщения сразу будут нужны? Подозреваю, что, как и в большинстве систем, основная работа будет идти с хвостом. Так что 32 гига вам должно хватить надолго. По поводу цен - залезьте к производителям и посмотрите, будет быстрее.
Да, я это и имел ввиду, когда писал про реплицирование.