Postgres вместо зоопарка баз данных: когда хватит одной

Нужно кэширование — добавляем Redis. Полнотекстовый поиск? Прикручиваем Elasticsearch. Фоновые задания? Снова Redis или, может быть, Sidekiq. Документы с гибкой схемой? Берём MongoDB. Аналитика? Snowflake. События? Kafka. Не успеешь оглянуться, как твоё «простое» приложение общается с семью разными хранилищами и микросервисами, у каждого из которых собственный деплой, стратегия резервного копирования, сценарии отказов и ночные алерты, когда они перестают разговаривать друг с другом. Каждая система увеличивает операционную нагрузку: мониторинг, оповещения, тестирование отказоустойчивости, патчи безопасности, обновление версий.

Несколько систем, которые нужно эксплуатировать и мониторить.

Одна база данных. Одна стратегия резервного копирования. Один набор сценариев отказов.

Этот аргумент звучит постоянно. Но какой процент программных проектов вообще когда-либо достигает так называемого «веб-масштаба»? Около 0,3%? Стоит ли вашему стартапу или SaaS-продукту тратить токены инноваций (innovation tokens) на множество микросервисов и баз данных вместо решения реальной задачи?

Если компании с миллионами пользователей — Notion, Netflix, Instagram и другие — доверяют «скучным» технологиям, то ваш стартап, скорее всего, обойдётся без архитектуры из семи баз данных. К тому же, если вы когда-нибудь действительно дорастёте до веб-масштаба и исчерпаете возможности Postgres, вы всегда сможете добавить недостающие компоненты — тогда, когда они действительно понадобятся.

Прежде чем тянуться за новой базой данных, проверьте, справится ли Postgres с тем, что вам нужно:

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