Contexte et besoin

PlanetScale s’appuie sur plus de huit ans d’expérience avec les plus grands clusters MySQL sharded, traitant des millions de requêtes par seconde pour des workloads tier 0 où chaque seconde d’indisponibilité est critique. Après le lancement de PlanetScale Postgres, les équipes clientes ont rapidement atteint les limites d’une instance unique : saturation du CPU, IOPS et contraintes de sauvegarde. Les solutions existantes imposent soit un sharding applicatif, soit des bases compatibles Postgres qui suppriment les extensions et augmentent la latence. Neki répond à ce besoin en proposant un Postgres sharded natif, sans compromis sur les extensions ni sur le protocole.

Architecture de Neki

Le cœur de Neki repose sur quatre composants : le router, les shards, les sidecars et le control plane. Le router accepte les connexions via le protocole PostgreSQL standard, ce qui permet d’utiliser les drivers, ORMs et chaînes de connexion habituels. Il intègre un analyseur de requêtes PostgreSQL, un planificateur distribué et un tampon de résultats ; chaque requête est découpée, envoyée aux shards concernés, puis les réponses sont agrégées en un flux unique. Les routers peuvent être déployés verticalement ou horizontalement, évitant ainsi tout goulot d’étranglement unique.

Chaque shard est un cluster PostgreSQL complet : un primaire et au moins deux réplications, répartis sur trois zones de disponibilité. Aucun moteur de stockage modifié n’est utilisé, garantissant la pleine compatibilité avec les extensions PostgreSQL et le comportement SQL attendu. Les shards sont groupés en shard groups, chaque groupe pouvant être dimensionné indépendamment (taille d’instance, nombre de réplications, paramètres PostgreSQL, extensions).

{
  "shard_key": "customer_id",
  "shard_groups": [
    {"name": "orders", "shard_count": 8},
    {"name": "analytics", "shard_count": 4}
  ]
}

Le JSON ci‑dessus illustre la topologie de données : la clé de sharding, le hachage et la répartition des tables sur les groupes de shards. Le router met en cache cette topologie et la consulte à chaque planification.

Gestion des opérations en ligne

Les sidecars, déployés à côté de chaque instance PostgreSQL, contrôlent le pool de connexions de façon fine‑grained. Contrairement à PgBouncer, ils connaissent les capacités réelles de chaque instance et ajustent le nombre de connexions autorisées, réduisant ainsi les refus de connexion sous forte charge.

Le control plane surveille la santé de chaque nœud, orchestre les basculements planifiés et non planifiés, et pilote les workflows automatisés : changements de schéma, mises à jour de version, importations massives, et resharding. Tous ces processus s’exécutent sans fenêtre de maintenance, via la même connexion psql que l’application, grâce à la fonction métadonnée __neki qui orchestre le basculement du trafic.

Limitations et phase preview

Actuellement, Neki est disponible en preview plateforme. L’usage en production est déconseillé car le produit subit encore des modifications susceptibles d’introduire des ruptures. Le modèle de facturation, la prise en charge de certains types d’extensions et la robustesse du router à très grande échelle restent à valider. Les équipes intéressées peuvent s’inscrire, créer un cluster Neki et soumettre leurs retours via le ticketing ou le Discord dédié.