L'essentiel
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
1
Récupérer la chaîne de connexion depuis le dashboard Aurabase
Section Base de données de votre projet, format standard postgresql://user:password@host:5432/dbname.
2
Créer une base de test séparée, jamais votre base de production
psql "$AURABASE_CONN" -c "CREATE DATABASE bench_test;"
pgbench et sysbench-tpcc créent, remplissent et modifient des tables. Utilisez toujours une base dédiée, jamais un schéma qui sert du trafic réel.
Initialiser et lancer un premier run
1
Initialiser le jeu de données
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = facteur d'échelle (10 × 100 000 lignes dans pgbench_accounts)
2
Lancer un run de 60 secondes, 10 clients concurrents
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
3
Lire le résultat
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
1
Installer sysbench et le plugin tpcc
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # suivre le README du dépôt pour la compilation du plugin
2
Préparer le jeu de données TPC-C
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 prepare
3
Lancer le run
./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.