PostgreSQL vs MySQL — выбор СУБД для проекта

Когда начинаешь новый проект, вопрос выбора базы данных встаёт рано или поздно. Если речь о реляционных СУБД, то почти всегда выбор сводится к двум кандидатам: PostgreSQL и MySQL. Оба бесплатны, оба популярны, оба работают на любом сервере. Но разница между ними принципиальная, и неправильный выбор в начале может дорого обойтись потом.

Немного истории и контекста

MySQL появился в 1995 году и долгое время был синонимом веб-разработки. LAMP-стек (Linux + Apache + MySQL + PHP) — стандарт де-факто для большинства сайтов нулевых и десятых. MySQL быстрый, простой, хорошо документированный. Почти любой хостинг его поддерживает.

PostgreSQL старше — первая версия вышла в 1996-м, хотя корни уходят в проект Ingres из Беркли 1977 года. Postgres изначально задумывался как более строгая, академическая база с упором на соответствие стандартам SQL и расширяемость.

Сейчас MySQL принадлежит Oracle (с 2010 года), а PostgreSQL развивается как полностью независимый open-source проект. Это важно для понимания вектора развития обеих баз.

Где MySQL объективно выигрывает

Простота запуска. MySQL настраивается быстрее. Меньше конфигурационных опций по умолчанию, понятная структура, отличная совместимость с большинством хостингов и CMS. Если разворачиваете WordPress, Drupal или типичный PHP-проект — MySQL заработает из коробки без лишних усилий.

Потребление ресурсов. На слабых серверах (1–2 CPU, 1–2 GB RAM) MySQL ведёт себя скромнее. PostgreSQL более требователен к памяти при старте и при большом количестве параллельных подключений.

Скорость простых операций чтения. На workload типа «много SELECT по первичному ключу» MySQL с движком InnoDB часто обходит PostgreSQL. Если у вас сайт-каталог с простыми запросами — разница будет заметна на нагрузочных тестах.

Репликация из коробки. MySQL master-slave репликация настраивается буквально за полчаса. Давно отработанный механизм, который работает стабильно даже без глубокого погружения в детали.

Экосистема хостинга. Почти каждый shared-хостинг даёт MySQL. Если клиент хочет дешёвый хостинг и простой сайт — MySQL безальтернативен.

Где PostgreSQL объективно сильнее

Соответствие стандартам SQL. Postgres строго следует стандарту SQL:2016. MySQL с историческими отклонениями — GROUP BY у него менее строгий, NULL-сравнения иногда ведут себя неожиданно, если не знать деталей. Для команд, которые пишут переносимый SQL, PostgreSQL предпочтительнее.

Сложные запросы и аналитика. Postgres значительно лучше работает с CTE (Common Table Expressions), оконными функциями, рекурсивными запросами. Для аналитических задач, отчётности, сложных JOIN-ов с большими таблицами — PostgreSQL выигрывает и по возможностям, и по производительности.

Типы данных. Вот где PostgreSQL реально блистает:

• JSONB — бинарный JSON с полноценным индексированием. Это не просто хранение строки, а работа с документами внутри реляционной базы.
• ARRAY — массивы прямо в колонке, с поддержкой индексов.
• UUID, INET, CIDR, MACADDR — специализированные типы для сетевых задач.
• TSVECTOR / TSQUERY — встроенный полнотекстовый поиск.
• RANGE — диапазоны дат и чисел.

MySQL тоже умеет JSON (с версии 5.7), но реализация заметно слабее.

Транзакции и ACID. Postgres реализует MVCC (Multi-Version Concurrency Control) на уровне всего движка, без исключений. В MySQL это зависит от движка: InnoDB — ACID-совместимый, а вот MyISAM — нет. Путаница с движками в MySQL — источник ошибок для новичков.

Расширения. PostgreSQL можно расширять кардинально: PostGIS для геоданных, TimescaleDB для временных рядов, pgvector для векторных эмбеддингов, pg_trgm для нечёткого поиска. Это реально другой уровень гибкости.

Права доступа и безопасность. Row-level security, более гранулярные привилегии, policy-based доступ — всё это в Postgres из коробки.

Производительность под нагрузкой

Здесь нет однозначного ответа — любой бенчмарк нужно смотреть в контексте конкретного workload.

OLTP (много коротких транзакций). MySQL с InnoDB традиционно силён. При 500–1000 одновременных подключениях и простых операциях INSERT/UPDATE/SELECT MySQL показывает на 10–20% лучшие результаты в тестах типа sysbench.

OLAP (аналитика, сложные запросы). PostgreSQL заметно обходит MySQL при GROUP BY, сортировке больших наборов данных, вложенных подзапросах. Разница может достигать 2–5x на тяжёлых аналитических запросах.

Параллелизм. Postgres лучше использует несколько CPU для одного запроса (parallel query execution с версии 9.6). MySQL этого полноценно не умеет.

Примерные цифры. На VPS с 4 CPU и 8 GB RAM PostgreSQL 16 обрабатывает около 2500–3000 транзакций/сек на pgbench при стандартной конфигурации. MySQL 8.0 — около 3000–3500 на sysbench при аналогичном тесте. Но это синтетика. На реальных задачах всё зависит от схемы, запросов и настройки конфигурационных параметров.

Масштабирование и репликация

MySQL. Проверенная master-slave репликация, Galera Cluster для multi-master, MySQL InnoDB Cluster. Шардирование через Vitess (используется в YouTube, Pinterest). Экосистема отработана годами.

PostgreSQL. Встроенная streaming replication и logical replication (с версии 10). Patroni + etcd — стандартный стек для production HA. Citus для горизонтального шардирования. Pgpool-II для балансировки подключений.

Если нужен геораспределённый кластер с несколькими мастерами — MySQL через Galera проще в настройке. Если нужна надёжная master-standby с автофейловером — Patroni для Postgres справляется не хуже.

Что выбрать под конкретный проект

Интернет-магазин на WooCommerce, Bitrix, OpenCart. Берите MySQL. Все эти CMS заточены под него: документация, плагины, хостинг — всё там. Кастомная разработка интернет-магазина с нуля — уже другой разговор, но на готовом движке MySQL — предпочтительный выбор.

Корпоративный портал, ERP, CRM с кастомной логикой. PostgreSQL. Сложные связи между таблицами, транзакции, аналитика, отчёты — всё это Postgres делает лучше. Когда запросы становятся сложнее, вы оцените оконные функции и JSONB для хранения гибких атрибутов.

SaaS-приложение, многопользовательский сервис. PostgreSQL. Row-level security позволяет изолировать данные разных тенантов на уровне базы без дополнительных костылей в коде. Это важная архитектурная разница, которая окупается при росте.

Геосервис, карты, логистика. PostgreSQL + PostGIS. Здесь нет конкуренции. PostGIS — промышленный стандарт для геопространственных данных. MySQL с пространственными типами несравнимо слабее.

Блог, новостной сайт, портфолио. Без разницы. MySQL — если на CMS, Postgres — если пишете с нуля на Django или Rails, где Postgres считается предпочтительным выбором по умолчанию.

ML/AI приложения, векторный поиск. PostgreSQL + pgvector. Хранение эмбеддингов прямо в базе и similarity search — актуальная задача в 2026 году, и Postgres с этим справляется на удивление хорошо.

Версии и актуальное состояние

MySQL 8.4 — текущий LTS-релиз с поддержкой до 2032 года. Версия 8.0 добавила оконные функции, CTE, улучшенный EXPLAIN — MySQL заметно вырос и закрыл многие исторические пробелы.

PostgreSQL 17 — вышел в 2024 году, добавил инкрементальный бэкап, улучшенный вакуум, новые возможности SQL/JSON. PostgreSQL выходит с предсказуемым расписанием — major release раз в год в октябре.

Оба активно развиваются. Разрыв в функциональности за последние 5 лет сократился, но Postgres по-прежнему опережает в расширяемости и строгости.

Миграция между базами

Если проект уже работает на MySQL и вы думаете о переезде на PostgreSQL — это реально, но требует усилий:

1. Синтаксические различия SQL. AUTO_INCREMENT → SERIAL или GENERATED ALWAYS AS IDENTITY. Кавычки: в Postgres двойные для идентификаторов, одинарные для строк.
2. Различия в работе с NULL, булевыми типами (в MySQL TINYINT(1) для bool, в Postgres — настоящий BOOLEAN).
3. Инструменты: pgloader умеет переносить данные из MySQL в PostgreSQL автоматически с трансформацией типов — хорошая отправная точка для миграции.

Обратно — из Postgres в MySQL — сложнее. Типы данных JSONB, ARRAY, специфичные функции — всё это придётся переписывать или терять в функциональности.

Как это выглядит на практике

В REEXY при разработке новых проектов базу выбирают исходя из задачи: для интернет-магазинов на популярных CMS — MySQL без вопросов, для корпоративных сайтов с кастомной логикой и сложной структурой данных — PostgreSQL. Это не вопрос моды, это вопрос правильного инструмента под конкретную задачу.

Быстрая шпаргалка

Если стартуете новый проект на кастомном стеке — берите PostgreSQL. Если работаете с популярными CMS или ограничены возможностями хостинга — MySQL. Оба варианта production-ready, оба бесплатны, оба не подведут при правильной настройке и понимании их сильных сторон.