Ces questions d'entretien pour un DBA PostgreSQL partent des situations de production que le poste rencontre. Au quotidien, le DBA surveille l'autovacuum, analyse les requêtes lentes avec EXPLAIN et pg_stat_statements, met en place les sauvegardes avec pgBackRest ou Barman et la haute disponibilité avec Patroni. En France, les ESN et les infogérants le recrutent pour gérer de nombreuses instances, souvent avec astreinte. Chez un client final, il conseille aussi les développeurs. Les migrations depuis Oracle avec ora2pg sont fréquentes.
La difficulté vient souvent des profils multi-moteurs. Un DBA Oracle expérimenté peut garder ses habitudes sans connaître le MVCC de PostgreSQL ni le risque de wraparound. Sur Amazon RDS ou Cloud SQL, un candidat peut n'avoir jamais restauré une base lui-même. Les certifications d'éditeurs comme celles d'EDB attestent la connaissance de l'architecture. L'entretien doit faire raconter une bascule Patroni ou une restauration PITR déjà vécue.
Quand le poste comporte une astreinte, commencez par les questions de restauration et de bascule. Le PDF complète avec 30 questions sur six axes, un cas de 20 minutes sur une plateforme e-commerce qui ralentit avant une montée de version et une grille de 1 à 4.
Les outils qu'un DBA PostgreSQL doit maîtriser
PostgreSQL et MVCC
PostgreSQL est la base open source la plus demandée dans les migrations depuis Oracle. Son fonctionnement repose sur le MVCC, où chaque modification crée une nouvelle version de ligne. C'est ce qui permet de lire sans bloquer les écritures, et c'est aussi l'origine de la plupart des problèmes d'exploitation propres à PostgreSQL.
VACUUM et autovacuum
VACUUM nettoie les anciennes versions de lignes. Quand l'autovacuum prend du retard, les tables gonflent (on parle de bloat) et, dans le pire des cas, la base finit par refuser les écritures pour protéger ses identifiants de transaction. Un DBA qui ne sait pas parler de VACUUM n'a pas exploité PostgreSQL en production.
EXPLAIN et pg_stat_statements
pg_stat_statements repère les requêtes qui coûtent le plus, EXPLAIN ANALYZE montre comment PostgreSQL en exécute une. Lire un plan et comparer les estimations à la réalité est le cœur du travail d'optimisation.
Réplication streaming et logique
La réplication streaming maintient des copies complètes de l'instance, prêtes à prendre le relais ou à servir des lectures. La réplication logique copie des tables choisies, y compris vers une version plus récente, ce qui sert aux montées de version et aux alimentations partielles.
Patroni
C'est l'outil de haute disponibilité le plus cité dans les offres. Il surveille les nœuds et promeut automatiquement un réplica si le primaire tombe, en s'appuyant sur un registre partagé (etcd, Consul ou Kubernetes). Demandez au candidat comment Patroni évite de se retrouver avec deux primaires.
PgBouncer
Un gestionnaire de connexions placé devant PostgreSQL. Chaque connexion PostgreSQL coûte un processus et de la mémoire. PgBouncer permet à des milliers de clients de partager quelques dizaines de connexions réelles, avec des contraintes que le DBA doit connaître.
pgBackRest et Barman
Ce sont les deux outils de référence pour la sauvegarde physique. Avec l'archivage des journaux de transactions (WAL), ils permettent de restaurer la base à la seconde près, ce qu'on appelle le PITR. Demandez simplement quand la dernière restauration a été testée.
ora2pg
L'outil open source de migration d'Oracle vers PostgreSQL. Il évalue la difficulté, convertit le schéma, le code PL/SQL et les données, mais une partie du travail reste manuelle. Une personne qui a mené une migration sait citer les pièges de conversion qu'elle a rencontrés.
Extensions
PostgreSQL s'enrichit par extensions, comme PostGIS pour la géographie, pgvector pour la recherche vectorielle, pgaudit pour la traçabilité ou pg_partman pour le partitionnement. Le DBA décide lesquelles installer et vérifie qu'elles suivront les montées de version.
Le poste change selon l'employeur. En ESN ou chez un infogérant, le DBA PostgreSQL gère des dizaines d'instances pour plusieurs clients, souvent avec astreinte, sur des architectures hétérogènes. Chez un client final, il vit avec ses bases dans la durée et conseille les développeurs sur le modèle de données et les requêtes. Sur une migration depuis Oracle, il doit aussi lire du PL/SQL. Les offres associent de plus en plus PostgreSQL à Ansible et à Kubernetes, avec des opérateurs comme CloudNativePG. Sur les services managés (Amazon RDS, Azure Database for PostgreSQL, Cloud SQL), l'hébergeur prend en charge la haute disponibilité et les sauvegardes, et le travail se concentre sur la performance et la configuration. Les certifications d'éditeurs, comme celles d'EDB, attestent la connaissance de l'architecture. Elles ne prouvent pas qu'un candidat a déjà mené une bascule ou une restauration en production.
Sur quoi juger un DBA PostgreSQL
- MVCC, VACUUM et maintenance
- Optimisation des requêtes et index
- Sauvegardes et PITR
- Réplication et haute disponibilité Patroni
- Migration Oracle et montées de version
- Connexions, sécurité et supervision
Cinq sujets PostgreSQL à creuser en entretien
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une table de commandes grossit de 30 % par mois alors que son nombre de lignes reste stable. Que se passe-t-il et que faites-vous ?
Une bonne réponseC'est du bloat. Chaque UPDATE ou DELETE laisse une ancienne version de ligne, et l'autovacuum ne suit pas. Le candidat regarde n_dead_tup et last_autovacuum dans pg_stat_user_tables, puis cherche ce qui empêche le nettoyage (transaction longue ou « idle in transaction », slot de réplication, transaction préparée, hot_standby_feedback). Il règle ensuite l'autovacuum table par table. Pour récupérer l'espace déjà perdu, il propose pg_repack, ou un VACUUM FULL dans une fenêtre de maintenance puisqu'il verrouille la table.
Signal d'alerte« Un VACUUM FULL chaque nuit », ou couper l'autovacuum parce qu'il consomme des ressources.
Question 2 · senior
Les logs affichent « database must be vacuumed within … transactions ». Que faites-vous, et dans quel ordre ?
Une bonne réponseC'est l'alerte de bouclage des identifiants de transaction (wraparound). Le candidat mesure age(datfrozenxid) par base et age(relfrozenxid) par table, trouve ce qui bloque le gel (transactions longues, transactions préparées, slots de réplication abandonnés) et le supprime. Il lance ensuite un VACUUM (FREEZE) sur les tables les plus anciennes en suivant la progression. Il sait que, sans action, PostgreSQL refuse les nouvelles écritures à trois millions de transactions de la limite, et qu'il n'est pas nécessaire d'arrêter le serveur.
Signal d'alerteRedémarrer l'instance, ou lancer un VACUUM FULL sur toute la base.
Question 3 · confirmé
Une requête passe de 50 ms à 40 secondes juste après un gros chargement de données. Comment trouvez-vous la cause ?
Une bonne réponseIl confirme avec pg_stat_statements, puis lance EXPLAIN (ANALYZE, BUFFERS) et compare lignes estimées et lignes réelles à chaque nœud. Un gros écart juste après un chargement indique des statistiques périmées, et un ANALYZE sur la table corrige souvent le plan (par exemple une boucle imbriquée choisie sur une estimation à 1 ligne). Si des colonnes sont corrélées, il ajoute des statistiques étendues avec CREATE STATISTICS.
Signal d'alerteAjouter un index au hasard, augmenter la RAM, ou forcer un plan sans avoir lu EXPLAIN.
Question 4 · confirmé
Un développeur a supprimé une table en production à 14h12. Comment la récupérez-vous sans perdre le reste de la journée ?
Une bonne réponseUne restauration à un instant donné (PITR) sur une instance séparée, à partir d'une sauvegarde physique et des WAL archivés (pgBackRest ou Barman), avec une cible recovery_target_time juste avant 14h12 ou une cible plus précise (xid, LSN). Il extrait ensuite la table avec pg_dump et la réimporte en production. Un bon candidat mentionne aussi le réplica différé (recovery_min_apply_delay) comme filet de sécurité.
Signal d'alerteRestaurer la sauvegarde de la nuit directement sur la production, ou découvrir à ce moment-là qu'il n'y a pas d'archivage des WAL.
Question 5 · senior
Dans un cluster Patroni à trois nœuds, le primaire perd le réseau. Que se passe-t-il, et qu'est-ce qui empêche d'avoir deux primaires ?
Une bonne réponseLe primaire détient une clé de leader à durée de vie limitée dans le DCS (etcd, Consul, ZooKeeper ou Kubernetes). S'il ne peut plus la renouveler, il se rétrograde lui-même. Un réplica éligible, dont le retard reste sous maximum_lag_on_failover, prend la clé et devient primaire. Le DCS doit avoir un quorum (trois nœuds etcd, pas deux) et un watchdog peut redémarrer un nœud qui n'a pas réussi à se rétrograder. En asynchrone, les dernières transactions peuvent être perdues, ce que synchronous_mode évite. L'ancien primaire revient comme réplica, avec pg_rewind si besoin.
Signal d'alerte« Patroni gère tout », sans pouvoir expliquer le rôle du DCS, ou un etcd sur deux nœuds.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
PostgreSQL, Oracle, RDS : les questions qui reviennent
Par où commencer pour juger un DBA PostgreSQL ?
Vérifiez d'abord la compréhension du MVCC et de l'autovacuum, à l'origine de la plupart des incidents propres à PostgreSQL. Viennent ensuite la lecture des plans d'exécution, les sauvegardes physiques avec restauration PITR, la réplication et la haute disponibilité avec Patroni, la gestion des connexions avec PgBouncer et la supervision. Selon le poste, ajoutez la migration depuis Oracle, l'automatisation avec Ansible ou l'exploitation sur Kubernetes et sur les services managés.
Un DBA Oracle peut-il devenir DBA PostgreSQL ?
C'est possible s'il a pratiqué en production ce qui est propre à PostgreSQL. Les deux métiers partagent les sauvegardes, la performance et la haute disponibilité, avec des mécanismes différents. PostgreSQL garde les anciennes versions de lignes dans la table et dépend de VACUUM, avec un risque de wraparound propre à ce moteur. La haute disponibilité passe par des outils open source comme Patroni plutôt que par une offre éditeur.
Faut-il un test technique pour recruter un DBA PostgreSQL ?
Il aide, à condition qu'il reproduise une vraie situation d'exploitation. Faire lire un plan EXPLAIN ANALYZE, diagnostiquer une table qui gonfle ou décrire pas à pas une restauration PITR montre vite le niveau réel. Un questionnaire à choix multiples sur la syntaxe en dit peu. Pour un profil senior, une mise en situation orale sur un incident de production complète bien l'entretien technique.
Un DBA PostgreSQL est-il utile sur un service managé comme Amazon RDS ?
Oui, avec un périmètre différent. L'hébergeur prend en charge la haute disponibilité, les sauvegardes et une partie des montées de version. Restent l'optimisation des requêtes et des index, le réglage des paramètres, le suivi de l'autovacuum, la gestion des droits, le choix des extensions et la préparation des migrations. Avec un candidat venu du managé, vérifiez qu'il comprend aussi ce que fait l'hébergeur, en particulier pour la restauration.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
