Quand j’ai commencé à former mes étudiants en BTS SIO à la conteneurisation, la première question qui revenait systématiquement était : « quelle image PostgreSQL choisir sur Docker Hub ? ». Et pour cause, une simple recherche « postgres » sur la plateforme renvoie des dizaines de résultats. Entre l’image officielle, les variantes Alpine, les builds Bitnami ou encore les images spécialisées PostGIS, le choix peut sembler déroutant. Dans ce guide, je vous propose un comparatif complet des images disponibles sur postgres docker hub pour vous aider à faire le bon choix selon votre contexte.

Les images officielles PostgreSQL sur Docker Hub

L’image officielle postgres sur Docker Hub est maintenue par le projet Docker Library sur GitHub. C’est la référence absolue pour déployer PostgreSQL en conteneur. Elle est construite à partir des sources officielles du projet PostgreSQL et bénéficie d’un processus de validation rigoureux avant chaque publication.

Cette image couvre toutes les versions majeures actives de PostgreSQL, de la version 13 jusqu’à la version 17 au moment où j’écris ces lignes. Chaque version majeure dispose de ses propres tags, ce qui permet de cibler précisément la version souhaitée. L’image supporte nativement les architectures amd64 et arm64, ce qui la rend compatible avec les Mac Apple Silicon et les serveurs ARM.

Je recommande systématiquement cette image à mes étudiants pour leurs premiers projets. Elle offre un excellent équilibre entre simplicité de configuration et fiabilité. Les variables d’environnement comme POSTGRES_PASSWORD, POSTGRES_USER et POSTGRES_DB permettent une initialisation rapide sans fichier de configuration complexe.

Un point que je souligne toujours en cours : l’image officielle inclut un mécanisme d’initialisation automatique. Tout script SQL ou shell placé dans le répertoire /docker-entrypoint-initdb.d/ sera exécuté au premier démarrage du conteneur. C’est extrêmement pratique pour créer des schémas, insérer des données de test ou configurer des extensions. Si vous travaillez avec des réseaux Docker, je vous invite à consulter mon guide complet sur Docker networking pour bien comprendre comment vos conteneurs communiquent entre eux.

Comprendre les variantes et tags disponibles

La nomenclature des tags sur docker hub postgres suit une logique précise qu’il faut maîtriser pour éviter les mauvaises surprises. Voici les principales variantes que vous rencontrerez.

Le tag postgres:latest pointe toujours vers la dernière version stable de PostgreSQL sur Debian. En production, je déconseille formellement son utilisation car il peut changer de version majeure sans préavis. Préférez toujours un tag versionné comme postgres:17 ou mieux encore postgres:17.2 pour un contrôle total.

Les tags Alpine (par exemple postgres:17-alpine) utilisent Alpine Linux comme système de base au lieu de Debian. Le gain en taille est considérable : environ 80 Mo contre 430 Mo pour la version Debian. En revanche, Alpine utilise musl au lieu de glibc, ce qui peut provoquer des incompatibilités avec certaines extensions compilées. Pour un environnement de développement ou des microservices légers, c’est souvent le meilleur choix.

Les tags Bookworm et Bullseye précisent la version de Debian utilisée. Bookworm (Debian 12) est la version actuelle, tandis que Bullseye (Debian 11) reste disponible pour les projets qui nécessitent une compatibilité spécifique. Cette distinction devient importante lorsque vous installez des paquets supplémentaires dans votre Dockerfile.

Enfin, les tags avec un numéro de patch complet (comme postgres:17.2-bookworm) offrent la reproductibilité maximale. C’est ce que j’utilise systématiquement dans mes fichiers Docker Compose YML en production.

Les images communautaires et alternatives

Au-delà de l’image officielle, plusieurs éditeurs proposent leurs propres images PostgreSQL sur Docker Hub. Chacune apporte des fonctionnalités ou des garanties spécifiques.

Bitnami PostgreSQL est probablement l’alternative la plus populaire. Maintenue par VMware (via Bitnami), cette image applique par défaut un utilisateur non-root, ce qui renforce la sécurité. Elle propose également une configuration simplifiée de la réplication maître-esclave via des variables d’environnement dédiées. J’apprécie particulièrement sa documentation exhaustive et sa cohérence avec les autres images Bitnami.

Ubuntu PostgreSQL (ubuntu/postgres) est maintenue par Canonical. Elle suit les cycles de publication d’Ubuntu et bénéficie des correctifs de sécurité via le programme Ubuntu Pro. Si votre infrastructure repose déjà sur Ubuntu, cette image garantit une homogénéité de votre pile logicielle.

PostGIS (postgis/postgis) intègre l’extension géospatiale directement dans l’image. Pour les développeurs qui travaillent avec des données géographiques, c’est un gain de temps considérable : pas besoin de compiler PostGIS manuellement ni de gérer les dépendances GEOS et PROJ.

Extended Postgres (postgresai/extended-postgres) de Postgres.ai embarque un ensemble d’extensions préinstallées : pg_stat_statements, pg_hint_plan, pgvector et bien d’autres. C’est une image particulièrement intéressante pour le développement et le test de performance sans avoir à construire une image personnalisée.

Les images Hardened proposées par Docker via le programme Docker Verified Publisher offrent des garanties de sécurité supplémentaires avec des scans de vulnérabilités réguliers et des correctifs accélérés. Elles ciblent principalement les entreprises soumises à des exigences de conformité strictes. Pour approfondir la sécurité de vos systèmes, mon article sur la sensibilisation à la cybersécurité aborde les fondamentaux à connaître.

Comparatif détaillé des principales images

Pour vous aider à trancher, j’ai rassemblé les caractéristiques essentielles des principales images disponibles sur postgres docker hub dans le tableau suivant.

Ce tableau montre clairement que le choix dépend avant tout de vos contraintes opérationnelles. En formation, je reviens souvent sur un point : la taille de l’image n’est pas le seul critère. La fréquence des mises à jour de sécurité, la qualité de la documentation et la compatibilité avec votre infrastructure comptent tout autant.

Comment choisir la bonne image pour votre projet

Après avoir accompagné des dizaines de projets étudiants et professionnels, j’ai développé une grille de décision simple que je partage avec vous.

Pour un projet personnel ou un TP en BTS SIO, l’image officielle postgres:17 fait parfaitement l’affaire. Elle est bien documentée, stable et largement utilisée dans les tutoriels. La communauté est vaste, donc vous trouverez facilement de l’aide en cas de problème.

Pour un pipeline CI/CD où le temps de téléchargement compte, la variante Alpine est idéale. Sa taille réduite accélère significativement le démarrage des jobs de test. Dans un pipeline GitLab CI que j’ai optimisé récemment, le passage à Alpine a réduit le temps de provisionnement de la base de 12 à 4 secondes.

Pour un déploiement en production, je recommande soit l’image officielle avec un tag versionné précis, soit l’image Bitnami pour son exécution non-root par défaut. La configuration de POSTGRES_PORT et du réseau Docker doit être soigneusement planifiée. Pour bien structurer vos réseaux, consultez mon article sur les configurations réseau Docker Compose.

Pour un projet nécessitant des extensions spécifiques, vérifiez d’abord si une image spécialisée existe (PostGIS pour le géospatial, pgvector pour l’IA). Sinon, construisez votre propre image à partir de l’image officielle en ajoutant les extensions nécessaires via un Dockerfile personnalisé.

Enfin, si vous hésitez entre Docker et une alternative comme Podman, mon comparatif Podman vs Docker vous aidera à trancher. Les images PostgreSQL fonctionnent de manière identique avec les deux outils.

Configuration et déploiement pratique

Passons à la pratique. Voici comment je configure typiquement un conteneur PostgreSQL pour un projet de formation ou de développement.

La commande la plus simple pour lancer PostgreSQL avec Docker :

docker run -d \
  --name postgres-dev \
  -e POSTGRES_PASSWORD=monMotDePasse \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_DB=mabase \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17-bookworm

Quelques points essentiels à retenir. Le volume nommé pgdata est absolument critique : sans lui, vos données disparaissent à chaque arrêt du conteneur. La variable POSTGRES_PASSWORD est obligatoire depuis PostgreSQL 14 sur l’image officielle. Le port 5432 est le port par défaut de PostgreSQL ; vous pouvez le mapper sur un autre port hôte si nécessaire avec -p 5433:5432 par exemple.

Pour un déploiement plus structuré, un fichier docker-compose.yml est préférable :

services:
  db:
    image: postgres:17.2-bookworm
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      POSTGRES_DB: production
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./init-scripts:/docker-entrypoint-initdb.d
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d production"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

J’attire votre attention sur l’utilisation de POSTGRES_PASSWORD_FILE au lieu de POSTGRES_PASSWORD. Cette approche utilise les Docker secrets pour éviter d’exposer le mot de passe en clair dans les variables d’environnement. C’est une pratique que j’enseigne systématiquement pour préparer mes étudiants aux exigences de la production. Pour des configurations Compose plus avancées, consultez mon article sur les différences entre net et network dans Docker Compose.

Le healthcheck est un autre élément que je considère indispensable. Il permet à Docker de vérifier que PostgreSQL est effectivement prêt à accepter des connexions avant de démarrer les services dépendants. Sans lui, vos applications risquent de tenter une connexion avant que la base ne soit initialisée.

Sécurité et bonnes pratiques en production

La sécurité d’un conteneur PostgreSQL ne se limite pas au choix de l’image. Voici les pratiques que j’applique et que je recommande à mes étudiants pour un déploiement robuste.

Utilisez toujours un tag précis et immuable. Le tag postgres:17.2-bookworm est préférable à postgres:17 qui peut pointer vers une version de patch différente après une mise à jour. En production, la reproductibilité est essentielle. Certaines équipes vont jusqu’à utiliser le digest SHA256 de l’image pour garantir une immutabilité totale.

Exécutez le conteneur en tant qu’utilisateur non-root quand c’est possible. L’image Bitnami le fait par défaut. Avec l’image officielle, vous pouvez ajouter une directive user: 999 dans votre Compose file. Cette mesure limite l’impact d’une éventuelle compromission du conteneur. La documentation officielle PostgreSQL sur l’authentification détaille les mécanismes disponibles pour sécuriser les connexions.

Ne publiez pas le port 5432 sur l’interface publique. En production, PostgreSQL doit être accessible uniquement via le réseau interne Docker. Remplacez -p 5432:5432 par -p 127.0.0.1:5432:5432 si vous devez absolument exposer le port sur la machine hôte, ou mieux encore, utilisez un réseau Docker dédié sans publication de port.

Activez le chiffrement SSL pour les connexions. L’image officielle supporte la configuration SSL via un montage de certificats. Pour les environnements sensibles, configurez ssl = on dans postgresql.conf et exigez des connexions SSL dans pg_hba.conf.

Planifiez vos sauvegardes. Un volume Docker n’est pas une stratégie de sauvegarde. Utilisez pg_dump ou pg_basebackup avec une rotation automatique. J’intègre généralement un conteneur de sauvegarde dédié dans mon fichier Compose qui exécute pg_dump selon un cron interne. Si vous envisagez de migrer votre infrastructure vers le cloud, mon guide sur la migration d’infrastructure dans le cloud aborde les stratégies de sauvegarde adaptées.

Surveillez les CVE de votre image. Utilisez docker scout cves postgres:17.2-bookworm ou un outil comme Trivy pour scanner régulièrement vos images. Les images officielles sont mises à jour rapidement après la découverte de vulnérabilités, mais c’est à vous de mettre à jour vos déploiements.

Cas d’usage avancés et images spécialisées

Certains projets nécessitent des fonctionnalités qui dépassent le périmètre de l’image officielle standard. Voici les cas d’usage avancés que je rencontre le plus fréquemment.

PostgreSQL avec réplication. L’image Bitnami simplifie considérablement la mise en place d’une réplication streaming. Via des variables d’environnement comme POSTGRESQL_REPLICATION_MODE, POSTGRESQL_REPLICATION_USER et POSTGRESQL_REPLICATION_PASSWORD, vous pouvez configurer un cluster maître-réplica en quelques minutes. C’est une fonctionnalité que l’image officielle ne propose pas nativement.

PostgreSQL avec pgvector pour l’IA. L’extension pgvector permet de stocker et rechercher des vecteurs d’embeddings directement dans PostgreSQL. L’image pgvector/pgvector:pg17 intègre cette extension prête à l’emploi. C’est devenu un choix courant pour les applications de recherche sémantique et de RAG (Retrieval-Augmented Generation).

PostgreSQL avec monitoring intégré. Pour superviser les performances de votre base, vous pouvez coupler PostgreSQL avec Grafana et l’exporteur Prometheus postgres_exporter. J’ai détaillé l’installation de Grafana dans mon article sur l’installation de Grafana avec Docker. Cette combinaison offre une visibilité complète sur les requêtes lentes, l’utilisation mémoire et les connexions actives.

Construction d’une image personnalisée. Quand aucune image existante ne correspond exactement à vos besoins, construisez la vôtre à partir de l’image officielle :

FROM postgres:17.2-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
    postgresql-17-postgis-3 \
    postgresql-17-pgrouting \
  && rm -rf /var/lib/apt/lists/*

COPY custom-postgresql.conf /etc/postgresql/postgresql.conf
COPY init-extensions.sql /docker-entrypoint-initdb.d/

CMD ["postgres", "-c", "config_file=/etc/postgresql/postgresql.conf"]

Cette approche vous donne un contrôle total sur les extensions installées et la configuration appliquée. C’est ce que je recommande pour les projets en production qui nécessitent une configuration sur mesure. N’oubliez pas de versionner votre Dockerfile et de l’intégrer dans votre pipeline CI/CD pour automatiser les reconstructions lors des mises à jour de sécurité.

Si vous travaillez avec d’autres services conteneurisés, comme un serveur d’authentification, mon guide sur le déploiement de Keycloak avec Docker illustre comment orchestrer PostgreSQL avec d’autres conteneurs dans un même environnement.

Pour les étudiants qui souhaitent approfondir leurs compétences SQL en parallèle, mon antisèche SQL complète et mon article sur ADD COLUMN en SQL sont des ressources complémentaires utiles. Maîtriser PostgreSQL dans Docker, c’est aussi maîtriser le SQL qui s’exécute à l’intérieur.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.