PostgreSQL на виртуальном хостинге: кому это на самом деле нужно

Почти каждый тариф виртуального хостинга на рынке предлагает MySQL или MariaDB — и ничего больше. В результате получается замкнутый круг: фреймворки по умолчанию используют MySQL, потому что именно он доступен на shared-хостингах, а shared-хостинги предлагают MySQL, потому что именно его по умолчанию используют фреймворки. Если вашему стеку нужен PostgreSQL, вас обычно сразу отправляют на VPS.

Иногда это действительно оправданно. Но часто — нет.

Когда вам действительно нужен PostgreSQL

Экосистема вашего фреймворка рассчитана на него. Django и Rails работают и с MySQL, но их документация, руководства и значительная часть сторонних пакетов ориентированы на PostgreSQL. В Django такие возможности, как ArrayField, запросы по JSONField, полнотекстовый поиск через SearchVector и ExclusionConstraint, доступны только с PostgreSQL. Без них можно обойтись — просто придётся писать больше кода для того, что фреймворк уже умеет делать сам.

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

Ваши данные имеют сложную структуру. Массивы, диапазоны, jsonb с индексами по содержащимся в нём ключам, полноценные типы ENUM, ограничения, которые действительно обеспечивают целостность данных. Поддержка JSON в MySQL вполне реальна, но менее развита, а историческая склонность MySQL принимать значения, которые следовало бы отклонить, до сих пор влияет на то, как разработчики пишут для него миграции.

Вам нужен геопространственный или полнотекстовый поиск, который выходит за рамки LIKE. У PostGIS нет полноценного аналога в MySQL. Полнотекстовый поиск PostgreSQL с tsvector и GIN-индексами способен решить удивительно много задач, ради которых разработчики часто сразу тянутся к Elasticsearch.

Когда это просто следование моде

WordPress, Joomla, Magento и большинство PHP CMS. Это проекты, ориентированные на MySQL. Запускать их на PostgreSQL означает использовать слой совместимости, а плагины будут ломаться способами, которые до вас, скорее всего, никто не отлаживал.
«PostgreSQL быстрее». Для запросов типичной CMS или небольшого приложения, когда весь набор данных помещается в RAM, разница практически теряется на фоне отсутствующего индекса или страницы без кеширования.
«Все серьёзные проекты используют PostgreSQL». Огромное количество серьёзных систем успешно работает на MySQL даже при больших нагрузках. Выбирайте ту СУБД, которую ваша команда умеет нормально обслуживать.

Практический тест

Задайте себе три вопроса.

Основной сценарий работы вашего фреймворка предполагает PostgreSQL? Его документация, руководства и значительная часть сторонних пакетов ориентированы именно на него.
Вашей схеме данных нужны типы, которых нет в MySQL? Массивы, диапазоны, jsonb с индексами по внутренним ключам, полноценные типы ENUM.
Вам необходимо, чтобы неудачная миграция полностью и чисто откатывалась? В PostgreSQL при сбое миграции изменения схемы откатываются вместе с ней. В MySQL DDL не является полностью транзакционным.

Одного ответа «да» достаточно, чтобы выбор PostgreSQL был оправдан. Если везде ответ «нет», MySQL — скучный, но правильный выбор.

И одного «да» действительно достаточно. Ноль положительных ответов означает, что MySQL остаётся скучным и правильным решением. А для базы данных скучность — это преимущество.

-- пример задачи, которая может определить выбор:
-- индексируем JSON-ключ и выполняем запрос по нему
CREATE INDEX idx_meta_plan ON accounts USING gin ((meta -> 'plan'));
SELECT id FROM accounts WHERE meta @> '{"plan": "growth"}';

Что должно означать «PostgreSQL на виртуальном хостинге»

Не просто галочка в списке возможностей тарифа. Чтобы PostgreSQL действительно можно было нормально использовать, нужны:

Собственная база данных и роль, а не общий пользователь кластера, чтобы GRANT действительно имел смысл.
Понятный лимит подключений, который можно посмотреть. Подключения PostgreSQL обслуживаются отдельными процессами, поэтому фреймворк с неаккуратно настроенным пулом соединений легко исчерпает доступный лимит.
Доступ к pg_dump через SSH, чтобы вы могли самостоятельно создавать резервные копии и переносить базу, а не обращаться для этого в поддержку.
Панель администрирования, чтобы при необходимости посмотреть или изменить строку в базе без открытия терминала.
Возможность подключать расширения — как минимум pg_trgm и uuid-ossp; а если хостинг действительно серьёзно относится к поддержке PostgreSQL — ещё и PostGIS.

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

Все тарифы виртуального и реселлерского хостинга inSave включают как MySQL, так и PostgreSQL: от одной базы PostgreSQL на тарифе Shared Start до 30 на Shared Business и от 25 до 300 баз в линейке реселлерских тарифов. На тарифах с shell-доступом также доступны SSH и pg_dump.

Именно поэтому проекты на Django и Rails могут размещаться здесь, а не переезжать на VPS, который им на самом деле не нужен.

Коротко

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

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