ClickHouse против PostgreSQL для аналитики
Это не «кто лучше», а «кто для чего» — и когда стоит держать обе базы.
PostgreSQL — универсальная строковая СУБД с сильными транзакциями; ClickHouse — специализированная колоночная СУБД под аналитику. Они дополняют друг друга.
Где силён каждый
| Критерий | PostgreSQL | ClickHouse |
| Хранение | строковое | колоночное |
| Транзакции (ACID) | да, полноценные | нет в привычном виде |
| UPDATE/DELETE строки | быстрые, обычные | дорогие мутации |
| Точечный поиск по ключу | отличный (B-tree) | не его профиль |
| Большие отчёты-агрегации | медленнее | в десятки-сотни раз быстрее |
| Сжатие | умеренное | очень сильное |
Почему PostgreSQL медленнее на аналитике
Мы это уже разобрали: строковое хранение заставляет читать все колонки, индексы не помогают full-scan'у, нет векторизации по колонкам. PostgreSQL прекрасно обслуживает приложение (заказы, пользователи, корзины), но квартальный отчёт по сотням миллионов строк его «придушит».
Почему ClickHouse не заменяет PostgreSQL
ClickHouse жертвует тем, что не нужно аналитике: нет полноценных транзакций, нет дешёвых точечных UPDATE/DELETE (они реализованы как тяжёлые асинхронные «мутации»), нет гарантий уникальности по ключу. Для оформления заказа, где важна атомарность и точность, это неприемлемо.
Типичная архитектура: вместе, а не вместо
Зрелые системы используют обе базы. PostgreSQL — «операционная» база приложения (OLTP). Данные из неё потоком (через Kafka, CDC или выгрузки) попадают в ClickHouse — «аналитическую» базу (OLAP), где живут дашборды и отчёты:
[приложение] --> [PostgreSQL: OLTP] --поток событий--> [ClickHouse: OLAP] --> [дашборды]
Как выбрать в конкретном случае
- Нужны транзакции, точечные правки, целостность — PostgreSQL.
- Нужны быстрые отчёты по миллиардам строк, логи, метрики — ClickHouse.
- Нужно и то, и другое — обе базы, каждая на своей задаче.
Как работает под капотом
Разница упирается в физическую модель: PostgreSQL хранит строки целиком и оптимизирует точечный доступ через MVCC и B-tree; ClickHouse хранит колонки раздельно, сжимает их и сканирует векторизованно. Один и тот же агрегирующий SQL на одинаковых данных может отличаться по времени на порядки — каждый инструмент быстр на «своей» нагрузке.
Частые ошибки
- Тащить всю аналитику в PostgreSQL «чтобы одна база». Тяжёлые отчёты задушат операционную нагрузку.
- Переносить приложение целиком на ClickHouse. Потеряете транзакции и дешёвые правки строк.
- Сравнивать «в лоб» без учёта нагрузки. Победитель зависит от типа запросов (OLTP vs OLAP).
Итоги
- PostgreSQL — транзакции и точечный доступ; ClickHouse — массовая аналитика.
- ClickHouse не имеет полноценных транзакций и дешёвых правок строк.
- Частое решение — держать обе базы: OLTP в PostgreSQL, OLAP в ClickHouse.
- Выбор зависит от типа нагрузки, а не от того, «кто вообще лучше».