Разговор о собственном PostgreSQL-кластере обычно начинается с фразы: «Да там поставить — день работы». Технически это правда. Установка PostgreSQL на два сервера в разных ЦОДах действительно занимает несколько часов. Проблема в том, что установка — это меньше 10% работы до Production-ready-состояния.
В этой статье мы декомпозируем все задачи, которые стоят между идеей развертывания и работающим кластером с отказоустойчивостью между ЦОДами. Все с оценками в человеко-часах, чтобы можно было собрать для себя TCO и сопоставить свои затраты. Учтите, что если все это вы делаете в первый раз, то по всем шагам время увеличивается втрое.
Параллельно покажем те же временные и трудозатраты при выборе Managed-решения, DBaaS (базы данных как сервис), чтобы вы могли сравнить и выбрать — делать дальше самим или передать это на аутсорс.
Что значит Production-ready
Прежде чем считать трудозатраты, стоит договориться о точке финиша. Без этого любые оценки бессмысленны: можно развернуть PostgreSQL за час, но это будет Dev-стенд. А можно потратить месяц и получить Production-ready-кластер.
Dev-кластер — для экспериментов и тестирования, где допустимы падения и потеря данных. Production-ready — для боевой нагрузки с отказоустойчивостью, резервированием и гарантиями доступности.
Production-ready PostgreSQL-кластер с репликацией между зонами доступности — это система, которая соответствует четырем критериям.
Отказоустойчивость. При падении мастера кластер автоматически переключается на реплику. Приложения продолжают работать без ручного вмешательства. RTO (Recovery Time Objective — целевое время восстановления) измеряется минутами, а не часами. Проще говоря, RTO — это ответ на вопрос «как быстро система должна вернуться в строй. Для критичных систем это означает автоматический Failover, а не звонок дежурному DBA в три часа ночи.
Восстановление данных. Бэкапы делаются автоматически по расписанию. Есть возможность восстановиться на любой момент времени за последние N дней — так называемый point-in-time recovery (PITR). Это не просто «откатиться на вчерашний бэкап», а восстановить базу на состояние, например, 14:35:22 — за минуту до того, как что-то пошло не так.
RPO (Recovery Point Objective — допустимая потеря данных для большинства бизнес-систем — от нескольких минут до часа. RPO отвечает на вопрос: «Сколько данных мы готовы потерять при катастрофе?» Если RPO = 1 час, значит, в худшем случае вы потеряете данные за последний час. Чтобы обеспечить низкий RPO, WAL-архивация должна работать непрерывно.
Наблюдаемость. Метрики собираются в реальном времени. Алерты настроены на критичные пороги. Дежурный инженер узнает о проблеме раньше пользователей — в идеале до того, как проблема станет инцидентом. Тут недостаточно просто установить Grafana — должна быть продуманная система метрик, порогов и эскалации.
Безопасность. Трафик между приложениями и базой шифруется. Трафик репликации между ЦОДами — тоже. Доступы разграничены по принципу минимальных привилегий. Все действия логируются для аудита. Для систем с персональными данными или платежной информацией добавляются требования регуляторов: 152-ФЗ, PCI DSS, отраслевые стандарты.
Если убрать любой из этих компонентов, вы получите систему, которая работает до первого серьезного инцидента. После него возникают вопросы: почему не было алертов, почему бэкап оказался битым, почему Failover не сработал автоматически.
Чтобы поддерживать настоящую отказоустойчивость, вам потребуются минимум три зоны доступности. Две зоны не дают кворума: при потере связи между ними обе стороны считают, что партнер умер, и пытаются стать мастером. Третья зона решает эту проблему — она голосует за одну из сторон. Вот к чему нужно прийти, чтобы получился настоящий Production-ready:
Теперь давайте разберем, как этого добиться по шагам и сколько это будет стоить.
Развертывание PostgreSQL состоит из нескольких этапов. Отразили их на схеме:
Пройдемся по каждому этапу отдельно, разбирая трудозатраты.
Часть 1. Инфраструктурный фундамент
Первые три этапа — это инфраструктура, установка и отказоустойчивость. Все это разовая работа на старте проекта, но без этого кластер не запустится вообще, а ошибки на этих этапах аукаются годами.
Эти этапы нельзя делать параллельно. Сначала нужна инфраструктура, потом на ней разворачивается PostgreSQL, и только потом настраиваются репликация и Failover. Каждый следующий этап зависит от предыдущего.
Этап 1. Подготовка инфраструктуры
Что делаем на этом этапе:
рассчитываем требуемые ресурсы: CPU, RAM, IOPS;
выбираем тип хранилища — для данных нужны быстрые диски, для WAL-логов лучше отдельные;
проектируем сеть: выделенная подсеть для репликации между ЦОДами, настройка VPN или приватного канала связи;
планируем топологию: где мастер, где реплики, как будет работать Failover при недоступности одного ЦОДа.
Здесь особую роль играет WAL (Write-Ahead Log) — журнал упреждающей записи. Прежде чем PostgreSQL изменит данные на диске, он записывает эти изменения в WAL. Это гарантирует, что при сбое (выключили питание, упала ОС) данные можно восстановить: PostgreSQL при старте просматривает WAL и применяет все изменения, которые не успели записаться в основные файлы данных.
WAL — основа и для репликации, и для бэкапов. Реплика получает WAL-записи от мастера и применяет их к своей копии данных. Point-in-time Recovery работает так: берем полный бэкап и накатываем WAL-сегменты до нужного момента времени. Если WAL потерян, потеряна и возможность восстановиться на произвольный момент.
Именно поэтому WAL выносят на отдельный диск: он постоянно пишется и задержки записи напрямую влияют на скорость транзакций.
Где кроются сложности. Эфф��кт роста производительности конфигураций компонентов до определенного предела сохраняется, а дальше прирост минимален — это нужно учесть. Для OLTP-нагрузок (много коротких транзакций) и OLAP-нагрузок (тяжелые аналитические запросы) нужны принципиально разные конфигурации.
Отдельная история — хранилище. PostgreSQL чувствителен к Latency дисков. Для WAL-логов критична скорость записи: если диск не успевает, транзакции начинают тормозить. Поэтому WAL обычно выносят на отдельный быстрый диск или NVMe. Для данных важнее объем и IOPS на чтение.
Сетевая часть между ЦОДами — ещё один потенциальный источник проблем. Репликация генерирует постоянный трафик. При синхронной репликации Latency сети напрямую влияет на скорость транзакций: каждый Commit ждет подтверждения от реплики. Нужно заранее понимать, какая задержка допустима, и выбирать между синхронной и асинхронной репликацией осознанно.
Ошибка на этом этапе означает либо переплату за избыточные ресурсы, либо проблемы с производительностью через полгода, когда данных станет больше.
Трудозатраты на подготовку инфраструктуры. Более 40 человеко-часов. Это без учета времени на закупку и доставку железа, если речь об On-Premise — там добавляются два-три месяца ожидания.
Self-managed | Managed-решения, DBaaS | |
Подготовка | >40 чч | <1 чч |
Что делает инженер | Расчет ресурсов, выбор железа, проектирование сети, согласование закупок | Выбор конфигурации в интерфейсе: размер, тип диска, топология |
Риск ошибки | Неправильный сайзинг → переделка через 6–12 месяцев | Масштабирование без миграции |
Этап 2. Установка и базовая настройка
Что делаем на этом этапе:
устанавливаем PostgreSQL на серверы;
настраиваем ключевые параметры в postgresql.conf: shared_buffers, effective_cache_size, work_mem, max_connections, параметры WAL для репликации;
конфигурируем pg_hba.conf для аутентификации;
создаем роли, задаем схему привилегий, настраиваем доступы для приложений.
В Managed-сервисе этот этап отсутствует: вы получаете готовый инстанс с параметрами, оптимизированными под выбранный размер.
Где кроются сложности. В PostgreSQL сотни параметров конфигурации. Большинство можно оставить по умолчанию, но несколько десятков требуют осознанного выбора под конкретную нагрузку:
shared_buffers выставлен в 50% RAM — кажется логичным, но на практике PostgreSQL эффективнее использует файловый кэш ОС. Рекомендация для большинства случаев — 25% RAM;
max_connections = 1000 на всякий случай — и каждое соединение потребляет память. Лучше использовать пул соединений и держать max_connections разумным.
Ошибки в pg_hba.conf — отдельный источник проблем. Слишком строгие правила заблокируют легитимные подключения приложений после деплоя. Слишком мягкие откроют доступ там, где не должны. Порядок правил важен: PostgreSQL применяет первое подходящее, а не самое специфичное.
Трудозатраты на установку и настройку. 16–24 человеко-часа.
Self-managed | Managed-решения, DBaaS | |
Установка | 16–24 чч | 0 чч |
Что делает инженер | Установка, настройка параметров, создание ролей, настройка привилегий | Получает готовый инстанс с преднастроенными параметрами |
Оптимизация под нагрузку | Требует экспертизы и итераций | Параметры оптимизированы под выбранный размер инстанса |
Этап 3. Отказоустойчивость
Что делаем на этом этапе:
настраиваем Streaming Replication между мастером и репликой;
разворачиваем систему автоматического Failover: Patroni, repmgr или аналог;
настраиваем механизм переключения клиентов: VIP (виртуальный IP), DNS-based Failover или интеграция с Load Balancer;
документируем и тестируем все сценарии отказа.
Где кроются сложности. Это самый трудоемкий и рискованный этап, так как здесь больше всего неочевидных решений с долгосрочными последствиями.
Сам по себе PostgreSQL не умеет автоматически переключаться при отказе мастера. Он умеет только реплицировать данные. Существует Patroni — надстройка, которая следит за состоянием кластера и принимает решение о переключении.
Но Patroni нужно где-то хранить информацию о том, кто сейчас мастер, какие реплики доступны, когда в последний раз был Health Check. Эту информацию нельзя хранить на самих серверах PostgreSQL: при сетевом разделении каждый сервер будет видеть только себя. Поэтому используется распределенное хранилище: etcd, Consul или ZooKeeper.
etcd — это распределенная база данных типа «ключ-значение». Для Patroni нужен кластер минимум из трех узлов etcd (чтобы работал кворум). Это означает еще три сервера, которые нужно развернуть, настроить, мониторить и обновлять. Если etcd недоступен, Patroni не сможет принимать решения о Failover.
Получается матрешка:
чтобы PostgreSQL работал отказоустойчиво, нужен Patroni;
чтобы работал Patroni, нужен отказоустойчивый etcd;
чтобы etcd был отказоустойчив, нужно минимум три узла.
Сложность инфраструктуры растет нелинейно.
Репликация настроена — но какая именно? Здесь развилка, которая определяет компромисс между производительностью и надежностью.
Синхронная гарантирует, что данные на реплике актуальны — RPO = 0. Но каждая транзакция ждет подтверждения от реплики, что добавляет Latency. Если сеть между ЦОДами имеет задержку 5 мс, каждый Commit становится минимум на 5 мс медленнее. При проблемах с сетью мастер может зависнуть, ожидая ответа от реплики.
Асинхронная репликация быстрее: мастер не ждет подтверждения. Но при Failover реплика может отставать — и последние транзакции будут потеряны. Если RPO бизнеса = 0 (финансовые транзакции, например), асинхронная репликация не подходит.
Настроить автоматическое переключение недостаточно — нужно убедиться, что оно работает. Это значит выдернуть сеть, убить процесс PostgreSQL, перезагрузить сервер, отключить целый ЦОД в тестовой среде. Без тестов в Production вы узнаете о проблемах в самый ��еподходящий момент — когда произойдет реальный инцидент.
Важно тестировать не только сценарий «мастер упал → реплика стала мастером», но и обратное переключение, и поведение при частичной потере сети, и что происходит, когда старый мастер возвращается.
Split-brain — ситуация, когда два узла одновременно считают себя мастером и принимают записи. Как это происходит: сеть между ЦОДами прерывается, каждая сторона считает, что другая недоступна. Patroni на каждой стороне решает: «Мастер умер, я беру на себя». Теперь у вас два мастера, и приложения пишут в оба.
По split-brain уточнение из комментриевТут увлекся и прописал про свой частный случай. Это не является правильной работой
Чтобы точнее быть в доках есть:
"The node is allowed to run Postgres as the primary only if it can update the leader lock in DCS. In case the update of the leader lock fails, Postgres is immediately demoted and started as read-only."
И дальше:
"In the case of DCS 'outage' the existing primary connects to all members presented in the /failsafe key via the POST /failsafe REST API and may continue to run as the primary if all replicas acknowledge it. If one of the members doesn't respond, the primary is demoted."
То есть мастер демотируется до того, как реплика успеет промоутиться. Split-brain в описанном сценарии невозможен при правильной конфигурации. Вы правы, сценарий в статье некорректен. Patroni по дизайну защищён от такого split-brain — мастер демотируется до того, как реплика успеет промоутиться. Описанная ситуация возможна только при багах в Patroni или ручном обходе системы., чем на реальное поведение Patroni 3.x/4.x.
Когда сеть восстанавливается, у вас две разные версии данных. Клиент А создал заказ №1 000 н�� первом мастере. Клиент Б создал заказ №1 000 на втором. Какой из них настоящий? Автоматически это не решается — нужен ручной разбор и, возможно, потеря данных.
Защита от Split-brain — Fencing (изоляция «лишнего» мастера) и кворум (решение принимается большинством узлов). Настроить это правильно — отдельная инженерная задача.
Трудозатраты на настройку отказоустойчивости. Более 40 человеко-часов. Это консервативная оценка для команды с опытом. Для первого раза умножайте на два.
Self-managed | Managed-решения, DBaaS | |
Настройка | >40 чч | <1 чч |
Что делает инженер | Настройка репликации, Patroni, etcd, тестирование сценариев отказа | Выбор типа «кластер» или «георепликация» при создании |
Failover | Требует настройки, тестирования и регулярной проверки | Автоматический, RTO менее 30 секунд |
Split-brain-защита | Настраивается вручную, требует понимания | Реализована на уровне платформы |
Промежуточный итог
После первых трех этапов у вас есть работающий кластер PostgreSQL с репликацией между ЦОДами. Он может принимать запросы и автоматически переключаться при отказе мастера.
Трудозатраты на запуск: более 100 человеко-часов для Self-managed, менее 2 часов для Managed-решения
Но это только фундамент. Кластер работает, но вы не знаете, что внутри происходит. Бэкапов нет. Аудита нет. Это Production в том смысле, что он обслуживает пользователей. Но это не Production в смысле готовности к инцидентам.
Часть 2. Операционная надстройка
Следующие три этапа — это то, что превращает работающую базу в надежную систему: бэкапы, мониторинг и безопасность. Без них первый серьезный инцидент станет катастрофой.
Этап 4. Резервное копирование
Что делаем на этом этапе:
настраиваем регулярные полные бэкапы через pg_basebackup;
настраиваем непрерывную архивацию WAL для Point-in-time Recovery;
организуем многоуровневое хранение: локальные бэкапы для быстрого восстановления, S3-совместимое хранилище для надежности, Offsite-копия для защиты от катастрофы в ЦОДе;
автоматизируем все через pgBackRest или Barman;
настраиваем Retention-политики.
Где кроются сложности. Сделать бэкап не так сложно, как восстановиться из него, когда Production лежит и бизнес теряет деньги.
Бэкапы нужно валидировать, то есть регулярно проверять восстановление на тестовом стенде. Не раз в год при аудите, а как минимум ежеквартально. В идеале — автоматически каждую неделю.
Полный бэкап — это снимок на определенный момент. Чтобы восстановиться на произвольное время между бэкапами, нужна непрерывная архивация WAL-сегментов. Если часть сегментов потеряется, восстановление возможно только до момента последнего доступного сегмента.
Сколько хранить бэкапы? Зависит от требований бизнеса и регуляторов. Для некоторых данных — пять лет. Это означает систему хранения, которая справится с объемом, и процесс, который гарантирует целостность архивов все это время.
Бэкап базы в 500 ГБ восстанавливается несколько часов. Если RTO бизнеса — 15 минут, нужны другие подходы: реплики для быстрого переключения, инкрементальные бэкапы, параллельное восстановление.
Трудозатраты на настройку бэкапов. 24–32 человеко-часа.
Self-managed | Managed-решения, DBaaS | |
Настройка | 24–32 чч | 0 чч |
Что делает инженер | Настройка pg_basebackup, WAL-архивации, pgBackRest, Retention, хранилища | Включено по умолчанию, настройка расписания и Retention в интерфейсе |
PITR | Требует отдельной настройки и тестирования | Встроен, восстановление на любой момент в пределах Retention |
Валидация | Ручная или требует отдельной автоматизации | Автоматическая проверка целостности |
Этап 5. Мониторинг и алертинг
Это самая трудоемкая часть операционки, причем и для запуска, и для дальнейшей поддержки. Если предыдущие этапы можно настроить и забыть (с периодическими проверками), то мониторинг требует внимания каждый день. Дальше станет понятно почему.
Что делаем на этом этапе:
устанавливаем и настраиваем стек мониторинга: PostgreSQL Exporter для сбора метрик, Prometheus для хранения, Grafana для визуализации;
определяем ключевые метрики и их критичные пороги;
настраиваем алерты с маршрутизацией: что идет в мессенджер, что будет требовать дежурного через PagerDuty, что пишется в тикет;
создаем Runbook для типовых инцидентов.
Где кроются сложности. Собирать метрики технически несложно. Гораздо сложнее построить какую-то понятную, полезную и работающую систему.
PostgreSQL отдает десятки метрик. Особое внимание стоит обратить на эти:
Connections — сколько используется из max_connections;
Cache Hit Ratio — доля запросов из памяти;
Replication Lag — насколько реплика отстает;
Transaction Rate и Latency — общая картина нагрузки;
длительные транзакции — запросы дольше пяти минут стоит расследовать;
дисковое пространство — банально, но это одна из частых причин аварий.
Слишком чувствительные алерты порождают Alert Fatigue, «усталость» от сигналов. Дежурные перестают реагировать, когда каждую ночь приходит десяток ложных срабатываний. Слишком мягкие тоже опасны — выше риск пропустить реальную проблему. Нужен итеративный процесс: начать с консервативных порогов, анализировать False Positives, корректировать.
Алерт без инструкции по реагированию бесполезен. Для каждого критичного алерта нужен документ, Runbook: что проверить, какие команды выполнить, когда эскалировать.
При 2–3 алертах в неделю каждый требует 30–60 минут на диагностику и исправление. Это ~100 часов в год. Донастройка порогов — ~20–30 часов. Постмортемы — ~20–30 часов. Обновление Runbook — ~10–20 часов. Обновление стека мониторинга — ~10–20 часов.
Трудозатраты на настройку мониторинга. Более 40 человеко-часов. И это только начало: настройка порогов и Runbook продолжается месяцами.
Self-managed | Managed-решения, DBaaS | |
Настройка | >40 чч | <2 чч |
Что делает инженер | Установка Prometheus, Grafana, экспортеры, настройка алертов, написание Runbook | Подключение к встроенным метрикам, настройка порогов под свою нагрузку |
Дашборды | Создаются с нуля или адаптируются из Community | Готовые, специфичные для PostgreSQL, с Best Practices |
Этап 6. Безопасность и Compliance
Что делаем на этом этапе:
настраиваем SSL/TLS для шифрования всего трафика: между приложениями и базой, между мастером и репликами;
внедряем pgAudit для логирования операций с данными;
настраиваем соответствие требованиям регуляторов;
определяем процедуры управления доступом: ротация паролей, отзыв привилегий при увольнении, сертификаты и их жизненный цикл.
Где кроются сложности. Безопасность базы данных — это процесс, который требует экспертизы и постоянного внимания.
Настроить SSL вроде бы можно за несколько команд. Но дальше начинаются вопросы. Какие Cipher Suites разрешить? Как управлять сертификатами? Что произойдет, когда действие сертификата истечет в три часа ночи? Нужна комплексная система: мониторинг срока действия, автоматическое обновление или процедура ручной ротации с напоминаниями.
pgAudit позволяет логировать все операции с данными: SELECT, INSERT, UPDATE, DELETE. Это требование многих стандартов. Но логи нужно куда-то складывать, ротировать, анализировать. При активной нагрузке объем логов измеряется гигабайтами в сутки.
Для российских компаний актуальны:
152-ФЗ — персональные данные, почти всегда;
PCI DSS — если храните данные платежных карт;
ГОСТ Р 57580.1-2017 — для финансовых организаций;
отраслевые стандарты — медицина, телеком, госсектор.
Для самостоятельной реализации требований регуляторов нужно правильно интерпретировать требования, документировать реализованные меры, проходить проверки. Ошибки стоят дорого: штрафы, предписания, в некоторых случаях приостановка деятельности.
Трудозатраты на настройку безопасности. 24–32 человеко-часа на базовую настройку. Для Compliance-требований — отдельный проект.
Self-managed | Managed-решения, DBaaS | |
Настройка | 24–32 чч + Compliance-проект | 0 чч |
Что делает инженер | Настройка SSL/TLS, pgAudit, процедуры ротации | Шифрование включено по умолчанию, аудит настраивается в интерфейсе |
Сертификаты | Ручное управление жизненным циклом | Автоматическая ротация |
Compliance | Требует отдельной проработки и аттестации | Аттестация УЗ-1, PCI DSS, ГОСТ Р 57580.1-2017 — на уровне платформы |
Сводная картина
Этап | Self-managed: запуск | Self-managed: поддержка/год | DBaaS: запуск | DBaaS: поддержка/год |
Подготовка инфраструктуры | >40 чч | — | <1 чч | 0 чч |
Установка и настройка | 16–24 чч | 20–40 чч | 0 чч | 0 чч |
Отказоустойчивость | >40 чч | 60–80 чч | <1 чч | 0 чч |
Резервное копирование | 24–32 чч | 30–50 чч | 0 чч | <10 чч |
Мониторинг и алертинг | >40 чч | 150–200 чч | <2 чч | 20–40 чч |
Безопасность | 24–32 чч | 40–60 чч | 0 чч | <10 чч |
ИТОГО | >180 чч | >300 чч/год | <5 чч | <60 чч/год |
Откуда берутся часы поддержки при Self-managed. Подготовка инфраструктуры — разовая работа. Установка и настройка (20–40 чч/год) — тюнинг параметров под изменившуюся нагрузку. Отказоустойчивость (60–80 чч/год) — регулярное тестирование Failover, обновления Patroni и etcd. Резервное копирование (30–50 чч/год) — проверка восстановления. Мониторинг (150–200 чч/год) — реагирование на алерты, донастройка порогов, постмортемы. Безопасность (40–60 чч/год) — ротация сертификатов и паролей, патчи.
Почему один сотрудник не справится за 300 часов? 300 часов — это примерно 15–20% годовой загрузки одного специалиста. На первый взгляд немного. Но эти часы распределены неравномерно: инциденты случаются ночью и в выходные, обновления требуют согласованного времени, тестирование Failover нужно планировать. Нужен либо дежурный график, либо готовность реагировать вне рабочего времени.
Что остается на стороне пользователя при использовании Managed-сервиса? Настройка и корректировка порогов алертов под свою нагрузку, анализ Slow Queries, управление Retention-политиками бэкапов, работа с пользователями и привилегиями. Инфраструктурные задачи — обновления, патчи, Failover — берет на себя платформа.
Что с этими цифрами делать
Формула для расчета стоимости владения: (Часы на запуск + Часы поддержки × Количество лет) × Ставка специалиста = TCO
Подставьте вашу ставку DBA или DevOps. Для Self-managed при горизонте в три года получите трудозатраты: 180 + (300 × 3) = более 1 000 человеко-часов. Для VK Cloud DBaaS: 5 + (60 × 3) = менее 200 человеко-часов.
Разница — более 800 человеко-часов за три года. В деньгах, в зависимости от ставки, это от 500 тыс. ₽ до нескольких миллионов. И это только работа специалистов — без учета железа, лицензий, электричества, аренды стойко-мест для Self-managed.
Когда Self-managed все-таки оправдан
Было бы нечестно утверждать, что Managed-решение лучше всегда. Есть сценарии, где Self-managed — осознанный и правильный выбор.
Специфические требования к конфигурации. Нужен форк PostgreSQL с кастомными патчами. Или нестандартные расширения, которые Managed-сервис не поддерживает. Или конфигурация, которая выходит за рамки того, что можно настроить через интерфейс.
Регуляторные ограничения. Некоторые регуляторы требуют, чтобы данные находились в ЦОДе, полностью контролируемом организацией. Не «в облаке с сертификатами», а физически на вашем оборудовании.
Существующая инфраструктура и команда. У вас уже есть ЦОД, железо, сильная DBA-команда. Инвестиции сделаны, компетенции есть, процессы отлажены. Переход на Managed-сервис не даст экономии — только добавит стоимость сервиса поверх существующих затрат.
Мультиоблачная архитектура. Стратегическое решение не привязываться к одному провайдеру. Self-managed PostgreSQL работает одинаково в любом ЦОДе, на любом облаке, на собственном железе. Переезд — вопрос инфраструктуры, а не миграции данных и логики.
Во всех этих случаях таблица трудозатрат выше остается актуальной — просто эти затраты осознанные и обоснованы бизнес-требованиями.
Вывод
Вопрос «Сколько стоит развернуть PostgreSQL?» неправильный. Правильный вопрос — «Сколько стоит эксплуатировать Production-ready PostgreSQL в следующие три-пять лет?».
Установка — это менее 15% трудозатрат Self-managed. Остальное — отказоустойчивость, бэкапы, мониторинг, безопасность и ежедневная операционная работа.
У VK Cloud есть Managed-решение VK Cloud DBaaS. В нем 85% берет на себя провайдер. Вы получаете Production-ready-кластер с SLA, автоматическими бэкапами, мониторингом и Compliance-сертификатами. Ваша команда фокусируется на том, что создает ценность для бизнеса: схема данных, оптимизация запросов, логика приложения.
Решение между Self-managed и DBaaS — это не вопрос «Что лучше?». Это вопрос «Где ваша команда создает больше ценности: в настройке Patroni или в развитии продукта?». И ответ на этот вопрос как раз и поможет принять правильное решение.
