Какими критериями руководствоваться при выборе базы данных для проекта?

А, выбор базы данных, говоришь? Ну это, блядь, как выбрать себе жену, только на всю жизнь проекта, а не на всю жизнь. Ошибёшься — и будет тебе пиздец, а не масштабирование.

Смотри, вот тебе расклад по полочкам, без этой вашей заумной хуйни, но чтобы всё по делу.

1. Модель данных: что за хлам ты собираешься хранить?

• Реляционные (SQL, типа PostgreSQL, MySQL). Это когда у тебя всё по полочкам, как у хорошей тёти в архиве. Пользователь, заказ, товар — всё связано, и если ты попробуешь удалить пользователя, у которого есть заказы, система тебе скажет: «Иди нахуй, мудак, сначала разберись с заказами». Это ACID, целостность, надёжность. Для денег, для бухгалтерии — идеально.
• Документо-ориентированные (NoSQL, типа MongoDB). А это уже как комната подростка: кинул JSON-документ с профилем пользователя — и забыл. Хочешь — добавь поле «любимый_цвет_соплей», схема не взвоет. Отлично для каталогов, контента, всякой хуйни, которая постоянно меняется.
• Ключ-значение (типа Redis). Вообще, ебушки-воробушки, это не база, а скоростной лифт. Запрос — ответ, нахер все связи. Кэш, сессии, временные данные — его царство. Быстрее только мысль о том, что работа закончилась.
• Колоночные (типа Cassandra). Это уже для серьёзных дядек, которые копят терабайты логов и потом хотят их все разом проанализировать. Запись — овердохуища, чтение для аналитики — тоже. Для обычного сайта-визитки — как из пушки по воробьям.

2. Масштабируемость: а что, если станет много-много?

• Вертикальная (Scale-Up). Просто берёшь сервер и начинаешь в него впихивать оперативку и процессоры, пока он не лопнет или твой бюджет не накроется медным тазом. Просто, но дорого и не бесконечно. Классика для SQL.
• Горизонтальная (Scale-Out). А вот это уже цирк. Берёшь кучу дешёвых серверов, раздаёшь им данные и говоришь: «Работайте, пидарасы!». Многие NoSQL так с рождения умеют. Мощно, отказоустойчиво, но админы потом могут поседеть, пока это всё настроят.

3. Консистентность: а все ли видят одно и то же?

• ACID. Это когда ты положил деньги на счёт, и все сразу видят, что они там есть. Всё строго, чётко, надёжно. Банки, платежи — только так.
• BASE (Basically Available...). А это когда ты написал сообщение в чат, а твой друг увидел его через секунду. Система не гарантирует, что все данные везде синхронны прямо сейчас, но она всегда доступна. Скорость и живучесть важнее сиюминутной точности. Многие распределённые NoSQL так живут.

4. Сложность запросов: что ты хочешь от неё?

• Нужно делать запросы вроде «покажи всех пользователей, которые купили красные трусы в прошлом месяце, но не купили зелёные носки»? Это JOIN'ы, это SQL, родной.
• А если просто «дай профиль пользователя по его ID» или «найди все документы, где есть слово "пиздец"»? Тогда NoSQL может быть проще и быстрее.

Вот тебе примеры на Go, чтобы не быть голословным:

// PostgreSQL: для серьёзных отношений, где важен порядок. Например, учёт денег.
import "github.com/jmoiron/sqlx"
db, err := sqlx.Connect("postgres", "user=postgres dbname=test sslmode=disable")
// Если err не nil, значит, ты где-то проебался с подключением.

// MongoDB: для свободных отношений, где структура меняется каждую неделю. Профили, контент.
import "go.mongodb.org/mongo-driver/mongo"
client, err := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://localhost:27017"))

Итог, блядь, какой итог? Волшебной таблетки нет! Есть задача. Для 95% проектов, особенно когда только начинаешь и хуй знает, что будет завтра, PostgreSQL — это твой бронежилет. Надёжный, гибкий, всё умеет. А потом, если в какой-то части проекта начнётся конкретный пиздец по нагрузке или по структуре данных, вот тогда и прикручивай Redis для кэша или Mongo для какого-нибудь безумного каталога. Главное — не выеби себе мозг раньше времени, пытаясь сделать всё на самой модной базе.