Migrer SQL Server 2016 vers PostgreSQL sur VPS

La politique de cycle de vie Microsoft prévoit dix ans de support pour chaque version de SQL Server : cinq ans de support standard, puis cinq ans de support étendu. Pour SQL Server 2016, la date de fin de support étendu est le 14 juillet 2026. Passée cette date, Microsoft ne publie plus de mises à jour de sécurité, de correctifs critiques, ni de mises à jour techniques pour cette version. Une instance SQL Server 2016 exposée sur un réseau après cette date accumule des vulnérabilités non corrigées. Les obligations réglementaires — PCI-DSS, RGPD, ISO 27001 — exigent en général que les composants d'infrastructure reçoivent les correctifs de sécurité disponibles. Rester sur SQL Server 2016 après juillet 2026 constitue donc un écart documentable lors d'un audit.

Avant d'écrire la moindre commande de migration, un audit du schéma existant est indispensable. Les éléments qui migrent sans friction sont les tables simples avec des types standard, les contraintes PRIMARY KEY, FOREIGN KEY, UNIQUE et NOT NULL, les index B-tree classiques, les vues sans syntaxe T-SQL propriétaire, et les séquences. Les éléments qui demandent un travail explicite sont les procédures stockées et les fonctions T-SQL (syntaxe incompatible, à réécrire en PL/pgSQL ou à supprimer), les triggers qui utilisent les tables virtuelles INSERTED et DELETED (équivalent PostgreSQL : NEW et OLD), les colonnes ROWVERSION / TIMESTAMP utilisées pour la détection de concurrence optimiste, les colonnes calculées (COMPUTED COLUMNS), les hint de verrouillage (WITH (NOLOCK), WITH (UPDLOCK)), et les tables temporaires globales (##temp). Un inventaire SQL Server peut être obtenu par requête sur INFORMATION_SCHEMA et sur les vues système sys.objects, sys.procedures, sys.triggers.

Plusieurs constructions T-SQL courantes n'ont pas d'équivalent direct en SQL standard et nécessitent une réécriture.

TOP N sans ORDER BY : SQL Server accepte SELECT TOP 10 * FROM t sans clause d'ordre. PostgreSQL requiert LIMIT 10 ; si un ordre défini est important, ajouter ORDER BY explicitement.

ISNULL(expr, valeur) : la fonction T-SQL ISNULL a pour équivalent standard COALESCE(expr, valeur). Le comportement est identique pour les cas courants.

GETDATE() et GETUTCDATE() : ces fonctions deviennent respectivement NOW() (timestamp avec timezone de la session) et NOW() AT TIME ZONE 'UTC' ou CURRENT_TIMESTAMP.

DATEDIFF et DATEADD : PostgreSQL utilise l'arithmétique d'intervalles : date + INTERVAL '7 days', date2 - date1 retourne un INTERVAL.

HINT WITH (NOLOCK) : ce hint demande une lecture sans verrou partagé (lectures non répétables). PostgreSQL ne supporte pas ce hint ; le niveau d'isolation READ COMMITTED (défaut) couvre la plupart des cas d'usage. Pour les rapports analytiques qui tolèrent des données légèrement obsolètes, une réplique en lecture est la solution structurelle.

PRINT dans les procédures : utiliser RAISE NOTICE 'message' en PL/pgSQL.

GO comme séparateur de batch : ce séparateur n'existe pas en PostgreSQL. Les scripts SQL doivent être restructurés en transactions ou en blocs DO $$...$$ séparés.

Une installation PostgreSQL par défaut n'est pas calibrée pour la production. Les paramètres suivants dans postgresql.conf sont un point de départ pour un VPS avec 4 Go de RAM.

shared_buffers : fixer à 25 % de la RAM disponible, soit 1GB pour 4 Go. Ce paramètre détermine la mémoire allouée au cache interne de PostgreSQL.

effective_cache_size : fixer à 75 % de la RAM totale, soit 3GB. Ce paramètre informe le planificateur de requêtes de la mémoire disponible pour le cache du système d'exploitation.

work_mem : 16MB à 64MB selon la complexité des requêtes de tri. Ce paramètre s'applique par opération de tri et par connexion ; une valeur trop élevée sur une instance avec de nombreuses connexions simultanées épuise la mémoire.

maintenance_work_mem : 256MB pour les opérations de maintenance (VACUUM, CREATE INDEX).

max_connections : 100 est suffisant pour la plupart des applications qui utilisent un pool de connexions. Si l'application ouvre une connexion par requête sans pool, utiliser PgBouncer en amont.

Pour pg_hba.conf, restreindre les connexions distantes à l'adresse IP du serveur applicatif et exiger TLS : hostssl all appuser 10.0.0.5/32 scram-sha-256.

Activer TLS en générant un certificat (Let's Encrypt ou certificat interne) et en configurant ssl = on, ssl_cert_file et ssl_key_file dans postgresql.conf.

Les procédures stockées T-SQL sont le principal point de friction d'une migration SQL Server vers PostgreSQL. T-SQL est un dialecte propriétaire avec des structures de contrôle, une gestion des curseurs, et une gestion des erreurs (blocs TRY...CATCH) qui n'ont pas d'équivalent direct en PL/pgSQL.

Les curseurs FAST_FORWARD de SQL Server deviennent des curseurs FOR en PL/pgSQL, mais les performances sont similaires et l'usage des curseurs doit dans tous les cas être questionné : une requête ensembliste remplace presque toujours un curseur de manière plus efficace.

Le bloc TRY...CATCH devient BEGIN...EXCEPTION WHEN OTHERS THEN en PL/pgSQL.

Les tables temporaires locales (#temp) correspondent aux tables temporaires de session PostgreSQL créées avec CREATE TEMPORARY TABLE. Les tables temporaires globales (##temp) n'ont pas d'équivalent direct — elles doivent être remplacées par des tables permanentes avec une gestion explicite du cycle de vie, ou par des tables dans un schéma dédié avec des politiques de nettoyage.

Les triggers qui référencent INSERTED et DELETED (tables virtuelles SQL Server) doivent être réécrits pour utiliser NEW et OLD en PostgreSQL. La structure de déclenchement est aussi différente : PostgreSQL distingue les triggers BEFORE et AFTER, et les triggers FOR EACH ROW des triggers FOR EACH STATEMENT.

Une approche pragmatique consiste à déplacer la logique des procédures stockées dans la couche applicative lors de la migration, ce qui simplifie les tests et réduit le couplage entre l'application et la base de données.

Plusieurs catégories d'erreurs reviennent systématiquement lors des premières migrations.

ERROR: column is of type uuid but expression is of type character varying : une colonne UNIQUEIDENTIFIER migrée en UUID reçoit une chaîne formatée comme un UUID mais sans cast explicite. Soit adapter la requête applicative pour envoyer un vrai type UUID, soit ajouter un cast implicite dans PostgreSQL (CREATE CAST), soit migrer la colonne en TEXT si la sémantique UUID n'est pas exploitée.

ERROR: operator does not exist: boolean = integer : une colonne BIT migrée en BOOLEAN est comparée à 0 ou 1. Remplacer col = 1 par col = true ou simplement col dans les clauses WHERE.

ERROR: function isnull(character varying, text) does not exist : remplacer toutes les occurrences de ISNULL par COALESCE.

ERROR: syntax error at or near "TOP" : la syntaxe SELECT TOP N n'existe pas en PostgreSQL. Remplacer par SELECT ... LIMIT N.

Dépassements silencieux sur les colonnes MONEY → NUMERIC : vérifier que les valeurs extrêmes de la table source tiennent dans la précision cible NUMERIC(19,4). SQL Server MONEY a une plage de ±922 337 203 685 477,5807 ; NUMERIC(19,4) couvre ±999 999 999 999 999,9999, ce qui est suffisant dans la quasi-totalité des cas.

Pertes de données sur les colonnes DATETIME sans timezone : SQL Server DATETIME et DATETIME2 ne stockent pas le fuseau horaire. Si la base de données était alimentée par des applications dans plusieurs fuseaux, les timestamps migrés en TIMESTAMPTZ sans conversion préalable seront interprétés comme UTC. Définir une convention (UTC ou heure locale) et appliquer un AT TIME ZONE lors de la migration si nécessaire.

Après la bascule, une checklist de vérification structurée réduit le risque de remettre les utilisateurs sur une base incomplète.

Vérifier le compte de lignes pour toutes les tables critiques : une requête sur information_schema.tables avec un COUNT(*) par table, comparée aux chiffres relevés sur SQL Server avant la migration.

Vérifier l'intégrité référentielle : SELECT * FROM pg_constraint WHERE contype = 'f' liste toutes les contraintes de clé étrangère ; tenter une insertion qui violerait une contrainte pour confirmer qu'elle est active.

Vérifier les index : SELECT indexname, indexdef FROM pg_indexes WHERE schemaname = 'public' liste tous les index créés. Comparer avec la liste des index SQL Server.

Tester les fonctions critiques de l'application : parcours d'achat, authentification, rapports, exports — au minimum les parcours qui touchent aux tables les plus volumineuses et aux requêtes les plus complexes.

Surveiller les logs PostgreSQL pendant les premières 24 heures : tail -f /var/log/postgresql/postgresql-*.log. Les erreurs de type character varying vs uuid, les timeouts de connexion, ou les plans de requête sous-optimaux se manifestent généralement dans les premières heures de trafic réel.

Conserver SQL Server en lecture seule pendant 48 heures avec un accès restreint à l'équipe technique. Le rollback consiste à pointer le DSN applicatif vers SQL Server et à rejouer les données écrites dans PostgreSQL pendant la fenêtre de bascule.