PostgreSQL: почему это база данных по умолчанию для веб-сервисов

PostgreSQL — база с открытым кодом и свободной лицензией: никаких платежей за ядро, лицензий на процессоры и внезапных изменений условий. При этом по возможностям она конкурирует с коммерческими системами, которые стоят миллионы: проекту с самого старта доступны транзакции, репликация, полнотекстовый поиск и десятки типов данных.

Для заказчика это устраняет целый класс рисков: продукт не привязан к вендору, база работает на любом сервере — от VPS за несколько сотен рублей до кластера — и её поддерживает любой бэкенд-разработчик, а не редкий специалист по конкретной проприетарной СУБД.

Главное, за что PostgreSQL любят в финансовых сценариях, — строгие транзакции (ACID). Операция «списать с баланса и записать платёж» либо выполняется целиком, либо не выполняется вообще: сервер может упасть в любой момент, но денег «в никуда» не спишется и заказ без оплаты не создастся.

Это свойство не добавляется «потом» — оно либо есть в фундаменте, либо нет. Поэтому биллинг, балансы, подписки и любые сценарии, где ошибка стоит реальных денег, мы строим только на транзакционной базе. В платформе Юнкис на PostgreSQL работают именно такие контуры: списания за сообщения ботов, тарифы, платежи.

Классический аргумент за NoSQL-базы — «у нас данные без жёсткой схемы». PostgreSQL закрывает это типом JSONB: в обычной таблице хранится структурированный JSON-документ, по которому можно искать и строить индексы. Настройки пользователя, метаданные диалога, ответы квиза — всё это живёт рядом с транзакционными данными.

Практическое следствие: в большинстве проектов не нужна вторая база «для гибких данных» — а значит, нет второй точки отказа, второго бэкапа и синхронизации между хранилищами. Одна база покрывает и строгие финансовые таблицы, и свободные структуры.

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

Альтернатива — отдельная векторная база — означает ещё один сервис, который нужно хостить, бэкапить и синхронизировать с основными данными. С pgvector каталог на десятки тысяч товаров и его векторный индекс живут в одной базе: наш RAG-поиск по фидам магазинов работает именно так. Подробнее мы разбирали это в статье о векторных базах данных.

Распространённый миф — «PostgreSQL не выдержит нагрузку, нужно что-то специальное». На практике одна правильно настроенная база на нормальном железе обслуживает проекты с миллионами записей и тысячами запросов в секунду; узким местом почти всегда оказываются неоптимальные запросы и отсутствие индексов, а не сама СУБД.

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