veilletech.frCe qui se passe
PlanetScale ouvre le 10 septembre une platform preview de Neki, du Postgres shardé. L'équipe vient de huit années d'exploitation de clusters MySQL shardés avec Vitess, et constate depuis le lancement de PlanetScale Postgres, il y a un an et demi, que des clients atteignent le plafond d'une seule machine sans bonne option de sortie. Les réponses existantes demandent toutes un sacrifice : le sharding applicatif pousse le routage dans le code, et les bases distribuées « compatibles Postgres » cachent la clé de partition, retirent les extensions et ajoutent une latence difficile à déboguer.
Comment ça marche
Le principe affiché : rester sur Postgres, sans le contourner, l'imiter ou le remplacer. Quatre pièces :
- Les routeurs. L'application s'y connecte avec le protocole Postgres standard, donc les pilotes, l'ORM et la chaîne de connexion existants restent. Le routeur embarque un parseur complet, un planificateur de requêtes distribué et du buffering : il analyse la requête, choisit les shards qui l'exécutent, et fusionne les résultats en un seul flux. Les routeurs scalent horizontalement et verticalement.
- Les shards et shard groups. Chaque shard est un cluster Postgres complet, un primaire et au moins deux réplicas répartis sur trois zones de disponibilité, sans moteur de stockage modifié : extensions, SQL et performances sont ceux de Postgres. Les shards se regroupent en shard groups, et chaque groupe a son profil (taille d'instance, réplicas, stockage, paramètres, extensions).
- Le pooling. Des sidecars tournent à côté de chaque instance. Comme Neki contrôle les deux bouts de la connexion, il dimensionne les pools sur ce que chaque instance peut réellement servir, au lieu de l'estimer de l'extérieur comme un PgBouncer posé devant.
- Le control plane. Il suit la santé des nœuds, exécute bascules planifiées et failovers, et coordonne les workflows de resharding, de changement de schéma et de montée de version.
Le tout est décrit par une topologie de données en JSON : des shard indexes qui désignent la colonne de routage et son hachage, et des shard groups qui fixent sur combien de shards un ensemble de tables s'étale. Les routeurs la mettent en cache et la consultent à chaque plan.
Ce que ça change
Tout ce qui demande normalement une fenêtre de maintenance devient un workflow
intégré : provisionner les nœuds cibles, les rattraper par réplication,
basculer le trafic avec une métafonction __neki, retirer les anciens nœuds,
depuis la même connexion psql que l'application. Cela couvre les changements
de schéma, les montées de version, les bascules planifiées ou non, les imports
et le resharding. On peut d'ailleurs démarrer Neki non shardé, un primaire et
ses réplicas, pour profiter du pooling, du DDL en ligne et des montées de
version sans coupure, puis resharder plus tard sur le cluster existant.
À retenir
C'est une preview : PlanetScale dit explicitement de ne pas y mettre de charge de production, le produit change encore et certaines modifications seront cassantes. Le prix et la résidence des données ne sont pas dans l'annonce. Ce qui vaut le détour dès maintenant, c'est la documentation sur le choix de la clé de shard : c'est la décision que Neki vous laisse, et qu'il faut prendre avant d'en avoir besoin.
Source : Introducing Neki