Holywar: MySQL vs PostgreSQL
Немного предыстории. Прародитель MySQL увидел свет ещё в 1979-м году. Назывался он "Unireg" и был написан на... бейсике. В 1996-м году был выпущен MySQL 1.0. Postgres активно разрабатывался с 1986 по 1994 как работа для защиты учёной степени кандидата наук. Те, кто плотно работал с Oracle RDBMS отмечают эту разницу в почерке создателей: Oracle изначально был "коммерческим", а Postgres "академически-исследовательский" с сопутствующей разницой в функционале, фичах и поведении под нагрузкой.
Postgres изначально был более "навороченным", а потому более сложным в изучении и админстрировании. Но вместе с тем в него со старта заложена грамотная и очень хорошо продуманная архитектура. MySQL же развивался эволюционно по принципу "подклянчим вот тут, подклянчим вот здесь" от простого к сложному. За счёт этого он получил большее распространение, про него написали больше всяких мануалов и howto-шек, для его использования ниже входной порог. Поскольку MySQL меньше всего умеет, его и настраивать проще. Вот его и растащили активно всякие быдлокодеры PHPшники для WordPress-ов и иже с ними.
Что касается меня самого, то я сам пришёл в мир Postgres совсем недавно: где-то три-четыре года тому назад. До тех пор, боялся его. Он мне тогда казался каким-то дико сложным и непонятным. В MySQL просто: установил, задал пароль, выбрал движок для таблицы и вперде. В Postgres-е же какие-то там роли, схемы, владельцы, привилегии, шаблоны, WAL-ы, вакуумирование и всё вот это. Но зато после того как один раз разобрался, возвращаться на MySQL больше не хочу, разве что только под угрозой расстрела.
Во-первых, "под капотом" у современного MySQL-а дичайший быдлокод. Всё это обрастание фичами изначльно не заточенной под них архитектуры привело к водружению костыля на костыле. Двухступенчатая компиляция запросов, множественные движки, черезжопная репликация и всё вот это.
Во-вторых, MySQL / InnoDB вообще не устойчива к сбоям типа "внезапно вырубили электричество" или "Kernel Panic". PostgreSQL совершенно спокойно отрабатывает такие ситуации и сам восстанавливается до последнего консистентного состояния. Максимум, потеряет несколько последних транзакций. Починить ту же InnoDB после внезапного отключения электропитания возможно только сторонними утилитами, дикими плясками с бубном, и то только если очень сильно повезёт. Если в момент краша в какие-то таблицы велась запись, то с данными из них можно смело попрощаться сразу.
В-третьих, предсказуемость расходования системных ресурсов. В PostrgreSQL-е можно более-менее прогнозировать потребные CPU / RAM, их расходование зависит только от степени "тяжести" SQL-запросов. Также их потребление можно регулировать настройками в конфиге. MySQL может в самый неожиданный момент рухнуть по OOM просто потому, что у него до какой-то критической величины разрослись таблицы, хотя запросы к ним всегда выполнялись плюс-минус одни и те же. И этот момент весьма тяжело "поймать" и предупредить.
В-четвёртых, функционал PostgreSQL можно расширять extension-ами и плагинами. Или вообще превратить его в GIS, TimeSeries, Key-Value (Hstore) и так далее. Про MySQL я таких историй не знаю, может они конечно и есть, не уверен.
В-пятых, репликация. У Postgres она реализована кондово, straightforward, на уровне изменений бинарных данных, работает просто, быстро и предсказуемо. У MySQL это kind of magic. Тоже работает, но есть нюансы. © Как в анекдоте про Петьку и Василия Ивановича. Начинаются всякие тонкости, завязанные на выбор конкретных движков и способов.
Единственное, что мои оппоненты обычно выкатывают мне в защиту MySQL - это наличие multi-master репликации. Мол, в MySQL она есть "из коробки", а в Postgres-е нужно прикручивать всякие ухищрения. Дорогие мои, я могу возразить только одно: multi-master в RDBMS это есть суть какое-то извращение. Изучайте CAP-теорему и думайте о вечном. Если вам всерьёз нужны одновременно и multi-master, и реляции, то скорее всего вы что-то делаете не так. И нужно либо крестик снять, либо трусы надеть.
Ещё у Postgres-а есть большое больное место: mass update и mass delete, особенно в таблицах с внешними ключами. Но тут только подстраивать / оптимизировать запросы, пытаться как-то обходить эти грабли, проводить такие запросы с предварительным удалением индексов и через временные таблицы, прикручивать тот же TimeScaleDB если возможно. Увы, это следует из самой архитектуры организации хранения данных и никак не лечится.
В общем, персонально моё мнение заключается в том, что в 2023-м году MySQL-ю в проде вообще не место. В нём нет ничего такого, за что стоило бы цепляться. Если хотите, давайте спорить.