PostgreSQL vs MySQL в 2025: технический выбор или дело привычки?

"PostgreSQL или MySQL?" — этот вопрос задают на собеседованиях, обсуждают на конференциях и спорят в комментариях к статьям. В 2025 году PostgreSQL обгоняет MySQL по популярности (45.55% против 41.09%) в опросах разработчиков, получает титул "СУБД года" и считается более "продвинутым" выбором. Но MySQL всё ещё работает на миллиардах установок, остаётся первым выбором для WordPress и Laravel, и компании типа Uber предпочли его PostgreSQL.

Так в чём дело? Это технический выбор основанный на реальных преимуществах, или просто привычка и инерция экосистемы?

Спойлер: реальность сложнее чем "PostgreSQL лучше во всём".

Производительность: война бенчмарков

Поиск в Google по запросу "PostgreSQL vs MySQL performance" даёт противоречивые результаты. Одни тесты показывают что PostgreSQL в 4.7 раза быстрее MySQL. Другие говорят что разница максимум 30% и зависит от конкретной нагрузки. Третьи утверждают что MySQL быстрее для операций чтения.

Истина в том что производительность зависит от сотни факторов: версия базы данных, конфигурация, железо, характер запросов, индексы, схема данных. Тест который показывает пятикратное преимущество PostgreSQL в финансовых транзакциях может показать обратный результат на read-heavy веб-приложении.

Недавнее исследование на одинаковом железе и конфигурациях показало: для простых SELECT без условий PostgreSQL быстрее на 10-15%. Для SELECT с WHERE PostgreSQL быстрее примерно в 10 раз. Для INSERT разница минимальна. Но это всё синтетические тесты на упрощённых данных.

В реальном мире правда скучнее. Как отмечают эксперты: "Для большинства нагрузок производительность PostgreSQL и MySQL сопоставима с вариацией максимум 30%. С другой стороны, если ваш запрос пропустил индекс, это может быть деградация в 10-1000 раз независимо от базы данных."

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

MySQL всё ещё быстрее для чтения

Это не миф. MySQL с InnoDB и правильной настройкой кеширования действительно быстрее обрабатывает read-heavy нагрузки. Именно поэтому WordPress, Drupal, популярные CMS продолжают использовать MySQL как базу по умолчанию. Для блога который обслуживает 10,000 просмотров страниц в минуту и 10 записей в час, MySQL показывает отличные результаты.

PostgreSQL выигрывает в сложных запросах. Window functions, рекурсивные CTE, сложные JOIN с подзапросами — здесь query optimizer PostgreSQL показывает своё превосходство. Если ваше приложение строит сложную аналитику, агрегации по множеству таблиц, PostgreSQL может быть быстрее на порядок благодаря лучшей оптимизации плана запроса.

История Uber: когда PostgreSQL не справился

В 2016 году Uber опубликовал детальный разбор миграции с PostgreSQL на MySQL. Статья вызвала бурную дискуссию в сообществе, и многие обвинили Uber в необъективности. Но давайте посмотрим на факты.

Проблемы Uber с PostgreSQL были реальными. Они использовали PostgreSQL 9.2 (древняя версия даже по меркам 2016 года) и столкнулись с write amplification. Каждое обновление строки создавало новую версию и требовало обновления всех индексов. У Uber были таблицы с сотнями (!) индексов. Обновление одного поля генерировало гигантский объём операций записи.

Репликация тоже была болезненной. PostgreSQL 9.2 использовал физическую репликацию через WAL, который записывал каждое изменение на уровне страниц диска. Объём данных репликации был огромен, обновления версий требовали даунтайма, cascade replication был сложен.

MySQL с InnoDB решал эти проблемы элегантнее. Вторичные индексы хранят ссылку на первичный ключ, а не на физическое расположение строки на диске. При обновлении поля которое не входит в индекс, этот индекс вообще не трогается. Логическая репликация через binlog компактнее и гибче.

Но вот важный контекст: многие проблемы Uber решены в современных версиях PostgreSQL. Логическая репликация появилась в PostgreSQL 10. Инструменты типа pg_rewind упростили failover. Hot Standby позволяет запросам на репликах работать одновременно с репликацией. Проблема коррупции данных минимизирована.

Остаётся write amplification при большом количестве индексов. Но тут вопрос: нужны ли вообще сотни индексов на одной таблице? Критики справедливо замечают: "Почему у вас столько индексов? Вы реально делаете запросы по всем этим полям?"

Uber построили Schemaless — шардинг-слой поверх MySQL. Интересно что внутри Uber к Schemaless относились неоднозначно: "Schemaless был... так себе. Никто особо не любил его использовать, никто особо не понимал как он работает, и нельзя было запустить собственный инстанс."

Мораль истории: миграция Uber была оправдана их конкретными проблемами на конкретной версии PostgreSQL с конкретной архитектурой (сотни индексов). Но экстраполировать это на "MySQL лучше PostgreSQL" неправильно. Instagram и Notion успешно используют PostgreSQL на гораздо большем масштабе.

Лицензирование: скрытая проблема

Технари часто игнорируют лицензирование. Но для бизнеса это может быть критично.

PostgreSQL использует лицензию типа MIT/BSD. Вы можете делать с ним всё что угодно: модифицировать, встраивать в коммерческий продукт, распространять в closed-source софте. Никаких ограничений. Именно поэтому многие коммерческие продукты выбирают PostgreSQL как встроенную базу данных.

MySQL под GPL-2. Это copyleft лицензия. Если вы распространяете софт с MySQL, вы обязаны сделать исходный код доступным под GPL или GPL-совместимой лицензией. Для SaaS это не проблема — вы не распространяете софт, вы предоставляете сервис. Но если делаете десктоп-приложение или встроенную систему, GPL создаёт проблемы.

Oracle предлагает коммерческую лицензию за деньги, которая снимает ограничения GPL. Но многие разработчики проприетарного софта просто выбирают PostgreSQL чтобы избежать этих сложностей.

Есть ещё психологический фактор. MySQL принадлежит Oracle. Для некоторых компаний это красный флаг. Oracle — крупная коммерческая корпорация с репутацией агрессивного лицензирования. Именно поэтому появился MariaDB — форк MySQL без Oracle. PostgreSQL принадлежит сообществу через PostgreSQL Global Development Group, что для многих привлекательнее.

Продвинутые фичи: где PostgreSQL вырывается вперёд

PostgreSQL заслужил репутацию "более продвинутой" базы данных не просто так. Набор возможностей действительно шире.

Типы данных и расширяемость

PostgreSQL поддерживает массу нестандартных типов данных из коробки: JSON/JSONB (с индексами!), массивы, hstore (key-value в колонке), XML, UUID, геометрические типы, сетевые адреса (inet, cidr, macaddr), полнотекстовый поиск, диапазоны (daterange, int4range). Но главное — вы можете создавать собственные типы данных.

Финтех приложение может создать тип "currency" с правилами валидации и операторами. Геймдев студия может создать тип для игровых координат. Это мощная возможность которой нет в MySQL.

MySQL ограничен стандартными типами. Есть JSON, но без индексации и с ограниченными операторами. Нет массивов, нет кастомных типов, нет полноценного full-text search (есть базовый, но не сравнить с PostgreSQL).

PostGIS и геопространственные данные

Если ваше приложение работает с картами, локациями, геопространственными запросами — выбор очевиден. PostGIS для PostgreSQL — это индустриальный стандарт. Uber, Lyft, доставки еды, логистика — все используют PostGIS.

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

Row Level Security

PostgreSQL поддерживает RLS из коробки. Вы определяете политики доступа на уровне строк прямо в базе данных. Например: пользователь может видеть только свои заказы, менеджер может видеть заказы своего отдела, администратор видит всё.

В MySQL это нужно реализовывать на уровне приложения или через views, что сложнее и менее надёжно.

Транзакционный DDL

PostgreSQL позволяет выполнять DDL (ALTER TABLE, CREATE INDEX и т.д.) внутри транзакции. Если что-то пойдёт не так — откат. Это критично для безопасных миграций схемы.

MySQL поддерживает INSTANT/INPLACE/COPY алгоритмы для ALTER TABLE, что хорошо. Но транзакционный DDL отсутствует. Если ALTER TABLE упал посередине — у вас проблемы.

Но MySQL проще

Вот в чём MySQL выигрывает безоговорочно: простота. Установка, базовая настройка, первый проект — всё проще и быстрее. PostgreSQL мощнее, но сложность — цена этой мощности.

Репликация в MySQL настраивается проще. Master-slave через binlog работает из коробки. В PostgreSQL нужно разбираться с primary_conninfo, слотами репликации, standby.signal файлами. Для опытного DBA это не проблема. Для джуниора или небольшой команды — барьер входа.

Экосистема инструментов для MySQL больше и зрелее. Percona Toolkit, pt-online-schema-change, gh-ost, множество GUI админок. Для PostgreSQL тоже есть инструменты (pgAdmin, pg_badger), но выбор меньше и многие решения моложе.

Хостинг-провайдеры. Откройте любой shared hosting — там MySQL. Хотите поднять WordPress на дешёвом хостинге за $5 в месяц? MySQL там будет по умолчанию. PostgreSQL нужно искать, часто платить дороже или использовать VPS.

Документация и Stack Overflow. Для MySQL миллионы ответов на типичные вопросы. Для PostgreSQL тоже много, но MySQL выигрывает количеством.

Реальный выбор: исходя из задачи

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

Выбирайте PostgreSQL если

1. Ваше приложение строит сложную аналитику. Много JOIN, window functions, рекурсивные запросы. Query optimizer PostgreSQL действительно лучше справляется со сложными планами запросов.
2. Нужны продвинутые типы данных. JSONB с индексами, массивы, кастомные типы, full-text search, геопространственные запросы через PostGIS.
3. Строгая консистентность данных критична. Транзакционный DDL, Row Level Security, более строгое соблюдение SQL стандартов.
4. Разрабатываете проприетарный продукт. BSD-like лицензия PostgreSQL не создаёт юридических проблем.
5. Ваша команда уже знает PostgreSQL. Экспертиза важнее теоретических преимуществ.

Выбирайте MySQL если

1. Read-heavy веб-приложение. Блог, новостной сайт, каталог продуктов. MySQL с хорошим кешированием отлично справляется.
2. Нужна простота. Небольшая команда, нет выделенного DBA, нужно быстро запустить проект. MySQL проще настроить и поддерживать.
3. Уже в экосистеме. Используете WordPress, Laravel, Drupal, другие PHP фреймворки где MySQL первоклассный гражданин.
4. Ограниченный бюджет на хостинг. Дешёвые shared hosting провайдеры предлагают MySQL по умолчанию.
5. Ваша команда знает MySQL. Опять же — экспертиза побеждает.

Используйте оба

Серьёзно. Для сложных систем гибридный подход может быть оптимален. Транзакционные данные, пользователи, заказы — PostgreSQL с его строгой консистентностью и ACID гарантиями. Кеш, сессии, простые справочники — MySQL для скорости чтения. Логи, временные ряды — специализированные решения типа ClickHouse или TimescaleDB.

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

Скрытая правда: инерция экосистемы

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

Разработчик знает MySQL потому что учился на LAMP стеке и делал десятки WordPress сайтов. Когда приходит время выбирать базу данных для нового проекта, MySQL — очевидный выбор. Комфортно, знакомо, быстро.

Другой разработчик пришёл в индустрию через Django или Rails, где PostgreSQL — рекомендуемая база данных. Heroku предлагает PostgreSQL из коробки. Для него PostgreSQL — естественный выбор.

Компания уже имеет экспертизу в PostgreSQL. DBA знают его наизнанку, настроили мониторинг, отладили бэкапы, написали скрипты для типичных операций. Переходить на MySQL значит выбросить годы накопленного опыта.

Стартап выбирает PostgreSQL потому что основатели читали Hacker News и "все крутые ребята" используют Postgres. Или выбирают MySQL потому что хотят быстро запустить MVP на Laravel и не париться с настройкой.

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

Производительность на практике: что реально важно

Да, PostgreSQL может быть быстрее в синтетических тестах. Да, MySQL может показывать лучшие результаты для чтения. Но в продакшене разница между хорошо настроенным PostgreSQL и хорошо настроенным MySQL часто незаметна для пользователя.

Что реально влияет на производительность:

Индексы. Пропущенный индекс на часто используемом WHERE условии убивает производительность в 100-1000 раз. Неважно PostgreSQL у вас или MySQL.

Схема данных. Денормализация где нужно, правильные типы полей, разумное использование JOIN vs денормализации. Плохо спроектированная схема тормозит любую базу данных.

Конфигурация. PostgreSQL из коробки настроен консервативно. shared_buffers нужно повысить до 25% RAM. work_mem, effective_cache_size, checkpoint параметры — всё требует настройки под вашу нагрузку. MySQL тоже — innodb_buffer_pool_size должен быть 70-80% RAM для выделенного сервера.

Железо. SSD vs HDD это разница в разы. Достаточно RAM для кеширования рабочего набора данных критично. Медленные диски убьют любую базу данных.

Connection pooling. PostgreSQL создаёт процесс на каждое соединение, что дороже чем потоки в MySQL. Для продакшена нужен pgBouncer или подобный пулер. Для MySQL тоже полезен пулинг при высоком конкурренте.

Оптимизация этих аспектов даст гораздо больше чем переход с MySQL на PostgreSQL или обратно.

Современные тренды и будущее

PostgreSQL набирает обороты. Stack Overflow Developer Survey показывает что PostgreSQL обогнал MySQL и стал самой "любимой" базой данных. DB-Engines Ranking даёт PostgreSQL титул "СУБД года 2023". Новые стартапы чаще выбирают PostgreSQL.

Почему? Несколько факторов. Облачные провайдеры (AWS RDS, Google Cloud SQL, Azure Database) одинаково хорошо поддерживают обе базы данных, убирая преимущество MySQL в простоте setup. Современные фреймворки (Django, Rails, Laravel) работают отлично с обеими базами. Продвинутые фичи PostgreSQL становятся нужны всё большему количеству приложений.

Но MySQL не сдаётся. MySQL 8.0 и 9.0 добавили много улучшений: window functions, CTE, улучшенный JSON support, descending indexes. Oracle вкладывает ресурсы в развитие. Огромная установленная база гарантирует что MySQL никуда не денется.

MariaDB пытается быть "лучшим MySQL чем MySQL", добавляя фичи и убирая Oracle из уравнения. Percona Server — ещё один форк с фокусом на производительность.

Облачные нативные форки меняют правила игры. Amazon Aurora совместим с MySQL и PostgreSQL API, но внутри это совершенно другая архитектура с разделением storage и compute. CockroachDB, YugabyteDB, TiDB используют PostgreSQL-совместимый API но обеспечивают горизонтальное масштабирование.

Главные выводы

PostgreSQL и MySQL — обе отличные базы данных. Спор "какая лучше" бессмыслен без контекста конкретной задачи.

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

MySQL проще и быстрее для типичных веб-приложений. Легче настроить, больше экосистема, отлично справляется с read-heavy нагрузками. Если делаете блог, CMS, простое веб-приложение — MySQL работает превосходно.

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

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

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

И наконец: не стоит недооценивать силу "просто работает". Если ваше приложение успешно работает на MySQL уже пять лет, не стоит мигрировать на PostgreSQL только потому что "все говорят что он лучше". Работающая система лучше теоретически оптимальной.

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