ClickHouse против PostgreSQL для аналитики

Это не «кто лучше», а «кто для чего» — и когда стоит держать обе базы.

PostgreSQL — универсальная строковая СУБД с сильными транзакциями; ClickHouse — специализированная колоночная СУБД под аналитику. Они дополняют друг друга.

Где силён каждый

КритерийPostgreSQLClickHouse
Хранениестроковоеколоночное
Транзакции (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.
  • Выбор зависит от типа нагрузки, а не от того, «кто вообще лучше».
Проверьте себя
1. Для какой задачи PostgreSQL предпочтительнее ClickHouse?
AОтчёт-агрегация по миллиарду строк
BАтомарное оформление заказа с транзакцией и точечными правками
CАнализ логов за год
DХранение метрик временных рядов
2. Какая архитектура часто встречается в зрелых системах?
AТолько ClickHouse для всего
BТолько PostgreSQL для всего
CPostgreSQL для OLTP-приложения и ClickHouse для OLAP-аналитики, данные текут из первой во вторую
DСлучайный выбор для каждого запроса