TL;DR
- Benchmark de Postgres managed by ClickHouse face à AWS RDS (16k IOPS provisionnées) et Aurora IO Optimized à l’aide des tests standard
pgbench
- Performances : le Postgres de ClickHouse, basé sur des NVMe, offre des performances 4,3 à 9 fois supérieures pour les charges de travail à forte intensité d’IO, et 12 % de mieux dans les scénarios limités par le CPU
- Idéal pour les charges de travail à forte croissance pilotées par l’IA qui exigent des taux de transactions élevés, un accès aux données à faible latence et des performances prévisibles sans goulots d’étranglement liés aux IO
pgbench, l’outil de benchmarking standard de PostgreSQL, afin d’évaluer les performances de la charge de travail dans des scénarios de concurrence modérée et élevée.
Tous les tests de performance ont été effectués à l’aide d’une VM cliente disposant de la même capacité de calcul, située dans la même région et la même zone de disponibilité que la base de données PostgreSQL, afin de garantir une comparaison équitable.
Test 1 : E/S intensives - Lecture+écriture (jeu de données de 500 GB)
- TPS supérieurs de 326 % (4,3x plus rapide)
Amélioration des performances par rapport à Aurora IO Optimized :
- TPS supérieurs de 345 % (4,5x plus rapide)
Analyse : Les charges de travail mixtes de lecture/écriture mettent en évidence les gains de performance les plus marqués du stockage NVMe et représentent le scénario le plus réaliste pour des charges de travail pilotées par l’IA en forte croissance, qui exigent à la fois une ingestion de données à haut débit et des lectures à faible latence. Postgres managed by ClickHouse a atteint 19,8k TPS avec un niveau de concurrence plus élevé, démontrant que le stockage NVMe passe efficacement à l’échelle sous charge. Cela le rend 4,3 à 4,5x plus rapide que RDS et Aurora. Les solutions de stockage en réseau ont eu du mal avec les opérations à forte composante d’écriture, RDS et Aurora plafonnant à 4,4k-4,6k TPS malgré la capacité provisionnée, et même avec la configuration IO Optimized d’Aurora.
Ce test évalue les performances mixtes en lecture/écriture avec un important jeu de données de 500 Go, en sollicitant à la fois les voies de lecture et d’écriture du sous-système de stockage.
Configuration de l’instance :
| Configuration | Postgres managed by ClickHouse | RDS with 16k IOPS | Aurora IO Optimized |
|---|
| Version PG | 17 | 17 | 17 |
| vCPU | 16 | 16 | 16 |
| RAM | 64 GB | 64 GB | 128 GB |
| Taille du disque | 1 TB | 1 TB | 1 TB |
| Type de disque | NVMe (IOPS illimités) | stockage en réseau (16,000 IOPS) | stockage en réseau (IO Optimized) |
# Initialize database (500 GB dataset)
pgbench -i -s 34247
# Read+Write benchmark
pgbench -c 256 -j 16 -T 600 -M prepared -P 30
Test 2 : E/S intensives - lecture seule (jeu de données de 500 Go)
- 802 % de TPS en plus (9,0x plus rapide)
Analyse : L’écart de performances se creuse nettement pour les charges de travail à forte lecture, limitées par les E/S. Postgres managed by ClickHouse a atteint 84,8K TPS, tandis que RDS avec 16 000 IOPS provisionnées n’a atteint que 9,4K TPS malgré des ressources de calcul équivalentes. La différence clé : le stockage NVMe de ClickHouse monte en charge avec une concurrence plus élevée, tandis que le stockage réseau reste limité par les plafonds d’IOPS provisionnées. Même avec des IOPS provisionnées, RDS restait 9x plus lent que ClickHouse, ce qui montre à quel point l’architecture de stockage est déterminante pour les charges de travail intensives en E/S.
Ce test évalue les performances en lecture sur un vaste jeu de données de 500 Go qui ne tient pas en mémoire, mettant à l’épreuve les capacités d’E/S du disque.
Configuration de l’instance :
| Configuration | Postgres managed by ClickHouse | RDS with 16k IOPS |
|---|
| Version PG | 17 | 17 |
| vCPUs | 16 | 16 |
| RAM | 64 GB | 64 GB |
| Taille du disque | 1 TB | 1 TB |
| Type de disque | NVMe (IOPS illimitées) | Stockage en réseau (16 000 IOPS) |
# Initialize database (500 GB dataset)
pgbench -i -s 34247
# Read-only benchmark
pgbench -c 256 -j 16 -T 600 -M prepared -P 30 -S
Test 3 : charge CPU élevée (les données tiennent en mémoire)
- 12,3 % de TPS en plus par rapport à RDS PostgreSQL
Analyse : Même dans des scénarios où le CPU est le facteur limitant et où les E/S disque sont minimes, Postgres managed by ClickHouse est arrivé en tête avec 36,5K TPS. Bien que les deux services aient atteint 100 % d’utilisation du CPU, le stockage NVMe de ClickHouse a offert de meilleures performances grâce à un meilleur taux de réussite du cache. L’avantage de 12 % sur RDS démontre l’efficacité de l’infrastructure sous-jacente, même lorsque les charges de travail sont principalement limitées par le CPU.
Ce test évalue les performances du CPU lorsque l’ensemble de travail tient entièrement en mémoire, ce qui minimise l’impact des E/S disque.
Configuration de l’instance :
| Configuration | Postgres managed by ClickHouse | RDS PostgreSQL |
|---|
| Version PG | 17 | 17 |
| vCPU | 2 | 2 |
| RAM | 8 GB | 8 GB |
| Type de disque | NVMe | stockage en réseau (gp3) |
# Initialize database (2 GB dataset)
pgbench -i -s 136
# Warm-up run to load dataset into memory
pgbench -c 1 -T 60 -S -M prepared
# Run benchmark (read-only, prepared statements)
pgbench -c 32 -j 16 -T 300 -S -M prepared -P 30
- Charges de travail de lecture/écriture intensifs en IO : TPS 4,3 à 4,5x plus élevés que RDS (16k IOPS) et Aurora IO Optimized
- Charges de travail de lecture intensifs en IO : TPS 9x plus élevés que RDS with 16k IOPS
- Charges de travail limités par le CPU : TPS 12 % plus élevés que RDS
Quand Postgres by ClickHouse se démarque
- Prennent en charge des charges de travail d’IA en forte croissance nécessitant une ingestion de données à haut débit, avec des upserts fréquents, des mises à jour de features en temps réel et des capacités analytiques prêtes à l’emploi grâce à une intégration fluide avec ClickHouse pour les charges de travail OLAP
- Effectuent fréquemment des écritures, des mises à jour ou des opérations mixtes de lecture/écriture
- Ont besoin d’un stockage prévisible et très performant
- Sont actuellement limitées par les plafonds d’IOPS des services Managed Postgres traditionnels
Si vous prévoyez d’avoir des besoins analytiques par la suite et anticipez une intégration plus poussée avec ClickHouse — ce qui est courant dans les charges de travail d’IA modernes, où les données transactionnelles alimentent des tableaux de bord en temps réel, des feature stores et des pipelines de ML — Postgres by ClickHouse devrait être votre choix par défaut. L’intégration native élimine les pipelines ETL complexes et permet une circulation fluide des données entre votre base de données opérationnelle et vos requêtes analytiques.
Avantage de l’architecture NVMe
| Aspect | Stockage NVMe (Managed Postgres) | Stockage réseau (IOPS provisionnés) |
|---|
| IOPS | 100k à quasi illimité | 16 000 provisionnés |
| Sauts réseau | Aucun (périphérique local) | Chaque opération disque nécessite un aller-retour réseau |
| Évolutivité des performances | Évolue linéairement avec la concurrence | Limitée par les IOPS provisionnés |
- Débit par dollar plus élevé : obtenez 4 à 9 fois plus de TPS que RDS avec 16k IOPS provisionnés et Aurora IO Optimized
- Coûts prévisibles : pas besoin de provisionner de capacité IOPS supplémentaire — IOPS locales illimitées incluses
- Besoins en ressources de calcul réduits : atteignez les performances cibles avec des tailles d’instance plus petites grâce à des E/S efficaces
- Moins besoin de read replicas : un débit plus élevé sur une seule instance réduit le besoin de mise à l’échelle horizontale
Pour les charges de travail actuellement limitées par les plafonds d’IOPS, passer à Managed Postgres peut éliminer le besoin d’IOPS provisionnés coûteux ou de configurations IO Optimized, tout en offrant des performances nettement supérieures.
Les données complètes du benchmark, les configurations et les métriques détaillées sont disponibles dans notre tableur des résultats du benchmark.
Ressources supplémentaires
Dernière modification le 25 juin 2026
