ClickHouse запустила PostgresBench — открытый бенчмарк для сравнения managed Postgres-сервисов. В основе — pgbench с TPC-B-нагрузкой: короткие транзакции с частыми записями и обновлениями. Тест симулирует реальные паттерны — платежи, заказы, обновления инвентаря.
Каждый прогон идёт 10 минут с 256 клиентами и 16 потоками. Использовали два размера данных: ~100 GB (scale factor 6849) и ~500 GB (34247). Меряли TPS, среднюю задержку, P95 и P99. Для сервисов выбрали инстансы 4 vCPU / 16 GB RAM и 16 vCPU / 64 GB RAM (кроме Aurora — там 1:8 CPU-to-RAM). Все тесты в us-east-2, без HA, с настройками «из коробки». Конфигурации каждой системы опубликованы на GitHub.
Протестировали пять сервисов: Postgres managed by ClickHouse, AWS Aurora PostgreSQL, AWS RDS for PostgreSQL, Neon и Crunchy Bridge. Результаты на 100 GB (small/large): - Postgres managed by ClickHouse: 6172 TPS / 28668 TPS - Aurora: 2685 / 12628 - RDS: 4882 / 8133 - Neon: 2847 / 8563 - Crunchy Bridge: 6338 / 14790
На 500 GB (large): - ClickHouse: 26328 TPS - Crunchy Bridge: 11113 - Aurora: 10402 - Neon: 7802 - RDS: 5092
Почему такой разрыв? Postgres managed by ClickHouse использует NVMe-хранилище, физически расположенное на том же узле, что и вычисления. Это даёт микросекундные задержки доступа к диску и стабильно высокие IOPS без разделения с другими клиентами. В конкурентах — сетевые хранилища вроде EBS или объектные слои: каждый fsync на коммит транзакции требует подтверждения от удалённого хранилища, что для write-heavy нагрузок резко накапливает задержки.
Весь код бенчмарка открыт — репозиторий на github.com/ClickHouse/PostgresBench. Любой может запустить скрипт на своём инстансе, получить JSON с результатами и отправить Pull Request. ClickHouse обещает проверять конфигурации и публиковать результаты — чтобы сделать PostgresBench самым полным открытым справочником по производительности managed Postgres.