Comment visualiser le schéma d'une base PostgreSQL en diagramme ER

Visualiser le schéma d'une base PostgreSQL en diagramme entité-relation reste l'un des moyens les plus rapides pour comprendre un domaine fonctionnel. Quand on rejoint un projet, qu'on audite une base existante ou qu'on prépare une migration, le diagramme ER donne une vue d'ensemble que la lecture brute des CREATE TABLE ne fournit pas.

Plusieurs outils desktop ou web permettent de produire ce type de diagramme. Ils ne se valent pas tous, et le bon choix dépend d'une question simple : voulez-vous voir le schéma réel tel qu'il est dans la base, ou un modèle que vous maintenez en parallèle ?

Schéma déclaré ou schéma inféré

Deux approches coexistent. La première consiste à écrire le modèle dans un format dédié comme DBML, puis à générer le diagramme depuis ce fichier. C'est utile pour concevoir une base avant qu'elle existe, mais le diagramme dérive vite de la réalité si la base évolue sans mise à jour parallèle du fichier.

La seconde approche consiste à introspecter directement la base. L'outil lit information_schema et pg_catalog, collecte les tables, les colonnes, les clés primaires et les clés étrangères, puis dessine. Le diagramme reflète l'état exact de la base à l'instant T. C'est l'approche utilisée par pgAdmin, DBeaver, DataGrip et QoreDB.

Les outils gratuits et libres

pgAdmin embarque depuis sa version 6 un ERD Tool. Il fonctionne et reste l'option naturelle quand on travaille déjà sous pgAdmin. La disposition automatique est rudimentaire et le rendu n'est pas pensé pour explorer une base de plusieurs centaines de tables, mais pour un schéma de taille moyenne il fait le travail.

SchemaSpy est un outil Java en ligne de commande qui génère un site HTML statique documentant le schéma. Il produit des diagrammes Graphviz et tourne sur n'importe quelle base JDBC. Le rapport est riche, avec relations, types et contraintes détaillés. Le flux d'utilisation est plus lourd : il faut un JDK, un driver JDBC PostgreSQL, puis on ouvre le HTML dans un navigateur.

DBeaver Community propose un visualiseur ERD intégré au client. Il introspecte la base, supporte les clés étrangères et permet de masquer des tables. L'expérience d'exploration reste dense, surtout sur des schémas étendus où le rendu charge l'ensemble du diagramme avant tout filtrage.

Les outils propriétaires

DataGrip de JetBrains propose un diagramme contextuel sur une table donnée ou sur un schéma entier. La qualité de l'introspection est bonne, le rendu est lisible et l'intégration avec l'éditeur SQL est cohérente. C'est une option payante, intégrée à l'écosystème IntelliJ.

dbdiagram.io fonctionne dans le navigateur sur la base d'un DSL maison, le DBML. Il est efficace pour produire un diagramme de conception à partager dans une documentation. Il ne se connecte pas à une base PostgreSQL pour lire son état réel : il faut importer un dump SQL ou écrire le DBML à la main.

L'approche de QoreDB

QoreDB intègre un diagramme ER interactif construit autour de l'introspection native du driver PostgreSQL. Quand la vue s'ouvre, le client charge les tables d'un schéma en parallèle, lit leurs colonnes, leurs clés primaires et leurs clés étrangères via information_schema, puis assemble le diagramme. Tout se passe en local, l'application ne pousse aucune métadonnée vers un service tiers.

Le rendu est volontairement compact. Chaque table est un nœud, avec ses colonnes clés affichées en priorité : clé primaire, clés étrangères sortantes, clés étrangères entrantes. Les autres colonnes sont visibles en dépliant la table. Cette règle évite de saturer l'écran sur des schémas larges, où afficher toutes les colonnes de toutes les tables rend la lecture impossible.

Les arêtes entre tables sont calculées depuis les FK déclarées dans le catalogue. QoreDB ajoute aussi le support des Virtual Relations : des relations définies côté client pour les cas où la base ne déclare pas ses FK. C'est utile sur des bases legacy où les contraintes sont gérées au niveau applicatif et jamais matérialisées dans le schéma.

La vue est manipulable au clavier et à la souris : zoom, pan, recherche par nom de table, isolation d'une table et de ses voisines pour se concentrer sur un sous-ensemble. La logique de layout dispose les tables en colonnes équilibrées, sans demander à l'utilisateur de placer manuellement chaque nœud.

Workflow concret avec QoreDB

L'usage typique commence par l'ouverture d'une connexion PostgreSQL existante. Depuis l'arbre des objets, on sélectionne le schéma à visualiser et on ouvre la vue ER. Le chargement est progressif : un indicateur affiche le nombre de tables introspectées en temps réel, avec une concurrence par défaut de six tables en parallèle pour limiter la charge sur le serveur.

Une fois le diagramme assemblé, on filtre par nom pour isoler un sous-ensemble cohérent, par exemple toutes les tables liées à un domaine métier. On peut cliquer sur une table pour ouvrir son contenu dans un onglet de requête ou de Data Grid. C'est cette boucle, exploration visuelle puis action ciblée, qui rend le diagramme utile au quotidien et pas seulement comme une image à archiver.

Pour les bases où certaines FK manquent, on déclare des Virtual Relations depuis le panneau dédié. Elles sont stockées dans la configuration locale et apparaissent dans le diagramme comme des arêtes distinctes des FK réelles. La base n'est pas modifiée, et les relations restent à votre poste.

Choisir selon le contexte

Le bon outil pour générer un diagramme ER PostgreSQL dépend de l'usage. Pour un design initial à partager dans une RFC, dbdiagram.io reste pratique. Pour un rapport complet à archiver, SchemaSpy fait le travail. Pour de l'exploration au quotidien d'une base réelle, un client desktop intégré comme DataGrip, DBeaver ou QoreDB est plus efficace : le diagramme est toujours à jour avec le schéma vivant, et il sert de point d'entrée vers les requêtes plutôt que d'artefact figé.