Cette année encore, Postgres a été élu SGBD de l’année par DB-Engines. Même si ce n’est qu’un classement, cela donne une tendance. Cela fait aussi plusieurs années qu’il est reconnu selon les sondages de Stackoverflow : Most popular Databases. C’est un SGBD très apprécié, tant par les développeurs, que par les DBA chevronnés… Mais aussi par les directeurs qui y trouvent une stabilité¹.

Postgres a tout pour séduire :

• Année après année, de nouvelles fonctionnalités sont rajoutées. Je pense notamment à : la parallélisation, le partitionnement, la réplication logique…
• Il a su, depuis toujours, garder sa fiabilité.
• Sa communauté n’a fait que grandir. Les conférences dédiées à Postgres battent des records d’affluence tous les ans.²
• C’est devenu un standard, même pour les autres logiciels : les éditeurs rajoutent même le support du protocole Postgres pour faciliter leur intégration : Aurora, AlloyDB, QuestDB…
• C’est un des rares projets de cette envergure à être communautaire. On a pu voir qu’il ne suffit pas que le projet soit opensource, il faut aussi compter sur la communauté et son écosystème.
• Il est supporté par les gros acteurs : les GAFAM emploient de nombreux committers et contributeurs. Ils sponsorisent également les conférences. Par exemple, le prochain pgDay Paris est sponsorisé par Microsoft.

Cependant, je suis un peu inquiet pour le futur. Non pas pour PostgreSQL. Bruce Momjian a fait plusieurs présentations sur ce sujet :

• Future Postgres Challenges
• Will Postgres Live Forever?
• PostgreSQL: Past, Present, and Future

C’est même le sujet de la Keynote d’ouverture du dernier PGConf Europe : Simon Riggs: The Next 20 Years (PGConf.EU 2023)

Non, je suis plutôt inquiet sur la perte de connaissance du métier de DBA.

A quoi servira Postgres si on ne sait pas l’utiliser correctement ?

Un peu d’histoire

Par le passé, il y avait une spécialisation forte des compétences : développeurs, testeurs, DBA étude, DBA prod, ingénieur système, ingénieur stockage, ingénieur sauvegarde…

Chaque spécialité évoluait un peu dans sa bulle, ce qui compliquait la collaboration avec des cycles de développement longs.

Cette organisation a laissé place à une nouvelle façon de travailler : développeurs fullstack, DEVOPS/SRE, des data “quelque chose” (engineer, analyst, steward…).

Les compétences se sont diluées sur les différents métiers. Je croise de plus en plus rarement des DBA.

A la place, la base de donnée est gérée par les développeurs. Ou, si on a un peu de chance, par des “data engineer” ou “data analyst”.

Après plusieurs années, alors que je baigne dedans, j’ai encore du mal à définir ces métiers.

Le constat : bonne connaissance du python, monte des pipelines, on assemble en quelque sorte des Legos avec pleins d’outils : airflow, dbt… Puis, on envoie ces données dans du Redshift, Biquery, Snowflake…

Cependant, j’ai l’impression que la connaissance du SQL s’appauvrit à cause des couches d’abstraction.

Du moment où on manipule de la donnée, la première des compétences à avoir, devrait être la maitrise du SQL.

Qu’est-ce qu’on oublie ?

J’ai le sentiment, qu’année après année, on oublie le métier de DBA.

Pour rappel, ce dernier va être à la croisée de plusieurs chemins :

• Il a des compétences pures sur la base de données :
  • Modélisation.
  • Maitrise du SQL.
  • Maitrise du SGBD : connait le fonctionnement du moteur (vacuum, checkpoint …). Comprend les mécanismes de verrouillages (MVCC, locks…).
  • Conserve une veille technique : le Postgres que j’ai connu à mes débuts est très loin du Postgres actuel.
• Mais également des compétences plus transverses :
  • Avoir une bonne connaissance système pour investiguer sur les problèmes de performance, dimensionner les ressources.
  • Un vernis en développement pour comprendre les besoins des développeurs et pouvoir les accompagner.
  • De la culture “computer science”.

Oui, mais le cloud!

On pourrait penser que le cloud a rebattu les cartes et qu’on n’a plus besoin de DBA. Dans la liste que j’ai donnée ci-dessus, quelles compétences sont couvertes par le cloud ?

Le cloud résout une partie des besoins : hébergement, maintenance, réseau, monitoring (qu’il faut souvent compléter avec un APM ou un Datadog like). Et il rajoute d’autres problèmes :

• Il faut rajouter un métier de FinOps pour maitriser et optimiser les dépenses.
• C’est parfois une boite noire et il peut être difficile d’investiguer sur des problèmes de performance³.
• Cet excellent article de Markus Winand présente aussi d’autres inconvénients : Sometimes Clouds Bring Rain
  • Changer de cloud provider est difficile. Je dirais même que c’est volontaire de leur part.
  • Les coûts peuvent changer Just because it is cheap today doesn’t mean it will be cheap forever.
  • Il faut prévoir un plan de sortie : éviter les services propriétaires, conserver un faible nombre de services.

Car une fois dans le cloud, qui s’occupe de : la modélisation, l’optimisation des requêtes, l’indexation, la veille technique sur le SGBD⁴, l’investigation sur les performances, comprendre les problèmes de verrouillages, l’accompagnement des développeurs ?

Ceci est confirmé dans mes audits, je vois régulièrement des problèmes très basiques :

• Absence de clé primaire.
• Pas d’index sur des cas très simples.
• Aucun respect des formes normales, même les plus basiques. Le JSON n’a pas arrangé les choses.
• Requêtes spaghetti.
• Des jointures façon SQL-89 alors que ça fait plus de 30 ans que le mot clé JOIN existe.

S’il faut retenir une chose : Le cloud ne permet pas de s’affranchir du DBA. Ce n’est pas parce qu’on peut obtenir les clés d’un avion, qu’on sait le piloter.

Un article intéressant sur le nombre de DBA dont vous avez besoin : How many DBAs should a company hire?.

On oublie le métier de DBA

On pourrait naïvement penser qu’on confie ces tâches à des DBA experts, mais j’ai de plus en plus de doutes. J’ai l’impression “qu’on” est en train de perdre la connaissance d’un métier. J’ai déjà croisé des développeurs expérimentés qui ne savaient même pas que le métier de DBA existait. Des recruteurs qui me demandaient si en tant que DBA, je savais optimiser des requêtes et si je connaissais le SQL. C’est mon métier ! C’est un peu comme demander à un plombier s’il sait changer un robinet !

Ce qui est d’autant plus alarmant, c’est que je crains qu’il y ait aussi des CTO qui ont aussi cette méconnaissance de la donnée.

La conséquence est qu’en cas de problème de performance, on ne fait qu’augmenter les ressources des instances. Avec le cloud, la facture croît linéairement avec la taille de l’instance. Si la croissance de la charge est exponentielle, il faudra scaler la base et la facture qui va avec. On se retrouve avec une facture exponentielle.

Quand on n’arrive plus à s’en sortir, on va accuser l’outil ou le modèle, donc on va changer de SGBD ou aller vers du NoSQL. Spoiler : ça ne résoudra pas vos problèmes.

On oublie le passé

Pendant un temps, j’ai voulu écrire un livre pour parler optimisation de requête, des erreurs courantes que je rencontre, etc.

En regardant ma bibliothèque, elle est pleine de livres de ce genre. Ils ont pour la plupart entre 10 et 30 ans et le contenu est toujours d’actualité. A quoi servirait un énième livre s’il n’est pas connu ?

J’ai un autre exemple en tête : les data warehouse (DWH). Ce terme devient de plus en plus galvaudé. La construction d’un DWH est complexe, il faut passer par une phase de modélisation afin de stocker correctement les données. Cela permet de bonnes performances et facilite l’écriture des requêtes analytiques.

Maintenant, je croise régulièrement des “data warehouse” qui se résument à envoyer toutes les données dans un SGBD spécialisé (redshift, biquery …). Sans travail de modélisation et avec des requêtes très mal écrites, parfois générées, car les utilisateurs ne savent pas faire du SQL.

Ces services coûtent très cher et ne font pas de miracle s’il n’y a pas eu un travail approfondi de modélisation et d’optimisation.

Pourtant, les livres sur les DWH et le SQL ont entre 10 et 30 ans. A cette époque, le cloud n’existait pas, les SSD non plus, les CPU avec plusieurs coeurs non plus. Pourtant, on savait construire des DWH, faire des sites performants…

Il ne faudrait pas que le cloud nous fasse oublier tout cet héritage. Sinon, on risque de payer la dette technique et la perte de connaissance très cher, avec les intérêts en plus.

Il faut avoir en tête que même si le SQL a évolué, les SGBD gagnés en fonctionnalités, les principes fondateurs sont toujours justes.

Le code change, la donnée reste

J’ai eu un super manager, ancien DBA, qui expliquait aux développeurs : tu n’es pas ici pour “produire du code” => yeux écarquillés du développeur. “tu es là pour produire et manipuler de la donnée.”

Lorsqu’il y avait une décision compliquée. Par exemple, prendre plus de temps pour revoir le code applicatif, faire une migration plus compliquée, plutôt qu’une solution “quick win”. Ce même manager expliquait :"

D’ici 5-10 ans, ton code aura été réécrit plusieurs fois, peut-être même dans un autre langage. Nous, la donnée, dans 50 ans, elle sera toujours là. C’est notre devoir de nous assurer qu’elle sera toujours exploitable.

Il faut quelques minutes pour prendre une mauvaise décision sur une base de donnée

Et parfois plusieurs mois / années pour la corriger.

Il m’est arrivé de faire des audits où le modèle était catastrophique. Il avait évolué de solutions à court terme en d’autres solutions à court terme. “On corrigera plus tard, il faut faire passer cette fonctionnalité dans le sprint”.

Un DBA peut corriger le modèle de données à coup de grosses migrations (encore faut-il avoir un DBA, difficile si on ignore que ce métier existe…). Au-delà de ça, le problème va se poser autour : il faut réécrire une grosse partie du code applicatif (qui est souvent dans le même état que la base).

Parfois, la complexité est quadratique ou exponentielle. Il vaut mieux tout jeter pour tout recommencer.

On se retrouve face à plusieurs dilemmes :

• Augmenter la taille des instances.
• Parfois, cette solution n’est pas suffisante. J’explique : “là, vous pouvez faire encore fois dix sur la taille de l’instance, mais vous ne pourrez jouer cette carte qu’une fois”. Notez que cette solution est inutile si le traitement ne peut pas être parallélisé.
• Tout jeter pour tout recommencer. Là aussi, le coût ou la perte peut être démentielle.

Alors qu’il aurait suffi des conseils d’un DBA à quelques moments de la vie du projet pour éviter de partir dans une mauvaise direction.

On ne bâtit pas un château sur du sable. J’ai une anecdote en tête, une personne de mon entourage m’a raconté une histoire d’un bâtiment qui avait été contrôlé au moment de la livraison :

Un prélèvement avait été fait dans les murs et il n’y avait pas assez de ciment, le bâtiment, neuf, pouvait s’écrouler. Il venait d’être totalement terminé, électricité, plomberie, menuiseries… Tout était terminé. Il a dû être rasé complètement. Autant il existe des assurances dans le bâtiment, mais pas pour le développement… Je pense que certaines sociétés ne survivent pas si la dette technique est trop importante.

L’usage du cloud

Le cloud a de nombreux avantages :

• On peut rapidement obtenir des bases de données avec une installation relativement propre.
• Le cloud provider vous obligera à rester sur des versions supportées.
• “Écologiquement”, cela permet de mutualiser des ressources physiques. Mais c’est aussi une faiblesse. L’accès facile à ces ressources peut aussi entrainer un gaspillage. On peut facilement déployer une centaine d’instances. Là, où avec une infrastructure on-premise, il faut concilier avec les ressources physiques à disposition : puissance des serveurs, puissance électrique, espace dans les baies…
• On paye ce qu’on consomme. On peut facilement identifier combien coute un service. Qu’une requête est responsable de 80% de la facture. Ce qui peut inciter à l’optimiser, le gain financier est immédiat. Encore faut-il qu’il y ait des personnes qui s’y intéressent. Je n’ai pas l’impression qu’il y ait beaucoup de FinOps. S’il y en a, est-ce que ces derniers pensent à optimiser la base ?

Mais il y a aussi de vrais inconvénients :

• Perte de souveraineté numérique. A cela s’ajoute des risques juridiques. Comment garantir que vos données ne sont pas stockées ailleurs ? Si vous avez choisi un service managé, comment en sortir si la législation vous impose d’être sur le sol Français ou d’un autre pays ?
• Perte de compétences.
• Dépendance à un cloud provider : encore que sur ce point, on voit émerger de nouvelles offres “cloud agnostique” : Des sociétés créent un cloud par-dessus un autre cloud. Je pense notamment à Aiven, EDB BigAnimal, Crunchy Bridge et j’en oublie certainement…⁵
• Les couts décollent quand l’infrastructure est importante. Certains commencent à quitter le cloud. Je pense notamment à Basecamp :
  • Why we’re leaving the cloud
  • We stand to save $7m over five years from our cloud exit
  • The Big Cloud Exit FAQ

Ce qu’il faudrait changer

• Redonner de la valeur à la donnée : des sociétés rechignent à faire appel à des DBA ou prendre des contrats de supports sur leur base. Quel est le cout d’une indisponibilité de service, d’une corruption de donnée, d’une perte de la base ?
• Réinvestir le champ des compétences en base de donnée : SQL, modélisation⁶. A ce sujet, j’aime beaucoup le titre de Markus Winand : SQL Renaissance Ambassador
• S’attarder un peu plus sur l’usage des ressources : la consommation du numérique est importante, si les serveurs et l’électricité étaient plus chers, on serait contraint d’optimiser.
• Surveiller les dépenses sur les bases. Que ça soit dans le cloud, mais également on-premise. Pour cela, il faut avoir des indicateurs de couts.
• Penser pas à faire appel à des DBA pour anticiper les problèmes et investiguer sur les problèmes de performance : J’ai audité des bases dans un état catastrophique, ça aurait pu être évité si un DBA était intervenu dans la phase de modélisation. Sur les problèmes de performance, il m’est déjà arrivé de diviser des factures de cloud par 10 ou de baisser la charge moyenne de 80% à 5% avec un suivi régulier.
• Il ne faut pas se résigner à payer de grosses factures cloud plutôt que d’investir dans de la compétence de DBA.

Pour conclure

C’est un article moins technique par rapport à ce que vous avez l’habitude de lire sur mon blog. Cependant, c’est un des plus importants que j’ai été amené à écrire. Ca fait plus de dix ans que je fais du Postgres et je réalise que la tendance ne va pas dans la bonne direction. J’espère qu’il y aura une prise de conscience pour un avenir plus durable des bases de données.