Benchmarker votre Postgres Aurabase avec pgbench, sysbench et TPC-C
Aurabase provisionne du PostgreSQL 16 standard, sans surcouche propriétaire — ce qui veut dire que tous les outils de benchmark Postgres de l'écosystème fonctionnent directement contre votre base Aurabase. Voici comment mesurer vous-même ses performances avec les trois outils de référence, plutôt que de vous fier à un chiffre marketing publié par quiconque.
pgbench (outil officiel PostgreSQL, workload proche de TPC-B) et sysbench-tpcc (workload TPC-C plus représentatif d'une charge transactionnelle réelle) tournent tous deux directement contre la chaîne de connexion Postgres 16 standard de votre projet Aurabase — aucune API propriétaire à contourner. Ce tutoriel montre les commandes réelles, et où s'arrête ce qu'un chiffre de tps peut légitimement prouver.
pgbench pour la simplicité, sysbench-tpcc pour le réalisme
pgbench est distribué avec PostgreSQL lui-même : aucune installation séparée sur le client si vous avez déjà les outils client Postgres. Son workload par défaut reproduit une charge proche du benchmark TPC-B historique — simple, rapide à lancer, utile pour un premier signal.
sysbench est un outil de benchmark plus général, avec un plugin sysbench-tpcc qui reproduit le workload TPC-C — un mélange de transactions représentatif d'une application OLTP réelle (commandes, paiements, stock), plus proche de ce que votre backend Aurabase encaisse en production que le workload générique de pgbench.
Récupérer la chaîne de connexion et créer une base de test dédiée
Section Base de données de votre projet, format standard postgresql://user:password@host:5432/dbname.
psql "$AURABASE_CONN" -c "CREATE DATABASE bench_test;"
Initialiser et lancer un premier run
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = facteur d'échelle (10 × 100 000 lignes dans pgbench_accounts)
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = clients concurrents · -j = threads · -T = durée en secondes · -P = rapport toutes les 5s
pgbench affiche un tps (transactions par seconde) en fin de run, avec et sans le temps de connexion. Notez le facteur d'échelle, le nombre de clients et la durée à chaque run — sans ces trois paramètres, le chiffre seul ne veut rien dire.
Un workload transactionnel plus représentatif
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # suivre le README du dépôt pour la compilation du plugin
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 prepare
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 run
Un guide de tuning sysbench-tpcc dédié à PostgreSQL a été publié par Percona en mai 2026 — utile pour ajuster shared_buffers et work_mem avant de lancer un run représentatif.
Ce qu'un chiffre de tps ne prouve pas seul
Le tps dépend du facteur d'échelle, du nombre de clients concurrents, du matériel sous-jacent et des réglages Postgres actifs au moment du run. Deux chiffres de tps obtenus avec des paramètres différents ne sont pas comparables, même sur la même base de données.
Pour que votre résultat serve de référence reproductible, documentez systématiquement : version de Postgres, facteur d'échelle, nombre de clients/threads, durée du run, et la configuration postgresql.conf effective. Voir notre méthodologie de benchmark complète pour le protocole que nous appliquons avant de publier un chiffre.
Tuning Postgres avant de relancer un run
Un run de benchmark révèle souvent un goulot d'étranglement avant tout réglage — connexions saturées, autovacuum en retard, index manquant. Notre checklist de tuning Postgres en production et notre article sur le dimensionnement de max_connections couvrent les réglages à vérifier avant de relancer un run.