Comment nous benchmarquons un backend : méthodologie complète et reproductible

Convex, éditeur d’un backend réactif concurrent, a pris ses distances publiquement avec ce que son équipe technique appelle la « guerre des bar charts » entre fournisseurs de bases de données. Sa formule est directe : « It’s scaling theater, not scaling » — du théâtre de passage à l’échelle, pas du passage à l’échelle réel (stack.convex.dev/on-competitive-benchmarks, blog technique Stack, consulté le 23 août 2026).

Son argument central : un benchmark qui compare deux systèmes aux garanties de cohérence, de topologie ou de modèle de tarification différents ne teste souvent pas la même chose, même quand il prétend le faire — « the benchmark is not actually testing the same thing ». Ce réflexe a un nom dans l’industrie : le benchmarketing, publier un chiffre choisi pour son effet marketing plutôt que pour sa rigueur méthodologique.

Notre réponse n’est pas de refuser de mesurer — refuser de publier un chiffre indéfiniment serait aussi malhonnête que d’en publier un non étayé. C’est de documenter d’abord comment nous mesurerions, avec quels outils et sous quelles conditions, avant de prétendre avoir mesuré quoi que ce soit. C’est aussi ce qui distingue une comparaison utile (comme notre comparatif Aurabase vs Appwrite, qui documente des différences d’architecture vérifiables) d’un comparatif de chiffres de performance sans protocole commun.

Ça compte particulièrement pour un lead technique ou un CTO qui doit défendre un choix de backend en comité technique : un chiffre qu’on ne peut pas retracer à une méthode ne survit pas à la première question un peu insistante. Un protocole documenté, lui, se défend — on peut montrer le script, la version testée, et refaire tourner le test devant quelqu’un si nécessaire.

Sur le premier point, PlanetScale documente explicitement sa contrainte de parité matérielle : chaque environnement comparé doit tourner sur des ressources de calcul (vCPU, RAM) égales ou supérieures à l’instance de référence, dans la même région cloud (planetscale.com/benchmarks, méthodologie « Telescope », consultée le 23 août 2026). Sans cette discipline, un écart de latence peut simplement refléter une machine plus grosse — pas une architecture plus rapide.

Le même principe s’applique à l’état du cache et à la topologie réseau. Une instance qui vient de démarrer (cache Postgres froid, pool de connexions vide, plan de requête pas encore mis en cache) répond structurellement plus lentement qu’une instance qui tourne depuis une heure sous charge stable. Une requête depuis la même région que la base de données répond structurellement plus vite qu’une requête inter-régions. Deux benchmarks qui ne précisent ni l’un ni l’autre ne sont tout simplement pas comparables, même s’ils affichent des unités identiques.

Sur le second point, le piège s’appelle la coordinated omission. HdrHistogram, le projet de référence sur la mesure de latence créé par Gil Tene, l’explique ainsi : quand un générateur de charge attend la réponse d’une requête avant d’envoyer la suivante (boucle fermée), une pause de service fait mécaniquement chuter le nombre de requêtes envoyées pendant la pause — et donc le nombre de mesures de latence élevée enregistrées (github.com/HdrHistogram/HdrHistogram, consulté le 23 août 2026). Le projet donne un exemple concret et chiffré : sur un système hypothétique qui échantillonne sa latence toutes les 10 ms pendant 200 secondes, une seule pause de 100 secondes au milieu du test suffit à produire, sans correction, un histogramme où environ 99,99 % des réponses semblent tenir sous 1 ms — alors que la moitié du temps réel s’est écoulée dans cette unique pause.

Une moyenne de latence peut sembler excellente alors qu’une requête sur vingt met cinq fois plus de temps. C’est précisément ce que les percentiles révèlent et que la moyenne dissimule structurellement.

Mécaniquement, un percentile n’a rien de mystérieux : triez toutes les latences mesurées par ordre croissant, puis prenez la valeur à la position correspondante. Sur 1000 requêtes triées, le p50 est la 500e valeur, le p95 la 950e, le p99 la 990e. Une seule requête anormalement lente parmi 1000 suffit à faire bouger le p99 — c’est justement sa sensibilité aux cas rares qui le rend utile, là où cette même requête isolée n’a presque aucun effet sur la moyenne.

Signe révélateur : le rapport texte que pgbench — l’outil de benchmark officiel de PostgreSQL — affiche par défaut donne une moyenne et un écart-type, pas des percentiles (postgresql.org/docs/current/pgbench.html, consulté le 23 août 2026). Sa documentation officielle prévient d’ailleurs : « Never believe any test that runs for only a few seconds » — ne croyez jamais un test qui ne tourne que quelques secondes, ce qui vaut autant pour la durée que pour la métrique choisie.

k6, l’outil de charge que nous utilisons pour le niveau 2 de notre suite, résout ça avec des seuils exprimés en percentile : la syntaxe p(95)<500 définit un critère pass/fail — 95 % des requêtes doivent répondre sous 500 ms — directement dans la configuration du test (grafana.com/docs/k6, consulté le 23 août 2026).

1. Préchauffe séparée de la mesure. Criterion.rs remplit les caches CPU/OS avant de chronométrer ; pgbench recommande explicitement de ne jamais croire un run de quelques secondes seulement.
2. Durée fixe, pas un nombre d’itérations fixe. Une charge a besoin de temps pour converger — c’est le rôle des stages k6 et du flag -T de pgbench.
3. Percentiles, jamais seulement la moyenne — et vigilance active sur la coordinated omission si le générateur de charge fonctionne en boucle fermée.
4. Environnement documenté dans le détail : commit git du service testé, version de PostgreSQL, spécification matérielle, version de l’outil de charge. PlanetScale documente ses paramètres TPCC exacts (TABLES=20, SCALE=250, ~500 Go) précisément pour cette raison — sans ces détails, personne ne peut reproduire un run.
5. Résultats horodatés et versionnés, jamais un chiffre unique gravé sur une page marketing sans date. Le tooling actuel écrit déjà dans un dossier daté ; il faudra étendre ce réflexe à toute mesure publiée publiquement, avec la région d’hébergement documentée comme n’importe quelle autre variable d’environnement (voir notre guide sur la souveraineté d’hébergement UE, pertinent dès qu’un chiffre dépend d’une région donnée).
6. Scripts et données brutes publiés à côté du résultat agrégé, pas seulement une moyenne finale. PlanetScale invite même les lecteurs à signaler une erreur de méthodologie sur une adresse dédiée — une posture qu’on trouve saine et qu’on veut reprendre.
7. Débit annoncé à côté de la latence, pas seulement l’un ou l’autre. Un système peut avoir une excellente latence à faible charge et s’effondrer en débit dès que la concurrence augmente — c’est exactement ce que le scénario breakpoint de notre suite k6 (montée en charge jusqu’à rupture) est conçu pour révéler, et ce que la mesure en Throughput::Bytes des micro-benchmarks Criterion capture au niveau fonction.
8. Écart significatif avant d’annoncer une amélioration. Une variation de quelques pourcents entre deux runs peut être du bruit de mesure plutôt qu’un vrai gain — Criterion.rs calcule justement une probabilité que l’écart observé soit dû au hasard avant de le qualifier de régression ou d’amélioration. Un chiffre isolé, sans cette vérification, n’est qu’une anecdote statistique.

Cette liste compte autant que le protocole positif ci-dessus.

• Comparer des topologies différentes (auto-hébergé vs managé, instance à froid vs préchauffée) sans le signaler explicitement.
• Retenir le meilleur run sur dix sans mentionner les neuf autres.
• Publier un chiffre sans date, sans version de service, sans script de reproduction.
• Republier un chiffre marketing existant tant qu’il n’est pas retracé à ce protocole.
• Nous comparer à un concurrent sur un chiffre de performance brut si ce concurrent ne publie pas sa propre méthodologie de façon équivalente — un chiffre contre un silence n’est pas une comparaison, c’est un slogan.

1. Définissez la charge avant l’outil : lecture seule, écriture, mix réaliste pour votre application — pas un ratio générique copié d’un autre projet.
2. Séparez explicitement la phase de préchauffe de la phase de mesure.
3. Faites tourner le test assez longtemps — des minutes, pas quelques secondes.
4. Mesurez en percentiles (p50/p95/p99), jamais en moyenne seule.
5. Vérifiez que votre générateur de charge n’est pas en boucle fermée, ou corrigez la coordinated omission dans l’analyse.
6. Isolez l’environnement testé — pas de voisin bruyant, pas de tâche de fond concurrente.
7. Publiez la version testée, la date, la spécification matérielle et le script — pas seulement le résultat final.

Sur une base Postgres nue, ce protocole tient en une commande pgbench — 20 clients concurrents répartis sur 4 threads, pendant 5 minutes, avec un rapport de progression toutes les 10 secondes :

# Initialiser le jeu de données de test (scale factor >= nombre de clients)
pgbench -i -s 50 ma_base
# -c clients concurrents, -j threads, -T durée en secondes, -P intervalle de rapport
pgbench -c 20 -j 4 -T 300 -P 10 ma_base