← На главную

Postgres хватит для всего: не множьте лишних БД

06.07.2026 14:57 · hackernews

Всё началось с простой мысли: Postgres не лучший инструмент для всего, но для большинства задач его достаточно. Проблема в том, что команды плодят микросервисы и базы данных раньше времени. Это преждевременная оптимизация. Типичная картина: для кэша добавляют Redis, для поиска — Elasticsearch, для фоновых задач — ещё один Redis или Sidekiq, для гибких схем — MongoDB, для аналитики — Snowflake, для событий — Kafka. В итоге простое приложение общается с семью разными хранилищами, у каждого своё развёртывание, бэкапы, сценарии отказов и ночные алерминги, когда они перестают понимать друг друга.

Каждая новая система увеличивает operational surface area: мониторинг, оповещения, тесты failover, патчи безопасности, обновления версий. С Postgres всё проще — одна база, одна стратегия бэкапов, один набор отказов.

Возражение «Postgres не тянет webscale» слышно постоянно. Но какой процент проектов реально дорастает до этого самого webscale? Примерно 0,3%. Стоит ли стартапу жечь «инновационные токены» на кучу баз данных вместо решения реальных проблем? Если компании вроде Notion, Netflix, Instagram доверяют «скучным» технологиям, ваш стартап наверняка переживёт без семи баз. А если Postgres действительно упрётся в потолок — можно добавить специализированные инструменты, когда они реально понадобятся.

Прежде чем тянуться за очередной базой, стоит проверить, что уже есть в Postgres. Вместо Redis — UNLOGGED tables и materialized views. Вместо очередей — SKIP LOCKED, pgmq, pgflow. Вместо Elasticsearch — tsvector, pg_trgm, ParadeDB. Вместо MongoDB — JSONB, FerretDB. Вместо Pinecone для векторов — pgvector, pgvectorscale. Вместо InfluxDB — TimescaleDB, pg_partman. Вместо Snowflake — pg_analytics, DuckDB integration. Вместо Neo4j — Apache AGE, рекурсивные CTE. Вместо специализированных GIS — PostGIS.

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

Читать оригинал →