Un développeur crée en quelques jours, avec l’IA, Terox, un CLI pour interroger 128 shards PostgreSQL à la fois

Avec une centaine de shards PostgreSQL, une question aussi simple que « sur lequel se trouve cet enregistrement ? » tourne au parcours du combattant : trouver l’hôte, se rappeler le port et la base, ouvrir psql, exécuter la requête, puis passer au suivant. Un développeur backend, auparavant DBA, a fini par en avoir assez. Avec l’aide de l’IA, il a créé en quelques jours Terox, un CLI interactif pour les clusters répartis en shards.

Quel problème résout-il ?

Dans psql et pgAdmin, l’unité de travail est la connexion. Dans un système réparti en shards, c’est tout un ensemble de connexions. Une boucle bash autour de psql convient pour une tâche ponctuelle, mais montre ses limites au quotidien : aucun contrôle du parallélisme, aucune annulation des requêtes, aucune conservation des erreurs propres à chaque shard, ni protection contre un accès accidentel à la production.

Terox introduit des abstractions de niveau supérieur : service → stockage → un, plusieurs ou tous les shards. Les hôtes et les bases sont définis par des modèles : par exemple, pgbouncer-shop-rs{p1:03}.example.net se développe en 128 adresses. Une requête ciblant all s’exécute sur tous les shards ; les résultats sont réunis dans une seule table avec une colonne shard, tandis que les erreurs sont affichées séparément.

Un exemple de fonctionnement

La commande \find items item_id = 424242 parcourt les shards, indique que l’enregistrement se trouve sur shard_37 et bascule automatiquement le contexte sur celui-ci. Plus besoin de copier un nom d’hôte ni de tâtonner.

L’implémentation interne est soignée. Le paramètre fanout_concurrency empêche le client de solliciter les 128 shards simultanément. Le pool de connexions de chaque shard est créé à la demande, chaque shard dispose de sa propre échéance et Ctrl+C annule les requêtes en cours. Les lectures s’effectuent dans une véritable transaction PostgreSQL READ ONLY, sans se fier à une analyse du texte SQL. L’écriture doit être activée explicitement avec \write on et se désactive à chaque changement de contexte.

Des commandes de diagnostic sont également prévues (\activity, \blockers, \longtx, \sizes, \diff, \doctor), ainsi qu’un linter qui repère les DELETE sans WHERE ou les NOT IN portant sur des valeurs susceptibles d’être NULL.

Des migrations pour les cas exceptionnels

L’auteur le souligne : les migrations ordinaires accompagnent le déploiement. Terox sert à traiter les exceptions sur de grandes tables fortement sollicitées. Sans l’option --allowed, la commande \migrate fonctionne en mode simulation. Elle propose un déploiement canari, une exécution par lots et --resume ; une somme de contrôle empêche de poursuivre le déploiement avec un fichier modifié.

Il n’existe pas de transaction globale couvrant les 128 serveurs : certains shards peuvent donc avoir déjà validé les modifications. Le rapport signale explicitement toute application partielle, et les migrations doivent être idempotentes. Pour CREATE INDEX CONCURRENTLY et VACUUM, qui ne peuvent pas être encapsulés dans une transaction avec SET LOCAL, Terox avertit que l’exécution n’est pas protégée et exige une confirmation distincte en production.

Ce que cela dit du vibe coding

Le cycle de travail était le suivant : décrire le problème, définir un modèle de comportement minimal, obtenir une implémentation de l’IA, la vérifier manuellement et par des tests, puis transformer chaque cas limite en nouveau test. C’est ainsi qu’ont été ajoutés la fermeture des pools à la sortie, un historique sans mots de passe et des tests de conditions de concurrence.

La principale conclusion de l’auteur : l’IA implémente une mauvaise idée tout aussi vite et proprement, et ce dans douze fichiers à la fois. Il faut donc commencer par formuler les invariants : aucune connexion ne reste ouverte après la sortie, PostgreSQL garantit la lecture seule, un changement de contexte désactive l’écriture et un échec partiel ne passe pas pour une réussite. L’échange avec l’IA devient alors un travail d’ingénierie.

Limites

L’analyse statique de Terox repose sur des heuristiques. La sécurité reste assurée par les permissions des rôles, les transactions READ ONLY, TLS et les délais d’expiration. L’outil ne remplace ni la supervision, ni les sauvegardes, ni la compréhension des plans d’exécution des requêtes, et ne corrige pas l’architecture de répartition en shards.

La leçon pratique : si vous intervenez régulièrement sur des dizaines de bases, transformez votre boucle en un outil qui mémorise les règles à votre place. Et lorsque vous travaillez avec l’IA, commencez par les invariants, avant le code.