PlanetScale a rendu Neki disponible en platform preview. Neki est une plateforme de sharding pour Postgres : chaque shard est une vraie instance Postgres, et Neki ajoute par-dessus un routeur, des sidecars et un plan de contrôle. Les objectifs annoncés sont des centaines de millions de requêtes par seconde et des pétaoctets de données par base, avec resharding sans interruption. Nick Van Wiggeren a annoncé le lancement dans un article de blog.

Les applications se connectent au routeur Neki, qui dirige les requêtes vers les shards Postgres. Quand un shard devient trop chargé, Neki peut le scinder en ligne : il crée de nouveaux shards cibles, les synchronise par réplication et déplace le trafic via des changements de topologie. Le resharding s'effectue pendant que la base reste en ligne, sans réécriture applicative ni fenêtre de maintenance.

La liste des fonctionnalités est longue. La haute disponibilité est gérée par la plateforme, qui surveille l'état, promeut les réplicas et met à jour le routage pendant que les applications conservent un seul point d'accès Postgres. Les changements de schéma s'exécutent comme des workflows coordonnés sur tous les shards, avec la méthode adaptée par shard et un cutover suivi. Le pooling de connexions est intégré à la couche de sharding, avec connaissance de la topologie, de la santé des shards et de l'état des sessions. Les shard groups permettent d'assigner des tables ou des charges de travail à des profils matériels différents. Chaque shard fonctionne comme un cluster Postgres hautement disponible réparti sur plusieurs zones de disponibilité.

Le placement des données est explicite grâce à un concept appelé data topology, qui associe les données aux shards, shard groups et index de shards. Les transactions inter-shards avec commit atomique sont annoncées comme prochainement disponibles. Des workflows explicites couvrent les imports, le resharding, les changements de schéma, les cutovers et le nettoyage. Les mises à niveau en ligne vers de nouvelles versions de Postgres suivent le même modèle de migration : créer des shard groups cibles, répliquer, basculer, retirer les anciens. Les imports sans interruption copient, répliquent, vérifient puis basculent pendant que la source continue de servir le trafic. Pour le CDC, chaque shard conserve son propre WAL et son propre chemin de réplication logique, compatibles avec les schémas Postgres habituels.