Почему этот выбор вообще важен
Есть два типа проектов: те, где базу данных выбирали осознанно, и те, где «ну MySQL поставим, все же его используют». Вторые рано или поздно приходят к первым с вопросом «а как нам это теперь мигрировать».
Проблема не в том, что MySQL плохой. Проблема в том, что у каждой СУБД есть своя сильная сторона — и если вы в нее попадаете, все работает отлично. Если нет — начинается борьба с инструментом вместо решения задачи.
Дальше — три сценария, с которыми чаще всего сталкиваются команды в российских облаках. Без маркетинга и без «зависит от задачи» в качестве ответа.
PostgreSQL: когда это очевидный выбор
PostgreSQL — это то, что я бы рекомендовал по умолчанию новому проекту в 2026 году. Не потому что модно, а потому что он умеет все, что нужно 80% приложений, и при этом не создает неприятных сюрпризов позже.
Конкретно: транзакции работают как надо (ACID без оговорок), JSONB-поля позволяют хранить полуструктурированные данные без NoSQL-костылей, полнотекстовый поиск на кириллице работает из коробки с нужной конфигурацией. Есть PostGIS — если вдруг понадобится геолокация. Есть расширения на любой вкус.
Где PostgreSQL реально хорош: e-commerce с заказами и платежами, CRM и ERP-системы, SaaS-продукты с многопользовательской моделью, любое приложение, где важна целостность данных. То есть практически везде, где данные — это деньги или их эквивалент.
Типичная ошибка с PostgreSQL
Поставить без настройки и удивляться, почему медленно. Дефолтная конфигурация PostgreSQL рассчитана на машину с 256 МБ RAM и датирована примерно 2000-м годом. На современном облачном инстансе нужно поднять shared_buffers до 25% RAM, work_mem, effective_cache_size и еще несколько параметров. Сервис pgtune делает это автоматически — просто ввести характеристики сервера. Managed DBaaS-сервисы (Cloud.ru, Yandex Cloud, Selectel) делают эту настройку за вас, что само по себе аргумент в их пользу.
MySQL: живет там, где уже живет
MySQL — это не плохая СУБД, это другая СУБД с другой историей. Она выросла из веба начала 2000-х, и в этом контексте до сих пор очень хороша. WordPress, Bitrix, большинство классических PHP-приложений — все это MySQL, и это нормально.
Если вы берете готовую CMS или ERP, которая написана под MySQL — не надо геройствовать и переводить на PostgreSQL. Это боль без выгоды. Используйте то, под что написано приложение.
Если же вы пишете с нуля и думаете «возьму MySQL, там попроще» — это ловушка. MySQL исторически имел проблемы с транзакционной моделью (сейчас в InnoDB все нормально, но репутация осталась), менее строгие проверки типов данных по умолчанию, нет нативного JSONB с индексацией. Для нового проекта PostgreSQL выбирают осознанно, MySQL — по привычке.
ClickHouse: когда вы считаете, а не ищете
ClickHouse — это отдельная категория. Его не сравнивают с PostgreSQL как альтернативу, его используют рядом с PostgreSQL для другого класса задач.
Упрощенно: PostgreSQL — это хранение и изменение данных. ClickHouse — это анализ уже накопленных данных. Если вам нужно посчитать, сколько пользователей из Москвы совершили покупку больше 5000 рублей в ноябре, и при этом у вас миллиард строк в таблице заказов — ClickHouse сделает это за секунды, PostgreSQL будет думать минуты.
Колоночное хранилище читает только нужные колонки, а не всю строку целиком. При агрегациях это дает выигрыш в 50–200 раз на больших объемах. Именно поэтому Яндекс создал ClickHouse для своей аналитики — и потом открыл его всем.
Где ClickHouse не нужен
Там, где данные часто меняются. ClickHouse плохо умеет UPDATE и DELETE — это не баг, это архитектурное решение. Если вы хотите хранить профили пользователей и часто их обновлять — это PostgreSQL. Если вы хотите строить отчеты по поведению этих пользователей за последние полгода — это ClickHouse.
Еще один момент: JOIN-ы в ClickHouse работают иначе и требуют понимания. Привычные паттерны из реляционного мира здесь дают плохую производительность. Придется переучиваться или потратить время на изучение особенностей движка.
Практическая схема для продакшна
Большинство нормально работающих продуктов используют что-то вроде такой схемы:
PostgreSQL — основная транзакционная база. Все пользователи, заказы, платежи, все, что нужно менять и у чего должна быть целостность.
Redis — кэш и сессии. Снимает нагрузку с PostgreSQL на частых чтениях, хранит авторизационные токены, счетчики, очереди для Celery или Sidekiq.
ClickHouse — аналитика. Данные из PostgreSQL стримятся сюда через Kafka или напрямую через репликацию. Дашборды, отчеты, BI-инструменты работают с ClickHouse.
Это не обязательная схема — маленькому проекту хватит одного PostgreSQL. Но когда вырастаете, эволюция обычно идет именно так.
Отдельно о миграции между СУБД
Если вы уже на MySQL и думаете переехать на PostgreSQL — это реальная работа, не однодневная. Типы данных отличаются, синтаксис SQL в деталях разный, функции называются иначе. Pgloader умеет автоматически конвертировать схему и данные, но бизнес-логику в приложении придется проверять руками.
Честный ответ: если текущая база работает нормально и вас все устраивает — не мигрируйте. Выбор СУБД влияет на новые проекты, а не на работающий продакшн. Технический долг лучше отдавать постепенно, а не одним большим болезненным рефакторингом.