Что не так с PostgreSQL — Разработка на vc.ru

Если вы никогда не задумывались о том, что не так с PostgreSQL, скорей всего, у вас всё так и можно спокойно жить дальше. Но это не точно. :-)

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

Отсутствие автоматического горизонтального масштабирования. Из коробки такой функциональности нет; шардирование реализовано как частный случай партиционирования; вся ответственность за распределение данных ложится на плечи разработчиков. Расширение Citus (GitHub) частично решает проблему с масштабированием, однако нужно понимать, что оно не делает из PostgreSQL полноценную распределенную реляционную базу с гарантиями ACID при выполнении транзакций. Иначе говоря, Citus обеспечивает только согласованность в конечном счёте, следовательно, в общем случае не подходит для OLTP-задач; либо подходит, но в рамках одного шарда; и хорошо подходит для "складов данных" (data warehouses).
Низкие гарантии отказоустойчивости. При выходе из строя мастера гарантирован простой в работе системы и риск потери согласованности данных. Очень часто для построения высокодоступного (HA, High Availability) кластера PostgreSQL используют Patroni (GitHub). Экземпляры Patroni работают как sidecars для узлов PostgreSQL, которые координируют свои действия через указанное распределенное хранилище конфигураций (etcd, ZooKeeper и т.п.). Patroni отслеживает доступность узлов кластера, управляет их работой и конфигурацией, определяет узел мастера, производит выбор нового мастера из существующих реплик в случае недоступности старого.
Простои при обновлении на новую версию. Частично решить проблему может логическая репликация, но она имеет ряд ограничений, в том числе не умеет переносить изменения схемы данных (DDL) и сразу же останавливается, если такое вдруг произойдет. Также нужно иметь в виду, что тот же Patroni использует только физическую репликацию.
Раздувание базы данных (bloat). Со временем файлы данных "раздуваются", занимая больше места на диске, чем могли бы. Эта проблема присуща не только PostgreSQL и связана с версионированием изменений данных. Для новых изменений резервируется дополнительное пространство на диске, а место, занимаемое старыми и неактуальными версиями, не освобождается. Для минимизации последствий рекомендуется контролировать уровень bloat и настроить автоматическую очистку. В крайних случаях можно использовать команды VACUUM, CLUSTER или REINDEX, но они создают блокировки, что может сказаться на работоспособности приложения. Если блокировки недопустимы, можно посмотреть в сторону расширений типа pg_repack.

Подводя небольшой итог, можно выделить случаи, когда PostgreSQL не подойдет:

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

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

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

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. ;-)