</>
halfcoder

Гайды

PostgreSQL vs MySQL: критерии выбора СУБД

SQL и типы, репликация и HA, лицензии, когда смотреть в сторону Postgres или MySQL/MariaDB и как мигрировать без сюрпризов.

~11 мин чтения

Базы данныхСравнение технологийPostgreSQLMySQL

PostgreSQL vs MySQL: критерии выбора СУБД

Сравнение PostgreSQL и MySQL (включая MariaDB) нужно при выборе СУБД для нового продукта или при миграции. Ниже — практичные критерии без «религиозных войн»: обе системы зрелые, но с разными сильными сторонами.

Версии и редакции имеют значение: в продакшене «MySQL» часто значит InnoDB + 8.x; у PostgreSQL — 15+ или 16/17. Проверяйте фичи по документации вашей минорной версии.

1. Краткая матрица выбора

КритерийPostgreSQLMySQL / MariaDB
Сложные запросы, CTE, оконные функции, типы данныхСильный стандарт SQL, jsonb, массивы, диапазоны и др.В 8.x возможности SQL сильно выросли; для очень сложной аналитики часто смотрят на PG
РасширяемостьExtensions (PostGIS, pgvector, Citus…), кастомные индексыПлагины и storage engines; широкая экосистема хостингов
Репликация и HAПотоковая и логическая репликация, Patroni и др.Group Replication, Galera — свой набор компромиссов
Дефолты «из коробки»Консервативные, чаще нужно читать про памятьЧасто проще стартовать на типовом LAMP/хостинге
Лицензия ядраPostgreSQL License (пермиссивная)GPL (MySQL); MariaDB — GPL

Если вы уже выбрали PostgreSQL, начните с установки и настройки PostgreSQL 17.

2. Когда чаще выбирают PostgreSQL

  1. Сложная модель, много JOIN и аналитики внутри OLTP.
  2. JSON/геоданные — jsonb, GIN/GiST, PostGIS.
  3. Расширения: векторный поиск, специализированные индексы.
  4. Жёсткие ограничения целостности (CHECK, FK) как часть модели.

Документный подход внутри Postgres — в гайде по JSONB.

3. Когда чаще выбирают MySQL / MariaDB

  1. Команда и хостинг уже стандартизированы на MySQL.
  2. Простой CRUD и чтение с реплик — привычный паттерн.
  3. Интеграции (CMS, коробочные продукты) заточены под MySQL.
  4. MariaDB — если важна ветка совместимости под конкретные дистрибутивы.

4. Нефункциональные аспекты

  • Производительность зависит от схемы, индексов, InnoDB vs shared_buffers, диска и паттерна нагрузки — меряйте на своих данных.
  • Эксплуатация — бэкапы, репликация, метрики; для PostgreSQL полезен стек из гайда по Prometheus и Grafana.
  • Миграция — различия в типах, SERIAL vs AUTO_INCREMENT, строгость GROUP BY, NULL в уникальных индексах; закладывайте время на переписывание запросов и тесты.

Кодировка и сортировка

В MySQL для Unicode по умолчанию используйте utf8mb4 и явный collation; «utf8» без mb4 — ловушка для эмодзи и части символов. В PostgreSQL — UTF8 + выбор collation на уровне БД/колонки; поведение ILIKE и классов символов отличается от MySQL — проверяйте индексы на выражениях с lower().

Блокировки и MVCC (очень кратко)

PostgreSQL — MVCC без read-lock'ов на чтение; длинные транзакции держат bloat и мешают VACUUM. InnoDB — MVCC с другой моделью gap/next-key locks под repeatable read — другие типичные дедлоки. Не копируйте паттерны «локну строку SELECT FOR UPDATE» между СУБД вслепую.

5. Практичный алгоритм решения

  1. Зафиксируйте RTO/RPO, пиковый QPS, объём данных, нужно ли шардирование на старте.
  2. Прототипируйте 3–5 самых тяжёлых запросов на обеих СУБД с реалистичным объёмом.
  3. Оцените команду и managed-провайдера.
  4. Если критичны PostGIS / jsonb / сложный SQL — по умолчанию смотрите на PostgreSQL, если нет жёсткого требования MySQL.

6. Инструменты миграции

pgloader для переноса MySQL → PostgreSQL (типы, индексы — проверка вручную). Обратный путь реже; чаще ETL в стадии перехода. ORM (SQLAlchemy, Django) помогают абстрагировать, но сырой SQL и триггеры всё равно переписываются.

7. Managed-облака

Сравнивайте RDS/Aurora, Cloud SQL, Azure Database по версиям движка, point-in-time recovery, read replicas, лимитам соединений и расширениям (например, доступность pgvector в вашем регионе).

См. также