PostgreSQL или MySQL: какую базу данных выбрать для нового проекта

Для нового веб-проекта мы по умолчанию выбираем PostgreSQL: он строже к данным, богаче по возможностям — JSON, полнотекстовый поиск, расширения вроде PostGIS и pgvector — и позволяет дольше обходиться без дополнительных хранилищ. MySQL остаётся хорошим выбором, когда команда глубоко его знает, хостинг поддерживает только его или проект — классический сайт на CMS.

Разберём, в чём базы действительно различаются, а где разница давно стёрлась.

Чем PostgreSQL и MySQL отличаются в 2026 году?

PostgreSQL и MySQL отличаются прежде всего философией: PostgreSQL развивается как расширяемая объектно-реляционная база с упором на строгость и стандарты SQL, MySQL — как быстрая и простая в эксплуатации база для веб-приложений. За последние годы обе закрыли большинство пробелов, поэтому разница сместилась в экосистему расширений и поведение в сложных запросах.

Что было аргументом раньше и уже не является:

• «MySQL быстрее на простых запросах» — для типичного веб-приложения разница несущественна, узким местом становятся индексы и схема;
• «В MySQL нет оконных функций и CTE» — есть с версии 8.0;
• «PostgreSQL сложно администрировать» — управляемые облачные сервисы есть для обеих баз.

Какие возможности есть только в PostgreSQL?

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

Возможность	PostgreSQL	MySQL
JSON-документы с индексами	JSONB с GIN-индексами	JSON-тип, индексы через генерируемые столбцы
Частичные индексы	Есть	Нет
Полнотекстовый поиск	Встроенный, с морфологией и ранжированием	Встроенный, проще по возможностям
Геоданные	Расширение PostGIS — отраслевой стандарт	Базовая поддержка пространственных типов
Векторный поиск для AI	Расширение pgvector	Нет стандартного решения в сообществе
Транзакционные изменения схемы	Да, миграцию можно откатить целиком	Большинство DDL не откатываются
Массивы, диапазоны, перечисления	Нативные типы	Ограниченно

Пример частичного индекса, который часто выручает в продуктах: уникальность email только среди неудалённых пользователей.

CREATE UNIQUE INDEX users_email_active_unique
    ON users (lower(email))
    WHERE deleted_at IS NULL;

В MySQL ту же задачу приходится решать обходными путями — генерируемыми столбцами или проверкой в коде приложения.

Фото: Unsplash

Когда MySQL — разумный выбор?

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

Ситуации, где мы оставляем или выбираем MySQL:

• сайт на WordPress или другой CMS, изначально ориентированной на MySQL;
• существующий проект, где MySQL стабильно работает и не мешает развитию;
• команда заказчика годами администрирует MySQL и будет поддерживать базу сама;
• нагрузка — в основном простые чтения по первичному ключу, а богатые возможности не нужны.

Как выбор базы влияет на фреймворк и хостинг?

На выбор фреймворка база почти не влияет: Laravel, Django, Rails, NestJS и другие поддерживают обе через ORM. Но ORM сглаживает только базовые операции — как только проект использует JSONB, частичные индексы или полнотекстовый поиск, код привязывается к конкретной базе.

Что учесть при выборе хостинга

У всех крупных облачных провайдеров есть управляемые версии обеих баз — с автоматическими бэкапами, репликами и обновлениями. Проверьте заранее:

1. Какие версии базы доступны и как быстро провайдер выпускает новые.
2. Какие расширения PostgreSQL разрешены — pgvector и PostGIS есть не везде.
3. Как устроены бэкапы и восстановление на момент времени.
4. Сколько стоит реплика для чтения, если она понадобится.

Можно ли сменить базу данных потом?

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

Как обычно проходит миграция с MySQL на PostgreSQL:

1. Инвентаризация: какие запросы, типы и функции специфичны для MySQL.
2. Перенос схемы с адаптацией типов — например, TINYINT(1) в boolean, DATETIME в timestamptz.
3. Перенос данных инструментом вроде pgloader и сверка количества записей и контрольных сумм.
4. Прогон тестов и сравнение результатов ключевых запросов на обеих базах.
5. Переключение с окном обслуживания или через репликацию, с планом отката.

Поэтому выбор на старте важен: он определяет, какие возможности будут доступны продукту без дополнительной инфраструктуры.

Коротко

• Для нового продукта по умолчанию выбирайте PostgreSQL: строгость, JSONB, поиск, PostGIS и pgvector в одной базе.
• MySQL разумен для CMS-проектов, существующих систем и команд с сильной экспертизой в нём.
• Скорость на типичных веб-нагрузках не аргумент: решают индексы и схема.
• ORM сглаживает различия только до первого специфичного запроса.
• Смена базы потом возможна, но это отдельный проект с миграцией и тестированием.