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

Давай разберём эту дичь про выбор базы данных, а то у меня уже волосы на жопе шевелятся от того, как некоторые это делают. Слушай сюда, но внимательно, а то потом будешь плакать, как Герасим над Муму.

Выбор базы — это не просто «ой, давайте возьмём ту, что в названии слово «пост» есть». Это, блядь, стратегическое решение, от которого потом вся твоя архитектура будет либо летать, либо ползать, как черепаха в сиропе. Я подхожу к этому, как сапёр к мине — осторожно и с пониманием, что хуй накосячишь — всем пиздец.

1. Модель данных и характер нагрузки — тут вообще пиздец, народ путается.

• Реляционные (SQL), типа PostgreSQL, MySQL: Это твои рабочие лошадки, когда данные — как кирпичики в стене, всё чётко, по схеме, и связи между ними важнее, чем твоя последняя зарплата. Нужны транзакции, чтобы деньги со счёта А перешли на счёт Б, а не испарились в никуда? Это твой выбор. Для всяких интернет-лавок и банковских приложений — идеально. ACID, ёпта!
• Документо-ориентированные (NoSQL), типа MongoDB: А вот это уже для тех, кто не знает, как его данные завтра будут выглядеть. Слабоструктурированный JSON, гибкая схема — сегодня поле username, а завтра уже user_nickname с массивом любимых покемонов. Для CMS, каталогов — то, что надо. Но, сука, не пытайся делать на ней сложные джойны, а то охуеешь.
• Ключ-значение, типа Redis: Это, блядь, не база в полном смысле, а скорее супер-быстрый шкафчик в оперативке. Кэширование, сессии, очереди задач. Задержка — минимальная. Но упал сервер — и всё, пиши пропало, если не настроил персистентность. Помни об этом, а то будешь как дурак.
• Колоночные, типа ClickHouse: Это уже для больших дядек, которые аналитикой занимаются. OLAP, ёбта! Когда нужно проанализировать терабайты логов, а не вставлять по одной записи в секунду. Для обычного веб-приложения — это как из пушки по воробьям, овердохуища мощности.

2. Масштабируемость и производительность — тут вообще отдельный цирк.

• Вертикальное масштабирование (добавить RAM/CPU серверу): Просто, как три копейки. Но, блядь, упираешься в потолок железа, и всё — апгрейдиться некуда, кроме как покупать новый супер-компьютер. Классика для SQL.
• Горизонтальное масштабирование (добавить ещё серверов в кластер): Вот это уже по-взрослому. Сложнее настроить, но масштабируется почти до бесконечности. Любимая фишка NoSQL.
• CAP-теорема: Это, сука, священный грааль. Нужно выбрать две из трёх букв. Консистентность (С), Доступность (A), Устойчивость к разделению (P). Хочешь, чтобы данные всегда были точные, даже если часть кластера легла? Выбирай CP (как MongoDB). Хочешь, чтобы сервис всегда отвечал, пусть даже немного устаревшими данными? Выбирай AP (как Cassandra). А хочешь всё и сразу? Иди нахуй, так не бывает.

3. Экосистема и операционные расходы — про это все забывают, а потом плачут.

• Стоимость: Managed-решения в облаке (AWS RDS, Atlas) — это удобно, но плати, сынок, плати. Self-hosted — дёшево, но админить надо самому, а это время, нервы и риск всё просрать.
• Сообщество: Есть ли нормальные драйверы для Go? А ORM типа GORM или sqlx? А инструменты для миграций? Если нет — готовься писать всё сам, велосипед за велосипедом.
• Сложность администрирования: Бэкапы, мониторинг, отказоустойчивость. Ты готов к этому? Или думаешь, что база сама себя будет обслуживать? Проснись, чувак, это не так работает.

Ну и чтобы ты не думал, что я просто языком чешу, вот тебе примеры кода, как с этой всей хуйней общаться из Go. Код не трогаю, он святой.

// PostgreSQL с использованием стандартной библиотеки
db, err := sql.Open("postgres", "user=... password=... dbname=... sslmode=disable")

// MongoDB с официальным драйвером
client, err := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://localhost:27017"))

// Redis
rdb := redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

Короче, думай головой, а не жопой. Выбирай базу под задачу, а не под модное название. Иначе получится, как в той истории: «Муму! Муму!», а она уже на дне, блядь.