Pourquoi je préfère gérer un projet SQL Server, qu'un projet PostgreSQL ?
Je vous propose aujourd'hui de partager avec vous un retour d'expérience concernant les SGBDs. Après des années à jouer avec de multiples solutions, il y a un point qui me fait presque toujours préférer SQL Server à d'autres solutions. Il s'agit de la problématique des montées de version.
Oui, c'est beau d'avoir un super projet, avec une base de données que l'on maitrise sur le bout des doits.
Mais que se passe-t-il après quelques années ? Votre SGBD, et la méthode utilisée pour l'héberger vous permettent-ils de ne pas avoir de coupure de service ? Mon équipe a les compétences pour ce travail ?
Vous ne savez pas... ou du moins vous pensez que "ça va bien se passer, car tout le monde utilise cet outil".
La problématique
Aujourd'hui, il y a trois solutions majeures pour disposer d'une base de données :
- Service Cloud.
- Kubernetes on-premise, ou Cloud (AKS, GKS,...).
- On-premise.
Chacun va avoir son processus pour la mise à jour, et nécessite que votre équipe le maitrise. Pour la suite de cet article je vai comparé SQL Server à PosgreSQL, car ce sont les SGBD. Mes motivations sont simples :
- J'ai l'expérience de ces deux SGBD dans l'intégralité des cas présentés aujourd'hui.
- Ce sont les seuls qui trouvent grâce à mes yeux ;)
Oui, même si je préfère m'appuyer sur SQL Server, j'apprécie beaucoup PosgreSQL.
On-premise
Commençons par l'approche historique, le "on premise" :
- SQL Server : coupure du service, on lance le setup, et on se laisse guider.
- PostgreSQL : coupure du service, on lance un script, et on se laisse guider.
Sur SQL Server, si vous avez un super DBA vous pouvez monter une architecture "zero downtime". Mais ce n'est pas donné, et il faut avoir les compétences.
Sur PostgreSQL, les solutions de sync / cutover sont possibles, là encore, il faut un bon DBA, car il y a des subtilités concernant les LOBS, et les séquences.
Kubernetes
C'est certainement sur Kubernetes qu'il y a le plus de différences. Par défaut, si l'on prend les images de bases et que l'on suit la documentation :
- SQL Server : zéro coupure.
- PostgreSQL : coupure du service, exécution d'un script.
Mais si on utilisé CloudNativePG pour sont déploiement de PostgreSQL, on peut effectuer des montés de versions sans coupure de service. Si vous utilisez déjà PostgreSQL sans CloudNativePG, il est possible de procédé à une migration du style sync /cutover (comme on-premise, il faut avoir un bon DBA sous la main).
Si vous ne connaissez pas CloudNativePG, prenez 5 minutes pour aller sur ce site. Cela vaut vraiment le détour. Ensuite, vous ne déploierez plus jamais PostgreSQL autrement ;)
Cloud
Sur le Cloud, là où le SAAS est roi, tous les SGBD ne sont pas logés à la même enseigne :
- SQL Server : Sur Azure, on utilise toujours la dernière version. Il n'y a donc pas d'upgrade à gérer.
- PostgreSQL : Azure, AWS, et GCP permettent de faire des montés der version. Mais il y a toujours une période d'indisponibilités des bases de données.
La seule solution pour approcher d'un upgrade sans coupure est donc de disposer d'un très bon DBA. Celuic- aura la charge de vous monter un plan de sync / cutover entre deux instances. Il faut donc des compétences, et consommer un peu plus de services cloud le temps de l'upgrade.
Conclusion
Seul SQL Serveur fourni des expériences d'upgrade sans coupure de service, sans rien avoir à configurer (Cloud, et K8S). Le nombre de compétences utiles est alors réduit.
Voilà pourquoi j’apprécie autant avoir à maintenir des projets qui utilisent SQL Server ;)