Contexte et objectif

PlanetScale a présenté Neki en aperçu de plateforme et a immédiatement cherché à valider la capacité du système à supporter un trafic de l’ordre du million de requêtes par seconde. L’objectif initial était de stabiliser 200 k QPS sur chaque fragment (shard) avant d’augmenter le nombre de fragments pour multiplier le débit global. Cette démarche a permis de mesurer la linéarité du scaling et d’identifier les marges de performance restantes.

Architecture du benchmark

Le test a exploité 512 shards, chaque shard hébergeant un serveur PostgreSQL primaire exécuté sur une instance r8g.16xlarge. Aucun réplica n’était déployé, ce qui a éliminé la surcharge de réplication et a isolé la charge de lecture. Les requêtes, strictement des sélections pointées par clé primaire, ont transitée par 480 routeurs Neki, chacun installé sur une instance 8xlarge. Le modèle d’accès était entièrement « single‑shard », sans jointures, écritures ni requêtes traversant plusieurs shards, garantissant ainsi que chaque fragment recevait une charge indépendante.

Résultats chiffrés et analyse

Sur une durée de 16 minutes, le cluster a atteint 118 538 803 QPS, avec un pic enregistré à 118 747 267 QPS. Chaque shard a finalement traité 231 k QPS, soit 15 % au‑dessus du seuil cible de 200 k QPS, démontrant une marge de headroom. Le p99 de latence s’est établi à 6,06 ms au niveau du routeur et à 13,95 ms côté client, ce qui indique que la majorité du temps de réponse provient du réseau et du traitement du routeur plutôt que du moteur de base de données. Le système a généré 67 erreurs par seconde, soit un taux d’erreur d’environ 1 requête sur 1,8 million, ce qui reste négligeable à ce niveau de charge. Au total, le cluster a produit 15,8 M IOPS de lecture et a consommé plus de 2 Tb/s de bande passante réseau, confirmant que le facteur limitant était principalement la capacité réseau et non le stockage.

Limites et perspectives

Le benchmark se limite à un workload en lecture seule, sans écritures, jointures ni requêtes multi‑shards ; les performances observées ne se généralisent donc pas à des charges transactionnelles complexes. De plus, l’absence de réplication exclut l’évaluation de la résilience en cas de basculement, un aspect critique pour les environnements de production. Enfin, la saturation du routeur à plus de 2 Tb/s suggère que l’évolutivité future devra s’appuyer sur des optimisations réseau ou des architectures de routage parallélisées. PlanetScale indique qu’une prochaine publication détaillera les défis d’ingénierie rencontrés pour franchir la barre des 100 M QPS, notamment la gestion du trafic, la distribution de la charge et la stabilité sous charge prolongée.