Для каких типов нагрузок PostgreSQL подходит лучше всего, а где стоит выбрать другую базу данных?

Где PostgreSQL показывает себя лучше всего

PostgreSQL — транзакционная реляционная СУБД общего назначения с поддержкой ACID и богатой системой типов. Он хорошо подходит для задач, где важны согласованность данных, сложные запросы и гибкость схемы.

Транзакционные системы с требованиями ACID — финансовые приложения, e-commerce, системы бронирования. Многоверсионное управление конкурентностью (MVCC) позволяет читателям не блокировать писателей, что даёт хорошую конкурентность при высоком rps на смешанных нагрузках.

Аналитика на оперативных данных (OLAP + OLTP) — PostgreSQL поддерживает оконные функции, CTE, LATERAL JOIN, FILTER, GROUPING SETS. На датасетах размером до нескольких сотен гигабайт он часто вытесняет отдельный аналитический склад.

Гетерогенные типы данных — JSONB, массивы, hstore, диапазонные типы (daterange, int4range), UUID, геометрические типы (PostGIS), полнотекстовый поиск, pgvector для ML-эмбеддингов. Всё это — в одной базе с транзакциями.

Сложные схемы с integrity constraints — FK, CHECK, EXCLUDE constraints, partial unique indexes позволяют выражать бизнес-правила на уровне базы, а не только в приложении.

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

Где стоит рассмотреть другую базу

Очень высокая запись с простой моделью данных — если нужно писать миллионы событий в секунду (логи, метрики, IoT), лучше подойдут TimescaleDB (расширение над PostgreSQL, но оптимизированное для time-series), ClickHouse (колоночный OLAP) или Apache Kafka + Iceberg. PostgreSQL при write-heavy нагрузке упирается в WAL и checkpoint I/O.

Горизонтальное масштабирование записи (sharding) — PostgreSQL нативно не поддерживает automatic sharding. Для глобального масштабирования на запись используют CockroachDB, YugabyteDB или Vitess (над MySQL). Citus даёт sharding над PostgreSQL, но требует операционных усилий.

Граф-запросы — рекурсивные CTE работают, но для graph traversal на больших графах Apache AGE (расширение) или специализированные Neo4j / Amazon Neptune дадут лучшую производительность и более выразительный язык (Cypher).

Кэш и очереди — Redis выигрывает по латентности для key-value операций, pub/sub и структур данных в памяти. PostgreSQL как очередь (LISTEN/NOTIFY или таблица задач) работает, но при больших объёмах лучше взять специализированное решение (RabbitMQ, NATS).

Документо-ориентированные схемы без реляций — если данные — плоские JSON-документы без JOIN-запросов и нужна горизонтальная масштабируемость, MongoDB или DynamoDB могут быть проще в операционном управлении. Но если join-ы нужны хотя бы иногда — JSONB в PostgreSQL чаще оказывается выигрышным вариантом.

Практические ориентиры

• До 10 TB данных, смешанная нагрузка read/write, нужны транзакции и сложные запросы — PostgreSQL.
• Миллиарды временных точек, агрегация по диапазонам — TimescaleDB или ClickHouse.
• Сотни тысяч write/s с простой схемой — Cassandra, ScyllaDB.
• Граф-траверсал, алгоритмы на графах — Neo4j.
• Sub-millisecond key-value — Redis, Dragonfly.

Подводные камни

• PostgreSQL не масштабируется по записи горизонтально из коробки — при планировании нагрузки > 50k writes/s нужно проектировать с учётом этого ограничения заранее.
• VACUUM и autovacuum — уникальная операция PostgreSQL; при неправильной настройке table bloat накапливается незаметно, пока не начнётся деградация производительности.
• Параллельное выполнение запросов (parallel query) появилось в PostgreSQL 9.6 и до сих пор имеет ограничения: не все планы параллелизуются, настройки max_parallel_workers влияют на CPU-конкуренцию.
• PostgreSQL не умеет multi-master out of the box — Patroni, Citus или pgEdge нужны для HA с возможностью записи на нескольких узлах.
• Переоценка JSONB: хранить всё в jsonb «для гибкости» ведёт к потере преимуществ реляционной модели, типизации и query performance.

• Объяснять PostgreSQL только через определение, без задачи и границ применимости
• Перечислять функции PostgreSQL, но не показывать, какую проблему они решают
• Называть PostgreSQL универсальным выбором для любых проектов

• Понимает назначение PostgreSQL, а не только определение
• Связывает инструмент с классом задач и ограничениями
• Умеет объяснить технологию простым языком