PostgreSQL или MySQL: что выбрать для проекта в 2026 году

Коротко: PostgreSQL или MySQL — выбор по модели данных и окружению проекта. PostgreSQL — выбор по умолчанию для новых продуктов со сложной логикой, аналитикой, геоданными, ИИ-поиском и требованиями импортозамещения (через Postgres Pro). MySQL — для сайтов на WordPress и PHP-CMS, типовых веб-приложений с упором на чтение и команд, которым важна простота администрирования. На небольших нагрузках разница в скорости незаметна — решают модель данных, экосистема и опыт команды.

База данных — самая «тяжёлая» часть технологического стека. Фреймворк или библиотеку интерфейса можно заменить за несколько спринтов, а смена СУБД в живом продукте означает перенос данных, переписывание запросов и хранимой логики, повторное тестирование и риск простоя. Поэтому, когда мы обсуждаем с клиентами создание сайтов и веб-сервисов под ключ, вопрос «на какой базе строим» решается на этапе архитектуры, вместе с выбором языка и хостинга. Для реляционных данных в финал почти всегда выходят два кандидата — PostgreSQL и MySQL.

Ниже — сравнение без фанатизма: что представляет собой каждая СУБД, сводная таблица по тринадцати критериям, архитектура и транзакции, производительность на разных типах нагрузки, возможности SQL и JSON, масштабирование, сценарии выбора, лицензии и импортозамещение, актуальные версии на 2026 год, миграция, частые ошибки, чек-лист и ориентиры по стоимости. Материал написан для владельцев продуктов, CTO и менеджеров, которые выбирают подрядчика и хотят понимать, почему им предлагают ту или иную базу. Если вы ещё не определились, нужна ли вам реляционная СУБД вообще, сначала прочитайте, как вообще выбрать базу данных для приложения.

Что такое PostgreSQL и кто его использует?

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

Корни PostgreSQL уходят в исследовательский проект POSTGRES Калифорнийского университета в Беркли, а под нынешним именем и как открытый проект СУБД развивается с 1996 года. За это время вокруг неё сложилось большое сообщество и множество коммерческих сборок. PostgreSQL распространяется под разрешительной лицензией PostgreSQL License, похожей на BSD и MIT: её можно использовать, менять и встраивать в коммерческие продукты без отчислений и без обязанности раскрывать собственный код.

Отличительная черта PostgreSQL — расширяемость. Помимо обычных таблиц, он из коробки работает с массивами, диапазонами, JSONB, полнотекстовым поиском, а расширения добавляют геоданные (PostGIS), векторный поиск для ИИ (pgvector), временные ряды и распределённые таблицы. Поэтому одна база PostgreSQL часто закрывает задачи, для которых в других стеках поднимают несколько разных хранилищ. Если вас интересует, когда реляционная модель вообще уступает документной или key-value, это мы разбирали в материале «SQL vs. NoSQL».

У проекта предсказуемый цикл релизов: новая мажорная версия выходит примерно раз в год, каждая поддерживается пять лет, а минорные исправления выпускаются минимум раз в три месяца — это зафиксировано в политике версионирования PostgreSQL. Актуальная ветка — PostgreSQL 18, вышедшая 25 сентября 2025 года. PostgreSQL используют финтех-компании и банки, SaaS-платформы, аналитические системы, геосервисы, а в госсекторе — через российскую сборку Postgres Pro из реестра отечественного ПО.

Популярность PostgreSQL среди разработчиков продолжает расти. По данным опроса Stack Overflow Developer Survey 2026, PostgreSQL используют 57,9% респондентов в разделе баз данных, MySQL — 35,1%. А в опросе 2025 года PostgreSQL, как и в предыдущие годы, стал самой «желанной» и «восхищающей» СУБД — той, с которой разработчики больше всего хотят работать и которой довольны те, кто уже работает.

Что такое MySQL и где он силён?

MySQL — это реляционная СУБД с открытым исходным кодом, которая заслужила репутацию быстрой и простой в эксплуатации базы для веба: она лежит в основе классического стека LAMP (Linux, Apache, MySQL, PHP) и является стандартной СУБД для WordPress и большинства PHP-CMS.

MySQL появился в 1995 году, а с 2010 года принадлежит корпорации Oracle. Его архитектурная особенность — сменные движки хранения (storage engines): одна и та же СУБД может хранить таблицы по-разному. По умолчанию используется транзакционный движок InnoDB с поддержкой ACID, блокировок на уровне строк и внешних ключей. Community-версия MySQL распространяется под GPLv2, а для встраивания в закрытые продукты и для Enterprise Edition Oracle предлагает коммерческую лицензию.

Сильные стороны MySQL — низкий порог входа, быстрые простые запросы на чтение, лёгкая настройка реплик для чтения и огромная база специалистов и хостинг-провайдеров. Практически любой виртуальный хостинг в России предлагает MySQL «из коробки», и под него написаны тысячи готовых решений.

У MySQL две ветки релизов. LTS-ветки (долгосрочная поддержка) получают пять лет основной и три года расширенной поддержки по политике Oracle и подходят для стабильного продакшена. Innovation-ветки выходят чаще, содержат новые функции и поддерживаются только до следующего Innovation-релиза — они рассчитаны на команды с отлаженным CI/CD. Сейчас LTS-ветки — 8.4 и 9.7, описание модели есть в документации MySQL. Ветка 8.0, на которой до сих пор работает много проектов, в апреле 2026 года лишилась расширенной поддержки.

MariaDB — третий вариант

MariaDB — форк MySQL, который развивает один из создателей MySQL. Долгое время MariaDB была почти полной заменой MySQL: совпадали протокол, утилиты и большинство запросов, и многие Linux-дистрибутивы поставляют её вместо MySQL. Но за годы ветки разошлись — различаются оптимизаторы, работа с JSON, системные таблицы и часть функций. Если вы планируете переезд между MySQL и MariaDB в любую сторону, совместимость нужно проверять на тестовом стенде так же тщательно, как при переходе на другую СУБД.

Сравнение PostgreSQL и MySQL: таблица

Сравнение PostgreSQL vs MySQL удобно свести в одну матрицу. Оценки в ней качественные: универсальных цифр вида «одна СУБД быстрее в N раз» не существует — результат зависит от схемы данных, индексов, настроек, железа и характера нагрузки.

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

Чем отличаются архитектура и работа с транзакциями?

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

Движки хранения и ACID

В MySQL слой SQL отделён от слоя хранения: таблица может использовать InnoDB, MyISAM или другой движок. Сегодня практически все проекты работают на InnoDB — он транзакционный, поддерживает внешние ключи и блокировки на уровне строк. Наследие старых движков иногда встречается в legacy-проектах: таблицы на MyISAM не поддерживают транзакции, и это частый источник «потерянных» данных при сбоях.

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

MVCC и конкурентный доступ

Обе СУБД используют MVCC — многоверсионное управление конкурентным доступом: читатели не блокируют писателей, а каждая транзакция видит согласованный снимок данных. Реализация различается. PostgreSQL при обновлении строки создаёт её новую версию прямо в таблице, а старые версии со временем удаляет фоновый процесс VACUUM (обычно в режиме autovacuum). InnoDB хранит предыдущие версии в отдельном undo-логе и обновляет строку на месте.

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

Модель соединений

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

Какая СУБД быстрее: PostgreSQL или MySQL?

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

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

Классический сценарий веб-сайта — множество коротких запросов на чтение по первичному ключу или простому индексу: открыть карточку товара, статью, профиль пользователя. На таких операциях MySQL с InnoDB традиционно очень быстр: кластерный индекс по первичному ключу хранит строки рядом с ключом, а модель «поток на соединение» дёшево обслуживает множество коротких подключений. Добавьте простую настройку read-реплик — и получите проверенную схему для контентных проектов и интернет-магазинов с упором на чтение.

Где обычно выигрывает PostgreSQL

Чем сложнее запросы, тем заметнее преимущества PostgreSQL. Его оптимизатор умеет выбирать между разными алгоритмами соединения таблиц, хорошо справляется с запросами из множества JOIN, подзапросами и CTE, а параллельное выполнение запросов позволяет задействовать несколько ядер процессора для одного тяжёлого отчёта. Богатый выбор типов индексов — B-tree, GIN, GiST, BRIN и другие — помогает ускорить поиск по JSON, полнотекстовый поиск и выборки по геоданным. При интенсивной конкурентной записи — например, в учётных и платёжных системах — PostgreSQL ведёт себя предсказуемо.

Почему не стоит выбирать по бенчмаркам

В интернете легко найти тесты, где одна СУБД «в разы» обгоняет другую, — и тесты с противоположным результатом. Причина в том, что производительность определяют не столько сама СУБД, сколько схема данных, индексы, настройки памяти, версия, железо и характер запросов. Тест, проведённый с настройками по умолчанию на чужой схеме, мало говорит о вашем продукте.

Для большинства бизнес-проектов — интернет-магазина, CRM, личного кабинета, корпоративного портала — скорость СУБД вообще не становится узким местом. Тормоза чаще дают отсутствующие индексы, запросы в цикле, неоптимальная работа ORM и отсутствие кэша. Об этом подробно — в материале о том, как ускорить веб-приложение: узкое место чаще в запросах и кэше, а не в выборе СУБД. Если производительность критична, правильный путь — прототип на ваших данных и нагрузочное тестирование обоих вариантов.

SQL, JSON и расширения: в чём разница возможностей?

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

SQL-стандарт. Общие табличные выражения (CTE), в том числе рекурсивные, и оконные функции есть в обеих СУБД — в MySQL они появились в версии 8.0. Но в PostgreSQL этот инструментарий шире: больше видов оконных функций и агрегатов, ограничения-исключения, частичные индексы, индексы по выражениям, транзакционный DDL. Для аналитических запросов и отчётов это значит меньше обходных решений на стороне приложения.

JSON. PostgreSQL хранит документы в типе JSONB — в бинарном разобранном виде — и позволяет строить по ним GIN-индексы, так что поиск по полям внутри документа работает быстро. Это позволяет совмещать реляционную модель с гибкими атрибутами: например, хранить характеристики товаров разных категорий без десятков отдельных таблиц. В MySQL есть тип JSON с функциями для работы с ним и индексы по вычисляемым выражениям, а в MySQL 9.7 в Community Edition появилась возможность изменять данные через JSON Duality Views — представления, которые отдают реляционные данные как JSON-документы.

Типы данных. PostgreSQL поддерживает массивы, диапазоны (например, интервалы дат для бронирований с проверкой пересечений на уровне базы), нативный UUID, перечисления, сетевые адреса и позволяет создавать собственные типы. В MySQL набор типов стандартный, и многие из этих задач решаются в коде приложения.

Расширения. Главный козырь PostgreSQL — экосистема расширений. PostGIS превращает его в полноценную геоинформационную базу: расстояния, зоны доставки, поиск ближайших объектов. pgvector добавляет хранение эмбеддингов и векторный поиск для ИИ-функций. Есть расширения для временных рядов и для распределения таблиц по нескольким серверам (класс решений вроде TimescaleDB и Citus). Отдельная тема — индексы: о том, чем отличаются B-tree, GIN, GiST и другие, мы писали в обзоре типов индексов в PostgreSQL.

Как масштабировать PostgreSQL и MySQL при росте?

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

1. Вертикальное масштабирование. Больше памяти, быстрые диски, больше ядер. Для большинства проектов этого хватает на годы, особенно в сочетании с правильными индексами и кэшем.
2. Реплики для чтения. Запись идёт на основной сервер, чтение распределяется по репликам. В MySQL репликация на основе binlog настраивается очень просто и десятилетиями используется в веб-проектах; есть также Group Replication для отказоустойчивых кластеров. В PostgreSQL есть физическая потоковая репликация на основе WAL — копия всего сервера — и логическая репликация, которая передаёт изменения отдельных таблиц и подходит для миграций и интеграций.
3. Партиционирование. Большие таблицы делятся на части — например, по месяцам. Обе СУБД поддерживают декларативное партиционирование, что упрощает архивацию старых данных и ускоряет запросы к свежим.
4. Шардинг. Данные распределяются по нескольким независимым серверам. Встроенного прозрачного шардинга нет ни у одной из СУБД, но есть известные инструменты: Vitess для MySQL и Citus для PostgreSQL. Это уровень крупных систем, и к нему стоит подходить, только когда остальные шаги исчерпаны.

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

Отдельно стоит сказать об управляемых базах данных (DBaaS). Крупные российские облачные провайдеры — Yandex Cloud, VK Cloud, Selectel, Timeweb Cloud — предлагают и PostgreSQL, и MySQL как управляемый сервис: резервное копирование, реплики, обновления минорных версий и мониторинг берёт на себя провайдер. Для небольшой команды без выделенного администратора баз данных это снимает бóльшую часть эксплуатационной рутины и отчасти выравнивает разницу в порогах входа. О том, как сравнивать провайдеров, — в материале про выбор облака.

Когда выбрать PostgreSQL?

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

1. Финтех и учётные системы с жёсткой целостностью. Платежи, биллинг, складской и финансовый учёт, бронирования. Строгие ограничения, транзакционный DDL, диапазоны с проверкой пересечений и предсказуемое поведение при конкурентной записи помогают не допустить расхождений в данных.
2. SaaS и B2B-платформы со сложной бизнес-логикой и отчётами. Многопользовательские системы с ролями, настраиваемыми полями, аналитическими дашбордами. Сильный оптимизатор и JSONB позволяют совмещать строгую модель с гибкими атрибутами клиентов.
3. Геосервисы. Доставка и логистика, агрегаторы недвижимости, такси, сервисы поиска ближайших точек. PostGIS даёт расчёт расстояний, зон и маршрутов прямо в базе, без отдельной геоинформационной системы.
4. ИИ-функции и векторный поиск. Чат-бот по базе знаний компании, семантический поиск по каталогу, рекомендации. pgvector позволяет хранить эмбеддинги рядом с обычными данными и строить RAG-поиск без отдельной векторной базы на старте.
5. Госсектор и крупный бизнес с требованием импортозамещения. Если заказчику нужна СУБД из реестра российского ПО, практический путь — Postgres Pro, совместимый с PostgreSQL. Разработка на PostgreSQL изначально упрощает такой переход.

Общий признак: продукт сложнее, чем «каталог и формы», и будет развиваться годами. Если вы узнаёте свой проект в двух-трёх пунктах, PostgreSQL — сильный кандидат.

Когда выбрать MySQL?

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

1. Сайт на WordPress или другой PHP-CMS. WordPress официально поддерживает MySQL и MariaDB, под них написаны ядро, темы и плагины. 1С-Битрикс и большинство популярных PHP-CMS тоже исторически работают с MySQL. Здесь выбор СУБД фактически делает платформа; сравнение самих платформ — в материале «WordPress, Битрикс или кастомная разработка».
2. Типовой интернет-магазин и контентный проект с упором на чтение. Каталог, карточки, статьи, поиск по фильтрам — много коротких чтений и сравнительно мало сложной записи. MySQL с кэшем и репликами отлично справляется с такой нагрузкой.
3. Существующий LAMP-проект и команда с экспертизой MySQL. Если продукт уже работает на MySQL и не упирается в его ограничения, менять СУБД ради моды нет смысла. Опыт команды в настройке и отладке конкретной базы стоит дороже теоретических преимуществ другой.
4. MVP с быстрым запуском на недорогом хостинге. MySQL есть практически на любом виртуальном хостинге и в любой панели управления, а инструкций по нему больше всего. Для простого MVP на PHP это самый короткий путь к работающему продукту.
5. Проект, которому нужен простой набор read-реплик. Если масштабирование сводится к «одна запись — несколько чтений», репликация MySQL настраивается быстро и предсказуемо, а специалистов, которые с ней работали, много.

Общий признак: продукт опирается на готовую экосистему и типовые сценарии веба. Если ваш проект попадает в два-три пункта, MySQL — разумный выбор.

Что важно для российских компаний: лицензии и импортозамещение?

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

Лицензии. PostgreSQL License — разрешительная: продукт на PostgreSQL можно продавать, распространять и встраивать без отчислений и без обязанности раскрывать свой код. MySQL Community распространяется под GPLv2; это важно, если вы распространяете ПО со встроенной СУБД — например, поставляете коробочный продукт заказчикам. Для SaaS, работающего на ваших собственных серверах, GPL обычно не создаёт ограничений, но в каждом конкретном случае условия стоит уточнить у юриста: эта статья не является юридической консультацией.

Реестр российского ПО. Postgres Pro — форк PostgreSQL, который развивает российская компания Postgres Professional, — включён в реестр российского программного обеспечения. Поэтому госкомпании и организации с требованиями к импортозамещению при уходе с зарубежных СУБД переходят именно на Postgres Pro, а не на «ванильный» PostgreSQL. Пример — перевод государственных информационных систем Федерального казначейства на Postgres Pro Enterprise. Приложение, изначально написанное под PostgreSQL, переезжает на Postgres Pro заметно проще, чем система на другой СУБД.

Риск вендора. MySQL — продукт Oracle, которая ушла с российского рынка. Community-версия остаётся доступной как открытое ПО, но получить коммерческую поддержку Oracle для российского проекта сейчас нельзя. Компании, которые остаются на MySQL, опираются на собственную экспертизу, на MariaDB или на управляемые сервисы российских облаков, где эксплуатацию берёт на себя провайдер. Если перед вашей компанией стоит задача перевести информационные системы на отечественный стек, посмотрите, как устроено импортозамещение ПО — от аудита до миграции.

Какие версии актуальны в 2026 году и когда обновляться?

В конце 2026 года актуальны PostgreSQL 18 и 17, а также MySQL 9.7 LTS и 8.4 LTS; ветка MySQL 8.0 осталась без поддержки в апреле 2026 года, а поддержка PostgreSQL 14 заканчивается 12 ноября 2026 года. Если ваш проект работает на одной из этих двух веток, обновление пора планировать.

Источники: политика версий PostgreSQL, разбор окончания поддержки MySQL 8.0 от Percona, обзоры релиза MySQL 9.7 LTS на InfoQ и в блоге Bytebase. В 9.7 в Community Edition пришли Hypergraph Optimizer и изменение данных через JSON Duality Views, а также улучшена наблюдаемость репликации.

Если у вас PostgreSQL 14. После 12 ноября 2026 года для этой ветки перестанут выходить исправления, в том числе по безопасности. Минорные обновления внутри одной ветки — это замена бинарных файлов и перезапуск, а переход на новую мажорную версию выполняется через pg_upgrade или выгрузку и загрузку данных (dump/restore). Порядок действий: поднять тестовый стенд с копией базы на целевой версии (разумно сразу на 17 или 18), проверить приложение и расширения, замерить время обновления, подготовить резервную копию и план отката.

Если у вас MySQL 8.0. Oracle рекомендует переходить на 8.4 LTS или 9.7 LTS. Важная особенность модели LTS — пропускать LTS-серию при обновлении нельзя: путь 8.4 → 9.7 поддерживается, а прыжок «через голову» — нет. Поэтому с 8.0 обычно сначала переходят на 8.4, а затем при необходимости на 9.7. Проверьте на стенде устаревшие параметры конфигурации, плагины аутентификации и поведение запросов, и только потом обновляйте рабочий сервер.

Стоит ли мигрировать с MySQL на PostgreSQL?

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

Когда миграция оправдана: продукту нужны геоданные или векторный поиск; аналитические запросы стали тяжёлыми, и обходные решения в коде множатся; растёт доля полуструктурированных данных в JSON; заказчик или регулятор требует СУБД из реестра; проект переписывается и всё равно меняет архитектуру.

Когда не стоит: продукт построен на PHP-CMS, которая официально поддерживает только MySQL; система стабильна и не упирается в возможности базы; у команды нет экспертизы PostgreSQL, а сроки сжатые. Правило «работает — не трогайте» здесь вполне применимо: миграция — это проект со своим бюджетом и рисками.

Если решение принято, перенос обычно проходит в шесть шагов:

1. Аудит схемы и запросов. Составьте инвентарь таблиц, типов данных, индексов, хранимых процедур, триггеров и запросов, которые приложение отправляет в базу, включая сырые SQL-запросы вне ORM.
2. Выбор инструмента переноса. Подберите инструмент переноса, например open-source утилиту pgloader, и проверьте её на копии базы, а не на рабочем сервере.
3. Конвертация типов и диалекта SQL. Замените AUTO_INCREMENT на identity-столбцы, приведите типы данных, кавычки, регистр имён и специфичные функции MySQL к синтаксису PostgreSQL, перепишите хранимые процедуры.
4. Перенос данных на тестовый стенд. Перенесите полную копию данных на отдельный стенд и сверьте количество строк, контрольные суммы и граничные значения — даты, кодировки, пустые строки и NULL.
5. Тесты и сравнение результатов. Прогоните автотесты и ключевые бизнес-сценарии, сравните результаты запросов и время ответа со старой базой.
6. Переключение и план отката. Переключите приложение в согласованное окно простоя или через временную репликацию, заранее подготовив и проверив план отката на старую базу.

Миграция СУБД часто идёт вместе с обновлением устаревшего кода и архитектуры: когда приложение всё равно приходится разбирать, логично заодно убрать накопленный технический долг. Как мы подходим к таким проектам — на странице модернизации legacy-систем.

Частые ошибки при выборе СУБД

Большинство проблем с базой данных возникает не из-за самой СУБД, а из-за того, как и почему её выбрали. Вот пять типичных ошибок.

1. Выбор по популярности. «Все сейчас переходят на PostgreSQL» или «MySQL стоит на половине сайтов» — не аргументы для конкретного продукта. Популярность говорит о зрелости экосистемы, но не о том, подходит ли СУБД под ваши данные и вашу команду.
2. Выбор по одному бенчмарку. Синтетический тест с настройками по умолчанию на чужой схеме почти ничего не говорит о поведении вашего продукта. Если производительность критична, тестируйте на своих данных и своих запросах.
3. Игнорирование модели данных. Геоданные, сложные связи, полуструктурированные атрибуты, временные интервалы, векторы — всё это сильно влияет на выбор. Модель данных стоит описать до того, как выбирать СУБД, а не после.
4. «Потом поменяем». Смена базы данных в живом продукте — один из самых дорогих видов рефакторинга: миграция данных, переписывание запросов и хранимой логики, повторное тестирование, окно простоя. Сэкономить неделю на анализе и потом потратить месяцы на миграцию — плохая сделка.
5. Неучтённый жизненный цикл версий. Запуск нового проекта на ветке, у которой поддержка заканчивается через полгода, — гарантированное внеплановое обновление вскоре после релиза. Проверяйте даты окончания поддержки и закладывайте обновления в план сопровождения.

Чек-лист: как выбрать между PostgreSQL и MySQL за 7 вопросов

Прежде чем утверждать СУБД — свою или предложенную подрядчиком, — ответьте на семь вопросов. Каждый ответ сдвигает выбор в одну из сторон.

1. Строится ли продукт на готовой CMS? WordPress, Битрикс или другая PHP-CMS — склоняет к MySQL. Собственная разработка с нуля — вопрос остаётся открытым, переходите к следующим пунктам.
2. Какой тип нагрузки преобладает? Много коротких чтений и мало сложной записи — MySQL справится отлично. Интенсивная конкурентная запись, транзакции с деньгами и остатками — плюс в сторону PostgreSQL.
3. Насколько сложны запросы и отчёты? Простые выборки по ключам — разницы нет. Многотабличные отчёты, аналитика, оконные функции, рекурсивные запросы — PostgreSQL.
4. Нужны ли геоданные или ИИ-поиск? Расстояния, зоны, карты, эмбеддинги и семантический поиск — PostgreSQL с PostGIS и pgvector.
5. Есть ли требования импортозамещения? Если нужна СУБД из реестра российского ПО — PostgreSQL-экосистема с переходом на Postgres Pro.
6. Какая экспертиза у команды? Глубокий опыт с одной из СУБД — весомый аргумент в её пользу, особенно при сжатых сроках.
7. Managed-сервис или свой сервер? В управляемом облачном сервисе разница в порогах входа сглаживается; на собственном сервере без администратора баз данных MySQL проще в эксплуатации.

Если по большинству пунктов ответы нейтральные, а продукт новый, — берите PostgreSQL как более универсальную основу. Выбор СУБД — только часть решения о стеке; о том, как подобрать язык, фреймворки и инфраструктуру вместе, читайте в материале о выборе технологического стека проекта, а соседнее сравнение для серверной части — в статье «Node.js или Python для бэкенда».

Сколько стоит разработка и поддержка на PostgreSQL и MySQL?

Лицензия community-версии обеих СУБД стоит 0 ₽, поэтому реальная разница в бюджете складывается не из самой базы, а из инфраструктуры, часов администраторов и DevOps-инженеров, тарифа управляемого сервиса и возможных миграций.

• Инфраструктура. Сервер или облачные ресурсы, хранилище для данных и резервных копий, реплики. Стоимость определяется объёмом данных и нагрузкой, а не выбором между PostgreSQL и MySQL.
• Эксплуатация. Резервное копирование, мониторинг, обновления, настройка производительности. На собственных серверах это часы DBA или DevOps-специалиста; в управляемом сервисе — часть тарифа провайдера.
• Разработка. Стоимость часа разработчика почти не зависит от СУБД: обе массовые, специалистов достаточно. Гораздо сильнее на бюджет влияет то, насколько команда знает выбранную базу: незнакомая СУБД — это время на обучение и ошибки.
• Миграции и обновления. Мажорные обновления раз в несколько лет и возможная смена СУБД — отдельные статьи расходов, которые стоит закладывать в план сопровождения заранее.

Ориентиры по срокам — качественные. Перенос небольшой базы без хранимой логики между PostgreSQL и MySQL обычно занимает от нескольких дней до пары недель, крупной системы с хранимыми процедурами, триггерами и интеграциями — месяцы. Плановое обновление мажорной версии на подготовленном стенде, как правило, укладывается в дни, но требует окна обслуживания. Надёжная эксплуатация базы — резервные копии, мониторинг, обновления по графику — это зона DevOps и сопровождения инфраструктуры.

Как YuSMP Group выбирает СУБД для проектов

Мы не держимся за одну базу данных: СУБД подбираем на этапе проектирования архитектуры — под модель данных, тип нагрузки, требования к импортозамещению и планы развития продукта, — и фиксируем решение с обоснованием, чтобы заказчик понимал, почему выбран именно этот вариант. В работе у нас оба стека: PostgreSQL — для продуктов со сложной логикой, отчётами, геоданными и ИИ-функциями, MySQL — для проектов на PHP-платформах и контентных сайтов.

Для эксплуатации чаще всего предлагаем управляемые базы данных в российских облаках, а при необходимости берём на себя обновление версий и миграции между СУБД. Если вы планируете новый продукт, посмотрите, как устроена разработка веб-приложений, а для многопользовательских сервисов по подписке — разработка SaaS.

Часто задаваемые вопросы

Что лучше для сайта на WordPress: PostgreSQL или MySQL?

Для WordPress выбирайте MySQL или совместимую с ним MariaDB: именно эти СУБД официально поддерживает движок, под них написаны ядро, темы и подавляющее большинство плагинов. Запустить WordPress на PostgreSQL можно только через сторонние прослойки, и это создаёт риски при каждом обновлении. Та же логика работает для большинства PHP-CMS: если продукт построен вокруг готовой системы, база данных определяется ею.

Что быстрее — PostgreSQL или MySQL?

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

Можно ли перейти с MySQL на PostgreSQL без переписывания приложения?

Частично. Если приложение работает через ORM — Django ORM, Eloquent в Laravel, ActiveRecord в Rails, — бóльшая часть кода переедет без изменений. Но сырые SQL-запросы, специфичные функции MySQL, хранимые процедуры, триггеры и некоторые типы данных придётся переписать. Безопасный путь — перенос на тестовый стенд, прогон автотестов и сравнение результатов до переключения рабочей системы.

PostgreSQL бесплатный для коммерческого использования?

Да. PostgreSQL распространяется под разрешительной лицензией PostgreSQL License, похожей на BSD и MIT: его можно использовать, изменять и встраивать в коммерческие продукты без отчислений. MySQL Community Edition тоже бесплатен, но распространяется под GPLv2, а для встраивания в закрытые продукты Oracle предлагает коммерческую лицензию. Если вы распространяете ПО со встроенной СУБД, уточните условия у юриста.

Какая СУБД подходит для импортозамещения?

На практике — экосистема PostgreSQL, и прежде всего Postgres Pro: этот форк от российской компании Postgres Professional включён в реестр российского ПО. Именно на него переводят системы госкомпании, которым важен статус в реестре, — например, Федеральное казначейство мигрирует государственные информационные системы на Postgres Pro Enterprise. Для коммерческих проектов без требований реестра подходит и обычный PostgreSQL.

Что выбрать для стартапа или MVP?

Если продукт пишется с нуля, PostgreSQL — разумный выбор по умолчанию: он закрывает и транзакционные задачи, и JSON, и геоданные, и векторный поиск, так что при росте не придётся менять базу. MySQL стоит взять, если MVP строится на WordPress или другой PHP-CMS либо команда глубоко знает MySQL и хочет запуститься быстрее. Главное — не менять СУБД после запуска без серьёзной причины.

Нужна ли отдельная векторная база для ИИ, или хватит PostgreSQL?

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

Что делать, если проект работает на MySQL 8.0?

Планировать обновление: расширенная поддержка MySQL 8.0 закончилась в апреле 2026 года, и исправления безопасности для этой ветки больше не выходят. Oracle рекомендует переходить на 8.4 LTS или 9.7 LTS. Делайте это через тестовый стенд: проверьте совместимость запросов, плагинов и настроек, прогоните тесты, подготовьте резервную копию и план отката, и только потом обновляйте рабочий сервер.

Вывод: PostgreSQL или MySQL

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

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

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