La décision de réparer un backend Supabase

Cela semble évident jusqu'au jour où une application défaillante en production fait passer chaque défaut pour un défaut de la plateforme. J'ai vu des équipes planifier une migration de six semaines parce qu'un index manquant ralentissait un tableau de bord. Je les ai aussi vues passer des mois à peaufiner des politiques autour d'un modèle de données incapable d'exprimer les autorisations promises aux clients. La décision doit reposer sur des preuves tirées du système en fonctionnement, pas sur la frustration causée par le dernier incident.

Utilisez cinq tests : complexité des requêtes, prolifération de RLS, dépendance aux fonctions Edge, exigences de conformité et coût prévisionnel. Aucun ne suffit seul. Une requête complexe peut être parfaitement saine. Cinquante politiques peuvent être plus faciles à vérifier que cinq politiques vagues. Une facture d'hébergement basse peut masquer une récupération manuelle coûteuse. La bonne question consiste à déterminer si chaque difficulté peut être réparée sur place et si le système réparé conviendra encore aux deux prochaines années d'utilisation prévue.

Réparez les défauts tant que l'architecture convient

La réparation est préférable lorsque les limites prévues du backend correspondent encore au produit. Si PostgreSQL reste un système de référence adapté, si l'accès direct par le client convient toujours à l'application et si Supabase Auth, Storage ou Realtime répondent aux exigences réelles, changer de plateforme remplace des défauts connus par de nouvelles inconnues.

Classez chaque plainte avant de parler d'une destination. Placez-la dans l'une de ces quatre catégories : défaut d'implémentation, discipline d'exploitation manquante, incompatibilité architecturale ou exigence externe. Une clé étrangère absente, un secret de rôle de service exposé et un prédicat de politique non indexé sont des défauts d'implémentation. Des modifications de schéma effectuées uniquement dans le tableau de bord de production révèlent un manque de discipline. Un flux de travail qui demande de longues tâches gourmandes en CPU peut être incompatible avec les fonctions Edge. Un contrat qui impose une région de déploiement ou un contrôle d'audit indisponible dans l'offre choisie constitue une exigence externe.

Seules les deux dernières catégories rendent une migration probable. Les deux premières demandent généralement une réparation. Ce classement évite un échec bien connu : l'équipe migre les tables, puis recrée chez un autre fournisseur les mêmes autorisations trop permissives, l'absence de migrations et la faiblesse de la supervision.

La réparation l'emporte aussi lorsque l'équipe ne peut pas décrire une architecture cible vérifiée. « Un backend sur mesure » n'est pas une cible. C'est l'obligation de choisir un framework d'API, un système d'identité, un hébergement de base de données, une stratégie de connexion, un stockage d'objets, un exécuteur de tâches en arrière-plan, un système de secrets, une pile de journaux, un processus de sauvegarde et une méthode de déploiement. Chaque choix doit avoir un responsable. Tant que ces décisions ne sont pas prises, l'estimation de la migration contient surtout des zones blanches.

Fixez la limite de la réparation avant le début des travaux. Par exemple : restaurer l'historique des migrations, supprimer l'accès du navigateur aux identifiants privilégiés, faire réussir les tests d'autorisation, ramener les parcours utilisateur les plus lents dans un budget de latence convenu et documenter des exercices de restauration. Si cette réparation délimitée produit un backend que l'équipe sait exploiter, la migration n'a pas de justification économique. Si le périmètre ne cesse de s'étendre parce que chaque correction révèle une hypothèse incompatible, ces preuves plaident pour le déplacement.

La complexité des requêtes exige des plans, pas des avis

Un SQL complexe ne justifie pas à lui seul une migration. PostgreSQL exécute la base de données sous Supabase. Déplacer le même schéma et les mêmes requêtes vers un autre service PostgreSQL géré ne fera donc pas disparaître les mauvaises jointures, les index manquants, les lectures de lignes trop larges ou les échanges trop nombreux avec le client.

Commencez par les données de la charge réelle. La documentation Supabase recommande pg_stat_statements pour repérer les instructions fréquentes et coûteuses. Relevez les appels, le temps total d'exécution, le temps moyen, les lignes et la requête normalisée. Ne triez pas uniquement par durée moyenne. Une requête de 40 millisecondes exécutée un million de fois peut consommer plus de capacité qu'un rapport de deux secondes ouvert deux fois par jour.

Cette requête fournit un premier tri utile :

select
  queryid,
  calls,
  round(total_exec_time::numeric, 1) as total_ms,
  round(mean_exec_time::numeric, 1) as mean_ms,
  rows,
  left(query, 180) as sample
from pg_stat_statements
where calls >= 20
order by total_exec_time desc
limit 25;

La sortie contient une ligne par instruction normalisée, avec l'identifiant de requête, le nombre d'appels, le temps cumulé, le temps moyen, les lignes concernées et un extrait raccourci. Enregistrez ce résultat pendant une période d'activité représentative. Une base de préproduction calme ne prouve presque rien sur le trafic de production.

Pour les instructions qui dominent la latence ou le temps de base de données, exécutez EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) sur des données représentatives et sûres. ANALYZE exécute l'instruction. Utilisez donc une transaction annulable pour les écritures et ne le lancez pas aveuglément en production. Recherchez les parcours séquentiels de grandes relations, les écarts importants entre le nombre de lignes estimé et réel, les boucles répétées, les lectures disque et les tris qui débordent. Ces observations indiquent des index à créer, des prédicats à réécrire, des statistiques à améliorer, des sélections à réduire ou un modèle de données à modifier.

Réparez lorsqu'un petit nombre de plans identifiables explique l'essentiel du problème et que des modifications PostgreSQL ordinaires le résolvent. Envisagez la migration lorsque la charge elle-même contredit la forme du service choisi : analyses soutenues qui gênent le trafic transactionnel, extensions nécessaires indisponibles, comportement des connexions incompatible avec le modèle de concurrence de l'application, ou données qui doivent rester proches d'un autre système avec un temps réseau mesuré dominant les requêtes.

Ne confondez pas le nombre de requêtes API et la complexité SQL. Un frontend généré par IA récupère souvent une liste, puis demande les données associées une fois par ligne. La base peut exécuter des requêtes simples alors que la page souffre des allers-retours. Regrouper l'accès dans une vue, une fonction RPC ou un seul endpoint serveur est une réparation. Déplacer ce modèle sans le changer modifie seulement l'endroit où arrive la facture de latence.

Testez les réparations avec une charge, pas avec une requête choisie à la main. Capturez un ensemble reproductible d'opérations de lecture et d'écriture pour les parcours utilisateur les plus chargés, retirez les données personnelles des jeux d'essai, puis exécutez-le avant et après chaque modification. Relevez la médiane et la durée des requêtes lentes, le CPU de la base, le nombre de connexions, les lignes lues et le taux d'erreur. Un nouvel index qui aide un filtre peut ralentir les écritures ou consommer assez de stockage pour modifier le calcul des coûts. Une vue matérialisée peut accélérer un rapport tout en ajoutant un retard d'actualisation que le produit refuse.

La pression sur les connexions exige le même diagnostic. Les clients de navigateur, les processus serveur, les pools de transactions et les sessions directes se comportent différemment. Comptez les sessions actives et en attente pendant les pointes, puis trouvez le composant qui les possède. Si une application générée ouvre une nouvelle connexion serveur par requête, réparez la réutilisation des connexions avant d'acheter plus de calcul. Ne migrez que si les exigences vérifiées de concurrence et de transaction restent incompatibles après correction du client et du pool.

La prolifération de RLS se mesure par le comportement

La prolifération de RLS devient un signal de migration lorsque personne ne peut prévoir ni tester de façon fiable qui a le droit de lire et modifier chaque ligne. Le nombre de politiques ne dit presque rien à lui seul. Un grand ensemble de politiques étroites peut être plus sûr qu'une politique compacte remplie de contrôles d'appartenance imbriqués et de claims JWT modifiables.

Inventoriez les politiques dans la base au lieu de faire confiance à un schéma :

select
  schemaname,
  tablename,
  policyname,
  roles,
  cmd,
  permissive,
  qual,
  with_check
from pg_policies
order by schemaname, tablename, cmd, policyname;

Lisez la sortie comme une matrice d'autorisation. Pour chaque table exposée et chaque opération, indiquez les rôles actifs, la condition sur les lignes, le contrôle d'insertion ou de mise à jour et le refus attendu. Signalez les sous-requêtes d'appartenance dupliquées, les politiques qui dépendent de métadonnées modifiables par l'utilisateur, les conditions générales à true, les colonnes de locataire incohérentes et les tables exposées par l'API sans politique volontaire.

Le guide RLS de Supabase établit une distinction précise que beaucoup d'applications générées ratent. Les utilisateurs peuvent modifier raw_user_meta_data, qui ne convient donc pas aux claims d'autorisation. raw_app_meta_data ne peut pas être modifié par l'utilisateur et peut contenir des données d'autorisation, même si le contenu du JWT peut rester ancien jusqu'au renouvellement du jeton. Ce n'est pas une nuance de nommage. Placez un rôle dans le mauvais claim et un utilisateur peut s'accorder lui-même un accès.

Les corrections de performances viennent après la justesse des autorisations. Indexez les colonnes utilisées dans les prédicats de politiques. Lorsque la sémantique le permet, placer auth.uid() dans une sous-requête scalaire permet au planificateur de créer un plan initial et d'éviter l'évaluation de la fonction pour chaque ligne. Conservez des filtres explicites dans les requêtes de l'application même si une politique impose déjà la même limite de locataire, car le filtre aide le planificateur à choisir un chemin plus étroit. Aucun de ces changements ne répare un modèle d'autorisation que l'équipe ne sait pas décrire.

Créez des tests de refus avant de modifier les politiques. Exécutez les mêmes tentatives de sélection, insertion, mise à jour et suppression en tant qu'utilisateur anonyme, membre ordinaire, membre d'un autre locataire, administrateur et compte suspendu si cet état existe. Vérifiez les lignes autorisées comme les lignes interdites. Les tests avec le rôle de service ne remplacent pas les tests utilisateur, car un accès privilégié peut contourner RLS.

Réparez RLS lorsque le produit possède un modèle de locataires stable et que les politiques peuvent être réduites à des prédicats réutilisables et nommés, couverts par une matrice de tests complète. Migrez ou ajoutez une couche d'autorisation dédiée lorsque les droits dépendent de relations qui changent vite, que les décisions exigent un contexte extérieur à PostgreSQL, que les clients demandent des explications que le modèle actuel ne peut pas produire, ou que chaque nouvelle fonction impose de modifier des dizaines de politiques sans rapport. Même dans ce cas, la migration ne supprime pas la protection de la base. Elle déplace l'endroit où se prend la décision principale.

Surveillez la propriété pendant les écritures. Une politique de sélection peut cacher correctement les lignes d'un autre locataire, tandis qu'une condition with check incomplète autorise l'insertion d'une ligne avec l'identifiant de locataire d'une autre personne. Les mises à jour ont besoin d'une règle définissant les lignes existantes que l'utilisateur peut viser et d'une autre définissant le contenu permis de la nouvelle ligne. Testez ces chemins séparément. Les applications générées n'exercent souvent que les lectures réussies, si bien qu'une élévation par écriture survit jusqu'à la production.

Des fonctions auxiliaires centrales peuvent réduire les prédicats répétés, mais elles peuvent aussi masquer des privilèges. Examinez le propriétaire, le chemin de recherche du schéma, le mode d'exécution et les droits de chaque fonction security definer citée par une politique. Qualifiez les noms de relations et limitez la surface appelable. Si l'équipe ne sait pas expliquer pourquoi une fonction auxiliaire s'exécute avec des droits élevés, l'étendre au schéma augmente le risque au lieu de simplifier le système.

La dépendance aux fonctions Edge détermine l'ampleur du déplacement

Les fonctions Edge comptent parce qu'elles révèlent tout ce qui, dans le backend, dépasse la base de données. Un projet doté de deux gestionnaires de webhooks implique une migration différente d'un projet où chaque écriture privilégiée, retour de paiement, tâche planifiée, action d'e-mail et intégration externe passe par des fonctions Deno.

Créez un registre avec une ligne par fonction déployée. Notez son appelant, sa méthode d'authentification, ses secrets, ses opérations de base, ses services externes, son comportement en cas de délai dépassé, sa politique de nouvelle tentative, son mécanisme d'idempotence, sa commande de déploiement et ses volumes moyen et maximal d'appels. Les fichiers source ne montrent pas forcément un secret enregistré dans le tableau de bord du fournisseur ni un webhook externe configuré plusieurs mois auparavant.

Supabase décrit les fonctions Edge comme des fonctions TypeScript exécutées dans un environnement compatible avec Deno. Le code bénéficie donc d'une certaine portabilité, mais tout le comportement qui l'entoure demande du travail : routage de la passerelle, gestion des JWT, secrets d'environnement, appels planifiés, transmission des journaux, déploiement et exécution régionale. Considérez « le code est en TypeScript » comme une information utile, pas comme un plan de migration.

Réparez lorsque les fonctions sont de minces adaptateurs. Une bonne réparation extrait les règles métier dans des modules ordinaires, valide les entrées à la frontière, applique des délais explicites aux appels externes, rend les webhooks idempotents et transfère les longues tâches vers une file ou un worker adapté à leur durée. Les limites officielles portent sur la mémoire, le temps CPU, la durée totale, l'inactivité de la requête, la taille du paquet et le nombre de secrets. Consultez les limites actuelles de l'offre active au lieu d'inscrire dans un document d'architecture un chiffre qui vieillira.

La migration devient intéressante lorsque la limite d'exécution fait partie de la charge normale au lieu d'être un défaut occasionnel. Le traitement d'images, la conversion de gros documents, les longues tâches d'IA, les exportations de données lourdes et les flux durables ont souvent besoin de workers à concurrence contrôlée, de files persistantes et d'un état de reprise explicite. Vous pouvez garder Supabase pour PostgreSQL et Auth tout en déplaçant uniquement ces tâches. Une migration partielle élimine souvent la contrainte sans remplacer la base.

Estimez le déplacement par dépendance, pas par nombre de fichiers. Un webhook de paiement de 80 lignes au comportement de répétition non documenté peut comporter plus de risques que vingt endpoints en lecture seule. Pour chaque fonction, exigez un test de contrat qui envoie la même requête aux anciennes et nouvelles implémentations, normalise les champs générés par le fournisseur, puis compare le statut, le corps, les effets en base et les appels sortants. Sans ce dispositif, les équipes découvrent les différences de comportement dans les messages des clients.

La conformité peut l'emporter sur la commodité technique

La conformité ne justifie une migration que lorsqu'une exigence écrite ne peut être satisfaite par le service, l'offre, la configuration et le processus d'exploitation disponibles. Une inquiétude vague au sujet de données réglementées fait perdre du temps. Une clause client signée, une déclaration de contrôle d'un auditeur ou une restriction légale fournit un élément testable.

Transformez l'exigence en matrice de contrôles. Nommez les données concernées, les régions autorisées, les attentes de chiffrement, la durée de conservation, la procédure de suppression, l'objectif de récupération, les règles d'accès du personnel, les preuves d'audit, les conditions de notification d'incident, les sous-traitants et les documents contractuels. Attribuez chaque ligne à la plateforme ou à votre équipe. Un hébergement géré ne transfère jamais toute la responsabilité au fournisseur.

Vérifiez les contrôles requis dans la documentation actuelle des offres Supabase et dans les documents contractuels. Les journaux d'audit, la durée de conservation des logs, la récupération à un instant donné, l'authentification unique, les rôles de projet, les réseaux privés, le choix de régions et la prise en charge des charges réglementées peuvent varier selon l'offre et l'accord. Un contrôle absent de l'offre actuelle peut demander une montée en gamme plutôt qu'une migration. Comparez cette montée en gamme à une destination réaliste qui inclut les mêmes obligations de preuve et d'assistance.

Les sauvegardes exigent une attention particulière. La documentation de Supabase indique que les sauvegardes de base de données ne contiennent pas les objets conservés par l'API Storage, mais seulement leurs métadonnées. Restaurer la base ne restaure donc pas un objet supprimé. Si votre plan de reprise suppose qu'un bouton remonte les deux dans le temps, ce plan est faux. Réparez-le avec une protection séparée des objets et un exercice de restauration, ou choisissez une architecture dont les contrôles de reprise correspondent à l'exigence.

La migration se justifie lorsque le fournisseur ne peut pas signer l'accord requis, lorsque la région ou la frontière réseau demandée n'existe pas, lorsque la conservation des preuves ne respecte pas le contrat, ou lorsque l'organisation doit contrôler l'infrastructure d'une manière interdite par le service hébergé. Notez le contrôle qui échoue et la preuve fournie par la destination avant de bouger. L'auto-hébergement peut apporter du contrôle, mais il rend aussi l'équipe responsable des correctifs, de la supervision, de l'intégrité des sauvegardes, des revues d'accès et des preuves d'incident.

N'utilisez pas la migration pour éviter de comprendre les flux de données. Vous avez besoin du même inventaire pour migrer sans danger : tables, buckets d'objets, enregistrements d'authentification, logs, secrets, réplicas, exportations analytiques et sous-traitants externes. Le travail de conformité révèle souvent des flux non documentés. Cette découverte peut mener à une réparation plus petite ou confirmer que la conception actuelle doit changer.

Le coût prévisionnel comprend les personnes et le risque de transition

Le coût prévisionnel doit comparer le système réparé, l'état stable après migration et la transition elle-même sur une même prévision de demande. Comparer la facture Supabase actuelle à la seule ligne de base de données d'un autre fournisseur produit une fiction.

Modélisez le coût par facteur de charge. Utilisez les utilisateurs actifs mensuels lorsqu'ils influent sur l'authentification, la croissance du calcul et du stockage de la base, le trafic sortant par origine et destination, les messages Realtime et les pics de connexions, le volume et les opérations Storage, les appels de fonctions Edge, le volume et la conservation des logs, les fonctions de sauvegarde ou de récupération, l'assistance et les options imposées. Relevez les prix unitaires actuels des deux fournisseurs au moment de la décision. Conservez chaque prix et quota inclus dans une feuille d'hypothèses datée, car les tarifs changent.

Utilisez trois scénarios de demande plutôt qu'une prévision faussement précise : attendu, élevé et contraction. La formule peut rester simple :

monthly platform cost =
  base plans
  + database compute and storage
  + network egress
  + authentication usage
  + realtime usage
  + function usage
  + logs, backups, and support

monthly operating cost =
  engineering hours
  + incident response
  + security and compliance work
  + vendor management

Estimez les heures d'ingénierie à partir du travail réel : déploiements ratés, revues manuelles de politiques, réglage de la base, débogage des fonctions, tests de restauration et escalades vers l'assistance. N'attribuez pas une valeur nulle au travail absorbé par un fondateur. Il retarde tout de même les travaux sur le produit et les ventes.

Le coût de transition comprend les environnements parallèles, la copie des données, la copie des objets, la capture des changements si elle est nécessaire, les doubles écritures si elles sont retenues, les tests de contrat, les mises à jour des clients, l'observabilité, la revue de sécurité, l'assistance au basculement et la capacité de retour. Ajoutez l'exposition contractuelle ou la perte de revenus liées à l'indisponibilité et aux incohérences sous forme de fourchette, pas de chiffre précis inventé. Une migration qui économise quelques centaines par mois peut demander des années pour être amortie.

Calculez le mois d'équilibre :

break_even_month =
  transition_cost /
  (repaired_monthly_cost - migrated_monthly_cost)

Si le dénominateur est nul ou négatif, le coût ne soutient pas la migration. Si le résultat dépasse la durée de vie utile probable de l'architecture, l'économie est théorique. Refaites le calcul avec le scénario de forte demande, car une destination peut ne devenir moins chère qu'après un seuil, puis avec la contraction, car une infrastructure et des effectifs fixes peuvent pénaliser un usage réduit.

Réparez lorsque le réglage, le redimensionnement, l'archivage ou le déplacement d'une seule charge modifie suffisamment la courbe. Migrez lorsqu'un facteur de coût structurel subsiste après la réparation, par exemple un trafic sortant inévitable, une offre premium requise surtout par un contrôle, ou du travail consacré à compenser une incompatibilité persistante de la plateforme.

Une décision notée révèle les hypothèses fragiles

Une grille de notation n'aide que si chaque note renvoie à une preuve. Elle ne doit pas cacher le jugement derrière l'arithmétique. Utilisez-la pour révéler les hypothèses qui modifient la recommandation et les questions encore sans réponse.

Notez chaque facteur de 0 à 3 pour la réparation et pour la migration. Zéro signifie que l'option ne satisfait pas l'exigence. Trois signifie qu'elle la satisfait avec des preuves. Faites de la conformité et de la sécurité des conditions éliminatoires : si une option ne peut pas respecter un contrôle obligatoire, son total ne la sauve pas.

Utilisez ces facteurs :

1. Adéquation à la charge de requêtes, prouvée par les statistiques d'instructions et les plans d'exécution.
2. Clarté des autorisations, prouvée par l'inventaire des politiques et les tests de refus.
3. Adéquation de l'environnement d'exécution, prouvée par le registre des fonctions Edge et la durée des tâches.
4. Adéquation à la conformité, prouvée par la matrice de contrôles et les documents contractuels.
5. Coût sur la période prévue, transition et travail compris.

Ajoutez l'exploitabilité, les compétences de l'équipe, la qualité du retour et l'interruption des livraisons si ces facteurs peuvent changer le choix. Inscrivez un niveau de confiance à côté de chaque note. Une note de coût fondée sur un mois de données incomplètes ne doit pas paraître égale à une note de conformité confirmée dans un accord signé.

Fixez les règles de décision avant de noter. Une règle pratique consiste à réparer lorsque toutes les conditions obligatoires sont satisfaites, que le périmètre de réparation est délimité et que l'amortissement de la migration tombe après la période étudiée. Migrez lorsqu'une condition obligatoire échoue sans plan crédible ou lorsque plusieurs contraintes mesurées persistent après une réparation limitée dans le temps. Choisissez une solution hybride lorsqu'un service, souvent le calcul de longue durée ou l'analyse, cause l'essentiel de l'incompatibilité.

La grille arrête aussi les arguments liés aux coûts déjà engagés. Les efforts passés ne rendent pas le backend actuel adapté, et l'agacement ne rend pas une nouvelle solution adaptée. Les preuves peuvent évoluer pendant l'évaluation. Si l'ajout de deux index et la correction d'un prédicat de locataire suppriment le prétendu problème de montée en charge, modifiez la note sans défendre l'idée de migration initiale.

FixMyMess utilise un diagnostic du code et une vérification experte pour distinguer les défauts réparables des applications générées par IA et l'architecture qui doit être reconstruite. Son audit de code gratuit peut fournir ce premier inventaire délimité. La décision reste entre les mains des propriétaires de l'application, surtout lorsqu'elle touche aux contrats, à la tolérance au risque et à la charge future.

Ne basculez qu'avec un retour testé

Une décision de migration reste incomplète tant que l'équipe ne sait pas décrire le déplacement des données, la validation, le basculement et le retour. « Exporter et importer PostgreSQL » ne couvre qu'une partie d'un backend Supabase.

Inventoriez les schémas de base de données, extensions, rôles, politiques RLS, fonctions, déclencheurs, tâches planifiées, utilisateurs Auth et correspondances d'identité, objets et métadonnées Storage, abonnements Realtime, fonctions Edge, secrets, enregistrements de webhooks, DNS et chaque configuration client. Décidez ce qui bouge, ce qui reste et ce qui disparaît. Conservez des identifiants utilisateur stables si possible, ou établissez une correspondance explicite, car les lignes d'autorisation et de propriété en dépendent souvent.

Choisissez une migration avec interruption pour un petit produit lorsqu'une fenêtre de maintenance est acceptable. Elle est plus facile à raisonner que les doubles écritures. Pour un déplacement avec peu d'interruption, effectuez une copie initiale, répliquez les changements de base ultérieurs, copiez les objets avec leurs sommes de contrôle, gelez les modifications de schéma, vérifiez le retard et planifiez le transfert des dernières écritures. La double écriture depuis l'application paraît sûre, mais crée des règles de conflit et des combinaisons de pannes que beaucoup de petites équipes ne savent pas tester.

Définissez les contrôles d'acceptation avant de copier les données. Comparez le nombre de lignes par locataire et par table, les sommes ou empreintes de certains champs stables, le nombre d'orphelins, le nombre et les sommes de contrôle des objets, les résultats des tests de politiques, les tests de contrat d'API et un échantillon des parcours utilisateur essentiels. Les totaux peuvent correspondre alors que la propriété est fausse. Validez donc les relations et les accès avec de vrais rôles utilisateur.

Gardez la source en lecture seule ou récupérable d'une autre manière pendant une durée convenue après le basculement. Définissez un déclencheur mesurable de retour : taux d'erreur, enregistrements manquants, échec de l'authentification, différence sur un retour de paiement ou retard de réplication inacceptable. Précisez qui peut déclencher le retour et comment les écritures effectuées après le basculement reviendront dans l'ancien système. Un plan qui perd les nouvelles écritures est un compromis d'urgence, pas un retour complet.

Pour une réparation, appliquez la même discipline à plus petite échelle. Prenez une sauvegarde vérifiée, appliquez les migrations depuis des fichiers versionnés, exécutez les tests de politiques et de contrats, surveillez les erreurs de la base et de l'application, puis préparez une modification réversible lorsque PostgreSQL le permet. Le guide de migration Supabase avertit que les changements effectués à distance dans le tableau de bord contournent l'historique local. Récupérez l'état distant, réconciliez l'historique et arrêtez les changements de production non suivis.

L'authentification demande sa propre répétition. Les empreintes de mots de passe, les liens vers les identités sociales, l'inscription multifacteur, les jetons de renouvellement, les modèles d'e-mail, les règles de redirection et la durée des sessions ne sont pas transférés automatiquement avec les tables. Décidez si les utilisateurs gardent leurs sessions, se reconnectent ou réinitialisent leurs identifiants. Testez l'invitation, la récupération du mot de passe, la liaison et la suppression du compte sur la destination. Une migration qui conserve les profils mais bloque leurs propriétaires a échoué.

Storage exige également deux validations. Comparez d'abord l'inventaire des objets, la taille en octets, le type de contenu et la somme de contrôle. Testez ensuite l'accès comme le fait l'application, y compris l'accès signé, les objets publics, le remplacement et la suppression. Des lignes de la base peuvent pointer vers des objets jamais copiés, tandis que des objets copiés peuvent devenir publics à cause d'une règle de bucket modifiée. Conservez les journaux de transfert assez longtemps pour enquêter sur le signalement d'un client après le basculement.

Effectuez une répétition générale avec une copie récente et assainie, puis notez la durée de chaque phase. La répétition doit produire les commandes, responsables, points de contrôle et conditions d'abandon utilisés le jour réel. Si la synchronisation finale dépasse la fenêtre de maintenance ou si la validation ne peut finir avant la reprise des écritures, changez le plan avant la production au lieu d'espérer que les opérateurs travailleront plus vite sous pression.

Le choix est prêt lorsqu'une option satisfait les contrôles obligatoires, résiste à des tests représentatifs et montre une charge totale inférieure selon des prévisions crédibles. Si aucune n'y parvient, continuez l'enquête. Les données de production ne récompensent pas une confiance qui devance les preuves.