19 августа 2026 года The Register опубликовал разговор с Майклом Стоунбрейкером — человеком, из чьего проекта в Беркли вырос PostgreSQL. Одна фраза разошлась по лентам за сутки: спасибо Oracle. По его словам, когда Oracle получила MySQL, рынок испугался, что теперь она будет решать судьбу этой базы, — и с этого испуга началось восхождение Postgres. Про сам MySQL он высказался резче: тот «исчезает как конкурент».
Я backend-разработчик, и у меня в проде живут обе базы: PostgreSQL под основную нагрузку и MySQL под сервисом, который пережил три переписывания фронтенда. Поэтому разложу по полкам без холивара: что изменилось, что Postgres даёт технически, где он неудобен, когда MySQL остаётся правильным ответом и во сколько обходится переезд.
Что именно сказал создатель Postgres
Цитата и её контекст
Стоунбрейкер — не блогер с мнением: это автор Ingres и Postgres, лауреат премии Тьюринга 2014 года. В интервью он говорит о двух вещах. Первая — про покупку: Oracle забрала MySQL вместе с Sun, рынок это напугал, и напуганные пошли смотреть на альтернативу. Вторая — про сегодняшний расклад: «все слоны», то есть Microsoft, Google и Amazon, поставили на сетевой протокол PostgreSQL, и совместимость с ним стала стандартом для новых облачных баз.
Мы должны сказать спасибо Oracle: когда они купили MySQL, все испугались, что теперь они будут решать, куда MySQL пойдёт, — и это стало началом восхождения PostgreSQL. Майкл Стоунбрейкер, The Register, 19 августа 2026 года
Насколько это подтверждается цифрами
Опрос разработчиков Stack Overflow за 2025 год: PostgreSQL используют 55,6% респондентов против 48,7% годом раньше, MySQL — 40,5%; первое место Postgres держит третий год подряд. Но есть вторая цифра, о которой молчат победные заголовки: в рейтинге DB-Engines к августу 2026 MySQL всё ещё выше PostgreSQL — там считается накопленная известность. Картина честнее так: Postgres выигрывает новые проекты, MySQL держит огромный установленный парк. «Все ушли» — про то, с чего начинают в 2026-м, а не про то, что MySQL исчез с дисков.
Как MySQL стал стандартом веба и что изменилось потом
Эпоха LAMP и хостинга за доллар
В двухтысячных выбор делался не по тестам, а по тому, что стояло у хостера. Стояло Linux + Apache + MySQL + PHP, и любая CMS ставилась в три клика. MySQL был быстрым на простых выборках и, главное, прощающим: в нестрогом режиме он молча превращал некорректное число в ноль, принимал дату 0000-00-00 и обрезал длинную строку. Для гостевой книги — удобство. Для биллинга — мина.
2008–2010: развилка, после которой всё разошлось
16 января 2008 года Sun объявила о покупке MySQL AB примерно за миллиард долларов, сделку закрыли 26 февраля. В феврале 2009-го из Sun ушёл Монти Видениус, один из основателей. В апреле 2009-го Oracle объявила о покупке самой Sun — в ЕС сделку одобрили в январе 2010-го. Ещё до её закрытия, 29 октября 2009 года, Видениус выпустил MariaDB 5.1.38 — форк, названный в честь дочери.
Дальше произошло не убийство, а размывание. MySQL не умер: InnoDB стал движком по умолчанию в 5.5, в 5.7 появились тип JSON и строгий режим, восьмёрка принесла оконные функции и CTE. Но сообщество разъехалось на три ветки — MySQL от Oracle, MariaDB и сборка Percona, — и на старте проекта приходилось сначала выбирать, какой именно «MySQL» имеется в виду. Само наличие этого вопроса стоило экосистеме дороже любой отдельной фичи.
Что технически даёт PostgreSQL
Строгие типы: база спорит с вами вовремя
Разница видна на скучном примере. Вставляем в целочисленную колонку строку «abc»: Postgres вернёт ошибку, старый MySQL в нестрогом режиме положит туда ноль — и вы узнаете об этом через полгода из отчёта, где не сходится сумма. Сверху идут проверочные ограничения (цена не бывает отрицательной — пусть это знает база, а не три сервиса), массивы, диапазонные типы, перечисления. Смысл не в чистоте, а в том, что ошибка ловится на тестах, а не в бухгалтерии.
Транзакции, в которые попадает и схема
Главное практическое отличие для меня — транзакционный DDL. В Postgres можно открыть транзакцию, выполнить пять ALTER TABLE и откатить всё одной командой: схема останется прежней. В MySQL изменение схемы неявно фиксирует транзакцию. Это разница между «миграция упала на шаге четыре из семи, откатились, разбираемся утром» и «упала на шаге четыре, база в промежуточном состоянии, чиним руками прямо сейчас».
JSON без второй базы рядом
Тип jsonb появился в PostgreSQL 9.4, вышедшей 18 декабря 2014 года. Он хранит документ в двоичном виде и, что важнее, индексируется: запрос «где настройки содержат plan: pro» уходит в GIN-индекс, а не перебирает таблицу. На практике это закрывает три вечных случая — пользовательские настройки, сырые ответы внешних API и поля, про которые продукт ещё не решил, чем они станут. Раньше ради них рядом ставили документное хранилище. Теперь чаще не нужно: один бэкап, один мониторинг, одна транзакция на всё.
Расширения и полнотекстовый поиск
Одна команда CREATE EXTENSION добавляет базе новую специальность. PostGIS отвечает на «найди точки в радиусе двух километров», pg_trgm ищет с опечатками, pgvector хранит эмбеддинги — поэтому Postgres второй раз выстрелил на волне ИИ. pg_stat_statements показывает, какие запросы съели процессорное время: это первое, что я открываю при жалобе на тормоза. Встроенный полнотекстовый поиск с русской морфологией для среднего сайта заменяет поисковый движок — минус один сервис в эксплуатации.
Честно о минусах: где Postgres неудобен
Из коробки он настроен скромно
Заводские настройки PostgreSQL рассчитаны на то, чтобы он запустился где угодно, вплоть до слабой виртуалки. Буферы, память на сортировку, лимит соединений, агрессивность автоочистки — всё это придётся трогать руками, и без понимания легко сделать хуже. MySQL 8 на типичной вебной нагрузке чаще прилично работает вообще без тюнинга — это реальное преимущество, когда админа в проекте нет.
Соединения стоят памяти
Postgres запускает отдельный процесс на каждое соединение. Несколько мегабайт на процесс плюс память на сортировки — и пятьсот открытых коннектов превращаются в задыхающийся сервер. Лечится известно как, PgBouncer или пул внутри приложения, но это ещё один компонент, который надо настроить и мониторить. MySQL с его моделью потоков переносит много соединений спокойнее.
Репликация и уборка мусора
Здесь историю надо признать честно. Встроенная потоковая репликация появилась в Postgres только в версии 9.0 в 2010 году, а логическая — в PostgreSQL 10 от 5 октября 2017 года; до этого её собирали внешними инструментами. MySQL со своим бинарным логом поднимал реплику «в две команды» на годы раньше, и операционный опыт вокруг неё до сих пор шире. Второй сюрприз — версионирование строк: старые версии копятся, их убирает автоочистка, и если про неё не знать, база однажды распухнет и встанет.
Когда MySQL и MariaDB — по-прежнему разумный выбор
Четыре ситуации, в которых я не стал бы дёргаться
Первая: база работает, данные целы, а болит только у архитектора, которому неловко на конференции. Это не техническая причина. Вторая: вы ставите готовое приложение — CMS, магазин, портал, — которое годами тестируют именно на MySQL; идти против стека вендора значит собрать баги, которых до вас никто не видел. Третья: модель данных простая, запросы однотипные, а команда знает MySQL наизусть. Четвёртая: MariaDB — живой самостоятельный форк, в проектах с импортозамещением часто уже одобренный.
И неприятное: в половине случаев, когда ко мне приходят с «база тормозит, надо менять», дело в отсутствующем индексе, запросе в цикле или отчёте, который каждый раз перечитывает пять лет истории. Смена СУБД такое не лечит — она это переносит.
Вопросы при выборе базы
Шесть вопросов, которые я задаю на старте
Первый: чего больше — чтения или записи, и какого чтения. Сложная аналитика, отчёты, соединения десятка таблиц — территория Postgres с его планировщиком. Поток простых выборок по ключу честно тянет и MySQL. Второй: нужны ли сложные запросы вообще — геоданные, полнотекст, JSON с индексами, обход дерева. Если да, список кандидатов схлопывается сам. Третий, главный: кто будет чинить это в три часа ночи. Четвёртый: что уже есть у хостера — управляемый сервис с бэкапами и репликой экономит месяцы админской работы. Пятый: сколько будет одновременных соединений и есть ли кому поставить пул. Шестой: цена ошибки в данных — для платежей строгие типы и транзакционные миграции окупают любую сложность настройки.
Почему «модная база» — плохая причина
«Все перешли» — не аргумент: за словом «все» стоят чужая нагрузка, чужой бюджет и чужая команда с профильными инженерами. Хорошая причина звучит скучно: мы умеем её чинить в три часа ночи. И проверяется за вечер — попросите дежурного без вас посмотреть список активных запросов, снять зависшую блокировку, оценить отставание реплики и поднять базу из вчерашнего бэкапа. Если ответ «не знаю, где это смотреть», модность не спасёт: в аварии решает скорость понимания, а не архитектурная красота.
Чего на самом деле стоит миграция между базами
На что закладываться
Перенос схемы и данных — самая простая часть: конвертеры есть, на среднем проекте это дни. Дорого стоит всё вокруг. Диалект SQL в коде: «вставить или обновить», склейка строк в группе, форматирование дат, обратные кавычки — переписывается вручную. Семантика: пустая строка против NULL, регистр и «ё» в сортировке, часовые пояса. Дальше — последовательности вместо автоинкрементов, самописные отчёты аналитиков, о которых расскажут в последний день, заново настроенные бэкапы и алерты, обучение дежурных, двойная запись, окно переключения и план отката.
Мой практический коэффициент: закладывайте два-три срока от первой оценки. Сюрпризы приходят не из данных — они предсказуемы, — а из кода вокруг них и из людей, годами писавших отчёты и выгрузки под поведение старой базы.
Порядок действий, если решились
Сначала посчитайте выигрыш в цифрах: какие запросы ускорятся, какие сервисы уйдут, сколько это сэкономит в месяц. Нет ответа в цифрах — нет миграции. Дальше: инвентаризация запросов по логу медленных, теневая копия и прогон на ней реального читающего трафика, репетиция переключения с секундомером, сам переезд с возможностью вернуться в течение суток, месяц двойного мониторинга. Репетировать удобно локально: поднять обе базы в контейнерах стоит вечера и снимает половину сюрпризов.
Что со всего этого взять
Стоунбрейкер прав в главном: рынок сдвинулся, и покупка MySQL компанией Oracle этому помогла — не запретами, а неопределённостью, которой хватило, чтобы люди начали смотреть по сторонам. PostgreSQL за пятнадцать лет догнал по удобству эксплуатации и обогнал по возможностям, а ставка облаков на его протокол сделала выбор безопасным на будущее.
Но из «все ушли» не следует «уходи и ты завтра». Для нового проекта PostgreSQL у меня стоит дефолтом — не потому, что о нём написали, а потому, что он ловит мои ошибки раньше клиента. Под работающим сервисом MySQL остаётся нормальной поддерживаемой базой, и сам по себе он не технический долг. Дефолт — да. Религия — нет.
Пока нет комментариев