Когда Postgres достаточно для большей части стека продукта

Почему лишние компоненты создают проблемы

Каждый новый сервис добавляет работу. Вы не ставите Redis, брокер сообщений или поисковую систему и потом о них не думаете. Команда получает ещё одну вещь, которую нужно установить, обезопасить, мониторить, бэкапить, патчить и чинить, когда она падает в два часа ночи.

Боль обычно растёт быстрее, чем ожидают, потому что новая система редко остаётся отдельной надолго. Ей нужны данные из Postgres или туда начинают попадать первичные записи. Вскоре продукт зависит от задач синхронизации, повторных попыток и правил «событийной согласованности», о которых через полгода никто не вспомнит.

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

Часто именно задачи синхронизации превращают простую систему в что‑то странное. Одна задача пропускает батч. Другая запускается дважды. Рабочий отстаёт. Поддержка видит одно значение в приложении, финансы — другое в отчёте, и никто не доверяет ни одному из них. Отслеживание бага идёт медленно, потому что путь записи пересекает несколько инструментов, у каждого свои тайминги и логи.

Держать несколько копий одних и тех же данных в согласованности тоже дорого. Вы платите за дополнительные серверы и хранилище, но самая большая цена — время инженеров. Разработчик может потерять полдня, доказывая, что баг не в Postgres, не в Redis, не в воркере и не в скрипте, который патчит первый скрипт.

Вот почему стоит спросить, когда Postgres достаточно. Больше инструментов не всегда ускоряет продукт. Иногда они просто распыляют один чистый источник правды по трём системам и превращают пятиминутную проблему с запросом в неделю отладки.

Что Postgres уже умеет хорошо

Многие команды относятся к Postgres как к пассивному хранилищу, а затем добавляют лишние инструменты для задач, с которыми он уже справляется. На практике он может нести гораздо большую часть приложения, чем ожидают.

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

Транзакции — большая часть привлекательности. Если флоу регистрации должен создать аккаунт, запустить пробный период, записать аудит и поставить в очередь письмо-приветствие, Postgres может рассматривать это как единицу работы. Либо всё попадает, либо ничего. Вы не получите запись пользователя без записи плана.

Поиск — ещё одна область, где команды часто перестраивают систему. Для многих продуктов полнотекстовый поиск Postgres вполне хорош для статей справки, внутренних заметок, каталогов и админских инструментов. Если люди в основном ищут по словам и фильтрам, держать поиск ближе к исходным данным обычно проще.

Postgres также подходит для скромных очередей задач. Таблица может хранить задачи, количество повторов, время запуска и статус. Блокировка строк позволяет одному воркеру захватить задачу, пока остальные её пропускают. Часто этого достаточно для писем, вебхуков, отчётов, очистки данных и импорта CSV.

Отчётность тоже мощнее, чем многие думают. SQL умеет группировать, фильтровать и суммировать данные достаточно быстро для многих дашбордов. Суточные регистрации, выручка по планам, неудачные платежи и объём поддержки не всегда требуют отдельного аналитического стека.

Это не значит, что Postgres должен делать всё вечно. Это значит, что одна хорошо управляемая база данных может хранить данные, поддерживать поиск, выполнять фоновые задачи и отвечать на бизнес‑вопросы гораздо дольше, чем большинство команд ожидает.

Когда одна база лучше

Один Postgres часто безопаснее, когда продукт ещё меняется, а команда небольшая. Дополнительные инструменты сначала кажутся дешёвыми, но каждый из них добавляет настройку, бэкапы, алерты, режимы отказа и странные баги, которые появляются только под нагрузкой.

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

Это особенно важно, когда согласованность важнее пиковой скорости. Если пользователь оплатил план, вы хотите, чтобы новые лимиты, правила доступа и запись счёта совпадали сразу. Разделение этого флоу между Postgres, Redis, очередью и поисковым хранилищем может красиво смотреться на диаграмме, но также увеличивает шансы, что состояние рассинхронизируется.

Для ранних и средних стадий продукта простое решение должно быть по умолчанию. В консультационной работе со стартапами команды иногда спорят о Postgres vs Redis ещё до того, как у них есть устоявшийся набор фич. Большую часть времени реальная проблема — не сырая скорость БД, а слишком много систем для маленькой команды.

Одна база обычно лучше, когда:

• одни и те же таблицы поддерживают большинство фич
• правила продукта меняются каждые несколько недель
• команда тратит больше времени на операционную работу, чем на выпуск фич
• корректность данных важнее максимальной пропускной способности

Представьте B2B SaaS с пятью инженерами. Каждая фича касается клиентов, мест, счетов и разрешений. Если всё остаётся в Postgres, команда может изменить схему, выпустить фичу и доверять результату. Распылите всё слишком рано — одна просьба фичи превратится в четыре миграции, две задачи синхронизации и полдня отладки.

Это часто момент, когда Postgres достаточно. Не навсегда и не для любой нагрузки. Но пока узкое место реальное и измеренное, одна база держит модель чистой и команду подвижной.

Как решать, прежде чем добавить ещё инструмент

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

Начните с точной формулировки проблемы, а не с названия инструмента. «Страница оформления медленно работает при 200 одновременных пользователях» — полезно. «Нам нужен Redis» — нет. Если вы не можете описать боль в одном предложении, вы, вероятно, ещё не готовы разделять стек.

Потом измерьте, что делает Postgres сегодня. Посмотрите объёмы чтений и записей, медленные запросы, ожидания блокировок, накопление очереди и p95‑латентность там, где это чувствует пользователь. Одна плохая джойн или отсутствующий индекс могут выглядеть как предел базы, когда это реально ошибка дизайна.

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

Простой процесс помогает:

1. Запишите точный сбой с числами.
2. Измерьте, куда уходит время.
3. Попробуйте сначала исправить запросы, индексы и схему.
4. Проверьте, решит ли проблему таблица очередей, view или материализованный view.
5. Задайте чёткий порог, который оправдает новый инструмент позже.

Последний шаг самый важный. Решите заранее, что вынудит разделение. Это может быть устойчивый объём записей, задержка в очереди, рост хранилища или цель по латентности, которую вы не можете достичь после тюнинга. Сделайте порог конкретным. Например: если задачи ждут более 30 секунд в течение недели после исправлений запросов и индексов, тогда брокер может иметь смысл. Если чтение вырастет в 5 раз и кэшируемые запросы всё ещё нагружают базу, тогда вернитесь к вопросу Postgres vs Redis.

Паттерны, которые работают внутри Postgres

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

JSONB — простой выигрыш. Используйте обычные колонки для полей, по которым вы сортируете, джойните и фильтруете часто. JSONB — для дополнительных данных, которые отличаются у клиентов, например настройки форм, флаги фич или метаданные импорта. Вы держите один источник правды, не вводя новую базу.

Фоновая работа тоже может жить в Postgres. Таблица задач со статусом, временем запуска, счётчиком повторов и деталями ошибок часто покрывает письма, отчёты, вебхуки и задачи очистки. Её проще исследовать, чем отдельную очередь: видно, что упало, можно вручную повторить задачу и сохранить аудит. Если продукт порождает огромный объём задач каждую секунду — берите специализированный инструмент. Если это скромный поток, Postgres для очередей обычно подходит.

Паттерн outbox решает распространённую проблему. Когда приложение создаёт заказ, отправляет вебхук и обновляет другую систему, запишите заказ и строку в outbox в одной транзакции. Воркеры читают outbox и отправляют события после фиксации. Это безопаснее, чем разрозненные скрипты синхронизации, которые пытаются угадать, что изменилось ночью.

Views и материализованные views закрывают многие потребности по чтению. Они годятся для админских дашбордов, сводок по аккаунту и экранов отчётности. Вместо копирования данных в другое хранилище — формируйте их внутри Postgres и обновляйте по расписанию, которое соответствует продукту.

Хороший дефолт намеренно скучен: держите одну базу как источник правды, копируйте данные только когда нужно и добавляйте ещё хранилище только после того, как сможете назвать точный предел, который вы преодолели.

Реалистичный пример

Представьте небольшой SaaS для полевых команд. Клиенты заходят в систему, управляют персоналом, платят ежемесячно, получают уведомления по почте и обращаются в поддержку при проблемах. Админская часть требует отчётов по использованию, неудачным платежам, изменениям в аккаунтах и активности поддержки.

Многие команды разбивают это слишком рано. Они кладут данные пользователей в одно место, события в другое, очереди ещё куда‑то, а отчётность поверх — с задачами синхронизации. На диаграмме это выглядит аккуратно, но часто создаёт рассинхронизацию чисел и баги, которые трудно отследить.

Postgres может упростить. Он хранит пользователей, команды, подписки, счета, флаги фич, настройки клиентов и историю аудита в обычных таблицах. Если владелец аккаунта меняет план, приложение записывает новый план, событие биллинга и аудиторскую запись в одной транзакции. Поддержка, финансы и продукт читают одни и те же факты.

Уведомления могут оставаться там же. Когда нужно отправить письмо‑приветствие, напоминание об оплате или вебхук другой системе, приложение вставляет строку в таблицу задач. Воркеры берут ожидающие строки, отправляют сообщение и обновляют статус. Если вебхук падает, та же запись хранит время следующей попытки, текст ошибки и число попыток.

Это покрывает много реальной работы без Redis или брокера. Для многих продуктов очередь в Postgres проще в эксплуатации и гораздо легче проверяется при ошибках.

Поиск для саппорта тоже не требует отдельного движка, если контента немного. Заметки типа «клиент спросил про SSO» или «возврат после двойного списания» хорошо ложатся в полнотекстовый поиск Postgres. То же для небольшой внутренней базы знаний с шагами по отладке и политиками.

Самый большой выигрыш — в том, чего вам не нужно. Отчёты берут из живых таблиц. Операционные инструменты читают те же статусы задач, которые обновляют воркеры. Админские экраны показывают тот же статус биллинга, что и продукт. Чистая архитектура с одной базой даёт меньше движущихся частей и гораздо меньше рассинхронизации по продукту.

Где Postgres не должен делать всю работу

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

Поиск — частая точка перелома. Полнотекстовый поиск Postgres хорош для умеренных объёмов, фильтров и простого ранжирования. Становится больно, когда пользователи ожидают быстрый ранкинг по миллионам длинных документов, нечёткий поиск, толерантность к опечаткам и большой фан‑аут запросов одновременно. Тогда выделенный поисковый движок окупает себя.

Очереди имеют похожий предел. Postgres практичен, когда задачи идут равномерно и воркеры близки к приложению. Добавьте брокер, когда всплески резкие, воркеры масштабируются по многим сервисам или когда нужно свободное сцепление между продьюсерами и консьюмерами. Если тысячи повторов, отложенных задач и паттернов фан‑аута бьют по той же базе, что обслуживает трафик клиентов, пользователи это почувствуют.

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

Иногда дело не в общем масштабе, а в одном некрасивом паттерне записи. Поток событий только на запись, очень «горячие» счётчики или постоянные массовые импорты могут создать давление вакуума, конкуренцию за блокировки или скачки I/O, которые вредят несвязанным таблицам. Когда один паттерн вредит всей системе, другое хранилище может быть простым решением.

Несколько сигналов важнее погони за трендом:

• p95 или p99‑латентность растёт во время батч‑заданий или всплесков воркеров
• autovacuum отстаёт, и объём блоута таблиц постоянно растёт
• качество поиска остаётся плохим после тщательного тюнинга
• реплики, партиционирование и исправления запросов больше не дают нужного запаса

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

Ошибки, которые создают дополнительную работу

Команды часто добавляют новые системы, чтобы уйти от боли, которую они ещё не описали. Медленная страница превращается в проект Redis. Задержанный отчёт — в воркер синхронизации. Через пару месяцев команда запускает больше софта, но первоначальная проблема всё ещё там.

Самая распространённая ошибка — добавить кэш до того, как исправят работу базы. Если страница занимает 900 мс из‑за одного запроса, сканирующего огромную таблицу, Redis лишь на время это скроет. Два индекса, меньший результат или один лишний круг к Postgres часто делают больше, чем новый слой кэша. Вот где спор Postgres vs Redis становится грязным: команды сравнивают инструменты до того, как исправят план запроса.

Копирование данных в другое хранилище без ясного владельца создаёт другой вид бардака. Одна команда пишет в Postgres. Другая копирует те же записи куда‑то ещё для поиска, отчётов или фоновых задач. Затем синхронизация падает, ретраи накапливаются, и поддержка видит две версии одного и того же клиента. Если никто не может сказать, какая копия — источник правды, дизайн уже слишком дорог.

Ранние разделения сервисов приносят ту же проблему. Команде из четырёх человек не нужны пять пайплайнов деплоя, пять потоков логов и сетевые вызовы между частями одного продукта, который всё ещё меняется каждую неделю. Если всё ещё можно понять приложение в одном репозитории и одна команда может им управлять, держите его вместе.

Ещё одна утечка — хранение одних и тех же данных дважды потому, что разные команды предпочитают разные инструменты. Предпочтения — не архитектура. Каждая лишняя копия добавляет миграции, правила доступа, режимы отказа и работу по очистке.

Простой пример: SaaS‑команда добавляет Redis, потому что дашборд кажется медленным. Через две недели кэш работает, но пользователи всё ещё видят устаревшие числа. Истинное исправление оказалось проще и дешевле: один отсутствующий индекс, одна сводная таблица, обновляемая по расписанию, и один тяжёлый запрос вынесён из пути запроса.

Если боль связана с неясной ответственностью, плохими запросами или грязными операциями, ещё одна система обычно умножит работу. Исправьте форму приложения сначала. Добавляйте новый инструмент только когда Postgres покажет явный, проверенный предел.

Быстрые проверки перед расширением стека

Новый сервис может казаться прогрессом. Иногда это просто второе место для отладки одной и той же проблемы.

Прежде чем добавлять Redis, брокер или поисковое хранилище, убедитесь, что у вас есть измеренное узкое место. Медленный запрос, рост времени блокировок, всплески записи, накопление очереди или высокий CPU дают реальную цель для исправления. «Кажется медленно» — не повод.

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

Используйте этот краткий чеклист:

• опишите проблему в одном предложении с цифрой
• протестируйте дешёвые исправления сначала
• спросите, создаёт ли новый инструмент вторую копию тех же данных
• назначьте человека, который будет его поддерживать
• задайте чёткую точку выхода, если он не помогает

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

Что делать дальше

Начните с текущей боли, а не с инструмента, который кто‑то хочет добавить. Если страницы загружаются достаточно быстро, задачи укладываются в сроки, и команда доверяет данным, возможно, вам ещё не нужна вторая база. Многое расширение стека начинается с расплывчатого ощущения, что текущая система «слишком простая». Это ощущение дорого обходится.

Запишите все места, где данные живут или перемещаются: продуктовые данные, данные для поиска, фоновые задачи, кэш, аналитические копии, отчёты и вебхуки. Затем отметьте, какая система должна оставаться источником правды. Во многих продуктах ответ всё ещё Postgres.

Если вы не уверены, когда Postgres достаточно, задайте четыре простых вопроса:

• Что реально медленно или хрупко прямо сейчас?
• Какие данные должны оставаться корректными после ретраев, деплоев или падений задач?
• Какой дополнительный инструмент уберёт реальное узкое место, а не добавит работу по синхронизации?
• Какое минимальное изменение можно выпустить за неделю?

Последний вопрос обычно самый полезный. Маленькие изменения часто побеждают большие переделки. Вы можете перенести очередь в Postgres, удалить кэш, который почти ничего не даёт, или перестать копировать данные во вторую базу для одного отчёта. Каждое такое сокращение убирает одно место для мониторинга и одно место, которое может сломаться в два часа ночи.

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

Если команде нужен второй взгляд перед добавлением инфраструктуры, Oleg Sotnikov на oleg.is работает как Fractional CTO и советник стартапов. Его работа часто о невзрачных вещах, которые важнее всего: сокращении лишнего, упрощении архитектуры и решении, что держать вместе сейчас, а что разделять позже.