Коротко. PostgreSQL — база данных, на которой мы держим то, что нельзя терять и путать: отчётность по деньгам и стадиям сделок из CRM и SEO-платформу с данными девяти сайтов в одной базе. Для типового сайта или блога на WordPress достаточно MySQL — тянуть PostgreSQL туда не нужно. Разница появляется, когда нужны отчёты по живым данным, интеграции с Битрикс24 и несколько клиентов в одной системе: тут PostgreSQL даёт строгие транзакции и изоляцию данных на уровне самой базы — row-level security.
Где в бизнес-проекте живут данные
Сайт — это витрина. Данные, на которых зарабатывает компания, живут глубже: заявки, сделки в CRM, суммы и стадии, прайсы поставщиков, статистика рекламы и позиций в поиске. Пока это лежит в разных кабинетах и Excel-файлах, бизнес видит обрывки, а не картину.
Когда мы строим для клиента отчётность или автоматизацию, эти потоки сводятся в одну базу. И тогда выбор СУБД перестаёт быть мелочью: от него зависит, сойдутся ли цифры в отчёте и не увидит ли один клиент данные другого. Практическое правило, которым пользуемся сами:
- Контент — страницы, статьи, каталог товаров — спокойно живёт в MySQL внутри WordPress.
- Деньги и операционка — сделки, отчёты, интеграции с CRM — переезжают в отдельный сервис на PostgreSQL.
PostgreSQL против MySQL: в чём реальная разница
Обе базы бесплатны и проверены десятилетиями. Правильный вопрос не «что лучше», а «для какой задачи». Взгляд с точки зрения бизнеса, а не программиста:
| Критерий | MySQL | PostgreSQL |
|---|---|---|
| Типовой сайт на WordPress | Родная среда: WordPress спроектирован под MySQL | Официально не поддерживается — и не нужен |
| Целостность денег в отчётах | Достаточна для контента | Строгие транзакции: сумма либо записана целиком, либо не записана вовсе |
| Сложные отчёты (динамика, доли, менеджеры) | Возможно, но громоздко | Считаются штатными средствами прямо в базе |
| Несколько клиентов в одной системе | Разделение только на уровне кода приложения | Row-level security: изоляция на уровне самой СУБД |
| Гибкие данные (ответы API, JSON от CRM) | Базовая поддержка | Полноценная работа с JSON — удобно для интеграций |
| Хостинг | Есть на любом тарифе от ~300 ₽/мес (ориентир рынка) | Нужен VPS или свой сервер, ~800–2000 ₽/мес (ориентир рынка) |
Итог честный: для сайта-визитки MySQL выигрывает по простоте, для отчётности и мультиклиентских систем PostgreSQL — по надёжности.
Row-level security: изоляция данных клиентов на уровне базы
Row-level security (RLS) — «безопасность на уровне строк». Представьте сейф с ячейками: ключ от сейфа открывает только свою ячейку. Обычно за то, «кому что показывать», отвечает код приложения — и одна ошибка программиста открывает чужие данные. С RLS правило встроено в саму базу: запрос клиента А физически не может вернуть строки клиента Б, как бы ни был написан код поверх.
Мы используем RLS в своей SEO-платформе: в одной базе — позиции, страницы и метрики девяти сайтов, каждый запрос работает в контексте конкретного проекта. Утечка между проектами исключена на уровне СУБД, а не на честном слове кода.
Практический вывод: если подрядчик строит вам систему с данными разных клиентов или филиалов — спросите, как они изолированы. Ответ «на уровне базы» надёжнее, чем «в коде всё проверяется».
Как мы используем PostgreSQL в своих проектах
Мы не рассуждаем о PostgreSQL теоретически — он работает у нас ежедневно:
- Отчётность продаж для завода металлоконструкций. Python-сервис забирает из Битрикс24 сделки, суммы и стадии и складывает в PostgreSQL. Руководитель видит еженедельный отчёт по выручке и менеджерам — цифры сходятся, потому что база не допускает «полузаписанных» сделок.
- SEO-мониторинг девяти сайтов. Одна база, проекты изолированы через row-level security: позиции, индексация, история — по каждому сайту отдельно.
- Парсер прайсов поставщиков. Собирает цены и хранит историю: видно, кто и когда подорожал.
- SaaS-платформа мониторинга видимости брендов в нейросетях — наш продукт на том же стеке.
Всё это работает на нашем Linux-сервере в Docker-контейнерах, с CRM и внешними системами сервисы общаются через API-интеграции.
Когда PostgreSQL избыточен
Честный раздел: «серьёзная база» — не синоним «правильного решения». PostgreSQL не нужен, если:
- У вас контентный сайт. Корпоративный сайт, блог, каталог на WordPress — это MySQL, и это нормально. Наши темы с PageSpeed 90+ работают на MySQL; клиент с ростом трафика ×6,3 за месяц обошёлся без PostgreSQL.
- Данные помещаются в CRM. Пока Битрикс24 закрывает отчёты штатными средствами — отдельная база не нужна.
- Нет второго потребителя данных. Если цифры смотрит один человек раз в месяц, хватит Excel-выгрузки.
- Бюджет проекта — уровень лендинга. Лендинг от 80 000 ₽ с запуском за 5–10 дней не предполагает своей базы, и это правильно.
PostgreSQL оправдан, когда источников данных несколько, нужна сквозная картина по деньгам или в системе живут несколько клиентов. До этого — не усложняйте.
FAQ
PostgreSQL — это дорого?
Сама СУБД бесплатна, лицензий нет. Затраты — сервер (ориентир рынка: VPS от ~800 ₽/мес) и разработка сервиса, который с базой работает. Платите за инженерную работу, а не за право пользоваться базой.
Нужно ли переносить наш сайт с MySQL на PostgreSQL?
Почти наверняка нет. WordPress и большинство CMS спроектированы под MySQL, перенос сломает больше, чем даст. PostgreSQL подключают рядом — под отчётность и интеграции, сайт остаётся на месте.
Насколько это надёжно, если там деньги и клиентские данные?
PostgreSQL используют банки именно из-за строгих транзакций: запись или проходит целиком, или откатывается. Изоляцию клиентских данных закрепляем row-level security — правило работает внутри базы, независимо от кода. Плюс регулярные резервные копии.
Кто будет это обслуживать, у нас нет программистов?
В наших проектах базу и сервисы обслуживаем мы: сервер, Docker, мониторинг и бэкапы входят в поддержку. Штатный администратор баз данных не нужен — нужен подрядчик, отвечающий за систему целиком.