safe-not-safe analyse la sécurité des migrations PostgreSQL

Principe de fonctionnement

Le service safe-not-safe s’exécute entièrement dans le navigateur. Il télécharge libpg_query version 17, le compile en WebAssembly et le lance dans un web worker. Cette architecture garantit que le texte de la migration ne quitte jamais le client : aucune API, aucun journal serveur, aucune persistance disque. L’outil charge le fichier migration.sql, le transmet au parseur WASM, puis génère un arbre syntaxique (parse tree) exploitable par le moteur de règles.

Analyse des patterns à risque

Le moteur de règles compare chaque nœud du parse tree à une liste de constructions SQL réputées dangereuses. Parmi les exemples fournis, ALTER TABLE users ADD COLUMN status text DEFAULT 'active' déclenche une alerte parce que l’ajout d’une colonne avec une valeur par défaut impose un verrou exclusif sur la table pendant la mise à jour de chaque ligne. De même, CREATE INDEX CONCURRENTLY users_created_at_idx ON users (created_at) est détecté comme potentiellement problématique : bien que l’option CONCURRENTLY évite le verrou exclusif, elle reste sensible aux interruptions et aux conflits de ressources lorsqu’elle s’applique à des tables de plusieurs millions de lignes.

Le script ALTER TABLE orders ADD CONSTRAINT orders_user_id_fk FOREIGN KEY (user_id) REFERENCES users(id) NOT VALID suivi de ALTER TABLE orders VALIDATE CONSTRAINT orders_user_id_fk illustre un autre cas d’usage. La première instruction crée une contrainte sans validation immédiate, ce qui évite un verrou long, mais la seconde étape déclenche une vérification complète des données existantes. Le moteur signale ce séquencement afin que l’opérateur prenne conscience du coût de la validation post‑déploiement.

Limites de l’évaluation statique

Le contrôle repose exclusivement sur l’analyse syntaxique. Il ne tient pas compte du volume réel des tables, du taux de remplissage, ni des paramètres de configuration du serveur (par exemple max_locks_per_transaction). Ainsi, une migration jugée « safe » par l’outil peut devenir bloquante en production si la table dépasse les seuils de 5 M de lignes, critère mentionné dans l’interface (« Rows in target table : Over 5M »). De plus, l’outil ne simule pas les effets de déclencheurs, de fonctions PL/pgSQL ou de dépendances externes, ce qui limite la portée de la garantie de sécurité.

ALTER TABLE users ADD COLUMN status text DEFAULT 'active';
CREATE INDEX CONCURRENTLY users_created_at_idx ON users (created_at);
ALTER TABLE orders ADD CONSTRAINT orders_user_id_fk FOREIGN KEY (user_id) REFERENCES users(id) NOT VALID;
ALTER TABLE orders VALIDATE CONSTRAINT orders_user_id_fk;