MySQL vs PostgreSQL что выбрать для нового проекта в 2024

[solidity2024]

Стартуем новый SaaS-проект, бэкенд на Go, планируется около 10-20 млн записей в основных таблицах, сложные отчёты, немного JSON-полей. Команда одинаково знает и MySQL 8, и PostgreSQL 15. Долго спорим что взять — нет консенсуса. Что реально важно учитывать при выборе, кроме «я привык к X»?

[k8s2000]

Для SaaS с отчётами и JSON я бы без колебаний брал PostgreSQL. JSONB там значительно мощнее, window functions удобнее, CTE работают как ожидаешь (в MySQL рекурсивные CTE появились только в 8.0 и местами ведут себя странно). Ещё pg_trgm для полнотекстового поиска из коробки — удобно.

[postgres2]

MySQL 8 сильно подтянулся, не надо его демонизировать. Если у команды реально одинаковый опыт — смотрите на экосистему вашего стека. Для Go отличные драйверы есть для обоих. Я бы смотрел на managed-решения вашего облака: RDS Aurora MySQL vs Aurora PostgreSQL, или Cloud SQL — там могут быть ценовые и операционные отличия.

[kotlinmaster]

Из практики: репликация в PostgreSQL (логическая, физическая) гибче и в целом надёжнее настраивается, чем MySQL binlog в сложных топологиях. Если планируете multi-region или read replicas — это важный момент.

[Bowden]

Честно, разница для вашего масштаба будет минимальной. Важнее индексы написать правильно и не делать N+1 в ORM. Выбирайте то, в чём у команды чуть больше уверенности, и идите вперёд — не тратьте на это больше дня.

[Austkin]

Один нюанс про JSON: в PostgreSQL JSONB индексируется через GIN, можно делать операторы @>, ?, это очень удобно. В MySQL JSON-индексы есть только через generated columns, что работает, но менее эргономично. Если JSON-поля будут в условиях WHERE — это перевесит чашу весов в сторону Postgres.

[slypmp]

Поддержу тему про отчёты — если у вас есть аналитические запросы с группировками, агрегатами по большим диапазонам, смотрите ещё в сторону ClickHouse как отдельного хранилища для отчётности. Тогда основная база вообще не важна, можно брать что угодно, а тяжёлые отчёты гонять в колоночнике.