- Инфа о пользователях должна жить постоянно - Касательно изменений этих

данных - нет, эти данные менять может только сам пользователь, да и видна эта инфа будет только ему. Но пользоваться этой инфой будет сервер, при запросах от этого пользователя
- Пользователей за первые 2 месяца наберется до 300 по началу и потом в течении года предполагается где-то около 10 000 - 30 000, вряд ли сильно больше, но сколько реально их будет, не известно
- настройки менятся будут при создании и в среднем 1-3 раза в неделю каждым пользователем
- Инфа вида: юзернейм (текст до 100 символов), какие-то заметки (текст до 300 символов, где-то на аккаунт от 1 в первые пару месяцев и где-то до 20 в первый год), какие-то закладки (текст до 200 символов, на аккаунт от 1 в первые пару месяцев и где-то до 20 в первый год), общие настройки аккаунта, а не конкретного устройства, чтобы можно было синхронизировать между устройствами (по сути булин значения и числа, может штук 15). Собственно примерно такая иерархия.
- Бюджет - пет проект, с тестированием на одной фирме и дальнейший запуск на несколько других фирм, поэтому не шибко много, на сервера выделено будет сначало (первые пару месяцев) на бесплатном инстансе от amazona на aws (1cpu, 1gb ram), а потом в течении года можно будет перейти на DigitalOcean или на ScaleWay до 15$ в месяц + домен
- High Availability: Высокая доступность? т.е. не 24/7
- Disaster Recovery: Хватит ежедневных бекапов
- Обученность служб сопровождения - пока даже не представляю о чем это, службы поддержки как таковой не будет по первам, если это об этом))

Ну, тут уже видно, что это клиент-сервер, регистрации пользователей (которых порядка 1000-10000), и хранение их насторек с использованием на сервере. (сколько настроек кстати? Порядок числа?) Тут уже видно, что логично БД применять для этого. Но тут требования стандартные, объёмы небольшие (даже априори очевидно -- ты большие объёмы как параметры для настройки поиска использовать не сможешь), итого -- тебе подойдёт любая современная СУБД, даже такое говно, как MySQL. Я как раз его (MySQL) и рекомендую испльзовать -- распростанён и популярен, легко найти информацию. Можно PG, но тут наверное он слишком тяжёл будет, хотя с другой стороны, если он будет использован для ещё каких-то нужн данной системы -- то и ОК. И тем не менее, можно всё ещё использовать и SQLite.