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 сама по собі не повинна змушувати вас переходити на сервер, який доведеться адмініструвати самостійно.