Un panneau d'administration Postgres sans Docker, sans serveur, sans prise de tête

Je travaille avec PostgreSQL depuis presque une décennie, et la situation côté outils d'administration m'a toujours laissé perplexe. Postgres lui-même est l'un des logiciels les mieux conçus de la planète. C'est rapide, fiable, et il sort une version majeure chaque année avec des fonctionnalités qui comptent vraiment. Et pourtant, les outils qu'on utilise pour regarder nos bases Postgres ont l'air figés dans l'ambre.

pgAdmin 4 est la réponse « officielle », et il n'a pas vraiment évolué depuis des années. DBeaver fonctionne, certes, mais à chaque fois que je l'ouvre, on me rappelle que c'est une app Java de 2010. TablePlus est sympa et rapide, mais c'est un outil de requête, pas un panneau d'administration. Et les options cloud comme Retool et NocoDB te donnent un vrai panneau d'administration, mais seulement si tu acceptes de faire passer ta connexion de base de données par leurs serveurs.

Tout le monde à qui j'en parle veut la même chose : un panneau d'administration moderne pour Postgres qui ne nécessite ni Docker, ni serveur, ni donner ta chaîne de connexion à un tiers. Ça ne devrait pas être une demande controversée en 2026. Et pourtant, pendant longtemps, ça l'était.

Ce post, c'est l'histoire de comment j'ai fini par résoudre ce problème pour moi-même, et le workflow que j'ai adopté. Je serai honnête sur les alternatives, parce que la plupart sont de bons outils avec simplement des compromis différents. Mais je te montrerai aussi ce que j'utilise au final et pourquoi.

Les options actuelles d'administration Postgres (et leurs compromis)

Passons en revue ce qui existe vraiment, parce que le paysage est plus nuancé que « pgAdmin nul, tout le reste bien ». Chacun de ces outils existe pour une raison, et chacun a une vraie audience. La question, c'est quels compromis comptent pour toi.

pgAdmin 4

pgAdmin est l'outil de gestion officiel de PostgreSQL, maintenu aux côtés de la base de données elle-même. Ce pedigree compte pour quelque chose. Il supporte toutes les fonctionnalités Postgres, il comprend les dernières versions du serveur dès le premier jour, et il a un support approfondi pour des choses comme la gestion des rôles, l'instrumentation du serveur, et le planificateur de jobs pgAgent.

Le problème, c'est l'architecture. pgAdmin 4 est une application web. Pour le lancer localement, tu l'installes soit comme une app de bureau (qui embarque un runtime Python et lance un serveur web local en dessous), soit tu le lances dans Docker. Dans les deux cas, tu fais tourner un serveur Python pour servir une UI navigateur pour parler à une base de données qui tourne déjà sur ta machine. Ça fait beaucoup de pièces mobiles pour quelque chose qui devrait juste être « ouvrir ma base et la regarder ».

L'UI elle-même est fonctionnelle mais datée. C'est une web app qui fait semblant d'être une app de bureau, et ça se ressent. Navigation en arbre, fenêtres de requête à onglets, un panneau de propriétés qui prend la moitié de l'écran. Pas de vues kanban, pas de galeries, pas de dashboards. Si tu veux parcourir tes données sous autre forme qu'une grille de résultats SQL, c'est mort.

Pour les DBA qui gèrent des clusters de production, pgAdmin reste un choix raisonnable. Pour un développeur qui veut juste une vue propre de son Postgres local, c'est overkill.

DBeaver

DBeaver, c'est la bête de somme multiplateforme. Il supporte quasiment toutes les bases de données qui existent, il est gratuit (la Community Edition en tout cas), et il a des fonctionnalités à n'en plus finir. Diagrammes ER, génération de données, édition SQL avec autocomplétion, gestion des sessions, contrôles d'isolation des transactions. S'il y a une fonctionnalité de base de données, DBeaver a probablement un bouton pour ça.

Mais DBeaver est une app Java, et ça se ressent. Le démarrage prend quelques secondes sur une machine rapide et nettement plus longtemps sur une lente. L'UI est dense, avec des barres d'outils dans des barres d'outils dans des panneaux. À chaque fois que je l'ouvre, je passe les trente premières secondes à me rappeler où se trouve ce dont j'ai besoin. C'est puissant, mais ce n'est pas agréable.

Et comme pgAdmin, DBeaver est fondamentalement un outil de requête. Tu écris du SQL, tu obtiens une grille. Pas de vue kanban de ta table de tâches. Pas de vue galerie de ta table d'images. Pas de dashboard qui m'affiche un graphique des inscriptions par jour à côté d'une table des utilisateurs récents. Si tu veux ça, tu te le construis toi-même ou tu ne l'as pas.

DBeaver, c'est le bon outil si tu vis dans le SQL et que tu veux une seule app pour toutes les bases que tu touches. C'est le mauvais outil si tu veux que ta base de données ressemble à une application moderne.

TablePlus / Postico

TablePlus (et son cousin centré Mac, Postico), c'est la catégorie que j'ai personnellement utilisée le plus longtemps. Ce sont des apps natives, rapides et vraiment agréables à utiliser. TablePlus s'ouvre instantanément, lance les requêtes vite, et a une UI qui a l'air d'avoir été designée cette décennie. Sur macOS, Postico est encore plus agréable, avec une vraie attention aux conventions Mac.

Mais voilà le truc : TablePlus et Postico sont des outils de requête, pas des panneaux d'administration. Ils sont excellents pour écrire du SQL et parcourir des tables. Ils ne sont pas excellents pour, disons, transformer ta table users en kanban, ou construire un dashboard que ton cofondateur non-technique peut consulter, ou donner à un coéquipier une vue restreinte d'une table sans écrire une app custom.

Il y a aussi la question multi-base. TablePlus supporte beaucoup de bases, ce qui est super, mais chacune reste juste une fenêtre de requête. Tu n'as pas un panneau d'administration unifié qui traite ta base SQLite de side-project et ta base Postgres de production de la même façon.

Si tu veux un client SQL natif et rapide, TablePlus est excellent. Si tu veux un panneau d'administration, ce n'est pas ce produit.

Panneaux d'administration cloud (Retool, NocoDB, Budibase)

C'est la catégorie qui tient vraiment la promesse du « panneau d'administration ». Retool, NocoDB et Budibase te permettent tous de pointer vers une base Postgres et d'obtenir un vrai panneau d'administration : tables, formulaires, dashboards, kanban, tout ça. NocoDB en particulier est open-source et peut transformer une base Postgres en quelque chose qui ressemble à Airtable en quelques minutes.

Le compromis, c'est l'architecture. Ce sont toutes des applications web hébergées dans le cloud (ou auto-hébergées sur un serveur). Pour les utiliser, ta connexion Postgres, tes identifiants, et souvent tes résultats de requêtes transitent par leurs serveurs. Pour une base de production avec des données sensibles, c'est une vraie considération. Même NocoDB, que tu peux auto-héberger, nécessite de faire tourner un serveur, ce qui veut généralement dire Docker.

Il y a aussi la question de la latence et du hors ligne. Si ton Postgres est local, passer par un panneau d'administration cloud veut dire que tes requêtes vont de ta machine, jusqu'à un serveur cloud, redescendent vers ta base locale, et les résultats font le trajet inverse. C'est absurde pour une base de dev locale, et ça veut dire que tu ne peux pas travailler hors ligne.

Ces outils sont vraiment bons pour ce qu'ils sont. Si tu as besoin d'un panneau d'administration web partagé pour une équipe, Retool est un produit sérieux. Mais pour un développeur solo ou une petite équipe qui travaille avec un Postgres local ou auto-hébergé, l'aller-retour cloud est un compromis que tu ne devrais pas avoir à faire.

Construire le tien (Django admin, PostgREST + UI custom)

La dernière option, c'est celle vers laquelle beaucoup d'ingénieurs se tournent par défaut : construire le tien. Django te donne un panneau d'administration gratuitement si tu es déjà dans Django. PostgREST transforme ton Postgres en API REST et tu construis l'UI que tu veux par-dessus. Hasura fait la même chose avec GraphQL.

L'attrait est évident : contrôle total, aucune dépendance à un outil tiers, exactement les vues dont tu as besoin. Le coût est aussi évident : tu le maintiens pour toujours. Le Django admin est génial jusqu'à ce que tu veuilles une vue kanban, moment où tu te mets à écrire des templates custom. PostgREST est génial jusqu'à ce que tu réalises que tu dois maintenant construire un frontend entier.

J'ai construit ce genre de truc trois fois dans ma carrière, et à chaque fois c'est devenu de la dette technique. Le panneau d'administration qui devait faire gagner du temps devient le truc que personne ne veut toucher parce qu'il est couplé à une version de framework d'il y a deux ans.

Construire le tien, c'est la bonne réponse si tes besoins en panneau d'administration sont très spécifiques et que tu as la capacité technique de les maintenir. Pour tout le reste, c'est un piège.

Ce que « sans Docker » veut vraiment dire

Il y a un truc qui me trotte dans la tête. Va chercher « postgres admin panel » et lis les dix premiers tutoriels. Je te paie un café qu'au moins huit commencent par docker run.

Un truc comme ça :

docker run -p 8080:80 \
  -e PGADMIN_DEFAULT_EMAIL=admin@example.com \
  -e PGADMIN_DEFAULT_PASSWORD=secret \
  dpage/pgadmin4

Et écoute, je comprends pourquoi. Docker est la lingua franca du déploiement. Si tu mets un panneau d'administration sur un serveur pour qu'une équipe le partage, le conteneuriser est la bonne décision. Je ne suis pas anti-Docker. J'utilise Docker tous les jours.

Mais réfléchis à ce qui se passe vraiment quand tu lances cette commande pour une base locale. Tu démarres un conteneur. Ce conteneur fait tourner un environnement Linux. Dans cet environnement, un serveur web Python démarre. Ce serveur web sert une UI navigateur. Tu ouvres ton navigateur, qui parle au serveur web, qui parle à la base de données qui tourne déjà sur ta machine.

Pour un workflow de développeur local, c'est une chaîne comiquement longue d'indirections. Ta base de données est juste là. À un socket localhost près. Tu introduis un conteneur, un userland Linux, un runtime Python, et une couche HTTP juste pour rendre une table de lignes.

Il y a aussi l'angle maintenance. Les images Docker ont besoin de mises à jour. L'image pgAdmin sort une nouvelle version et tu dois la pull. Tes volume mounts doivent persister tes enregistrements de serveurs. Si tu redémarres ta machine, le conteneur ne revient pas sauf si tu as configuré une politique de redémarrage. Rien de tout ça n'est difficile, mais c'est de la friction qui existe purement parce que l'outil a choisi une architecture web.

« Sans Docker » ne veut pas dire « je déteste les conteneurs ». Ça veut dire : pour le cas courant d'un développeur qui veut regarder son Postgres local, la couche de conteneur est une indirection inutile. Une app de bureau native qui parle à Postgres via un socket, c'est plus simple, plus rapide et plus fiable. C'est tout l'argument.

Ça veut aussi dire « sans serveur ». Beaucoup d'outils de panneau d'administration, même ceux qui ne sont pas Dockerisés, sont des web apps qui ont besoin d'un processus serveur en marche. Soit tu le fais tourner toi-même, soit quelqu'un d'autre le fait. Une application de bureau local-first n'a pas besoin de serveur. Tu lances l'app, elle se connecte à ta base, c'est fini. Quand tu quittes l'app, rien ne tourne. Pas de port à gérer, pas de processus à tuer, pas de service en arrière-plan qui bouffe de la RAM quand tu ne l'utilises pas.

C'est ça que je n'arrêtais pas de rencontrer. Chaque panneau d'administration « moderne » voulait que je fasse tourner un serveur. Chaque option native n'était qu'un client SQL. Il n'y avait rien au milieu : natif, rapide, sans serveur, mais avec de vraies vues de panneau d'administration, pas juste une grille de requêtes.

L'alternative local-first

C'est là que je te dis ce que j'utilise vraiment. Je vais être transparent : je suis impliqué dans BaseVolt, donc ce n'est pas une recommandation impartiale. Mais je m'y suis impliqué justement parce que j'étais assez frustré pour vouloir quelque chose de mieux, donc le biais et le cas d'usage sont la même chose.

BaseVolt est une application de bureau local-first. Elle tourne sur macOS et Windows. Pas de compte cloud requis, pas de serveur à faire tourner, pas de conteneur Docker. Tu télécharges, tu ouvres, tu te connectes à ta base. C'est toute la configuration.

L'idée clé, c'est qu'elle donne à n'importe quelle base de données un panneau d'administration complet, pas juste une fenêtre de requête. Donc pour Postgres spécifiquement, tu te connectes avec une chaîne de connexion standard, et BaseVolt lit ton schéma, tes tables, tes colonnes, tes types, tes clés étrangères. Ensuite, il te donne :

Une vue grille pour parcourir les lignes, comme tu t'y attends, mais avec de vraies résolutions de clés étrangères pour que tu voies le nom d'affichage de la ligne liée au lieu d'un simple ID entier.
Une vue galerie pour les tables qui ont des images ou des fichiers, ce qui est vraiment utile pour les tables de contenu.
Une vue kanban pour toute table avec une colonne de statut, c'est comme ça que je gère mes propres tâches de projet qui vivent dans Postgres.
Une vue dashboard où tu peux déposer des graphiques et des tables sur un canvas et construire quelque chose qu'une personne non-technique peut réellement lire.

Il y a aussi un serveur MCP intégré. MCP, c'est le protocole qui permet aux outils de codage AI comme Claude, Cursor et Windsurf de se connecter à des systèmes externes. Avec le serveur MCP de BaseVolt en marche, je peux pointer Cursor vers ma base Postgres et dire « ajoute une colonne last_login_at à la table users et backfill-la depuis la table sessions », et Cursor peut vraiment introspecter le schéma, écrire la migration et la lancer, parce qu'il voit la base à travers BaseVolt.

La partie local-first compte pour moi. Ma chaîne de connexion ne quitte jamais ma machine. Mes résultats de requêtes ne quittent jamais ma machine. Quand je travaille avec un Postgres local, tout reste local. Pas d'aller-retour par un serveur cloud. Je peux travailler dans un avion.

Le tier gratuit te permet de connecter jusqu'à deux sources de données, ce qui est suffisant pour l'essayer sur un Postgres local et peut-être un side-project SQLite. Le tier Pro est à $99/an et ajoute la synchronisation entre appareils, utile si tu veux que ta configuration de panneau d'administration te suive entre un laptop et un desktop.

Je ne vais pas faire semblant que BaseVolt est le bon outil pour toutes les situations. C'est une app de bureau, ce qui veut dire que ce n'est pas un panneau d'administration web partagé pour une équipe de 50 personnes. Mais pour le cas du développeur solo et des petites équipes, ce qui correspond à la plupart des gens que je connais qui travaillent avec Postgres, c'est la chose qui m'a enfin semblé juste.

Étape par étape : un panneau d'administration Postgres en moins d'une minute

Laisse-moi te le détailler, parce que « moins d'une minute » est une affirmation que je devrais pouvoir prouver. Ça suppose que tu as déjà Postgres qui tourne quelque part, localement ou à distance, et que tu connais tes paramètres de connexion.

Étape 1 : Installe BaseVolt

Va sur basevolt.app et télécharge l'app pour ta plateforme. Il y a macOS et Windows. Pas de création de compte, pas de confirmation par email, pas de carte bancaire. Tu télécharges un .dmg ou un installeur, tu le lances, et l'app s'ouvre.

Si tu veux jeter un œil avant d'installer quoi que ce soit, il y a une démo sur demo.basevolt.app qui tourne dans le navigateur sur une base de données d'exemple. Ce n'est pas l'expérience complète de bureau, mais ça te donnera une idée des vues et de l'UI.

Cette étape prend environ 20 secondes, en supposant que ta vitesse de téléchargement coopère.

Étape 2 : Ajoute une source de données PostgreSQL

Ouvre l'app et clique sur « Add Data Source ». Tu verras des options pour SQLite, PostgreSQL, MySQL et Cloudflare D1. Choisis PostgreSQL.

Tu peux te connecter soit en remplissant les champs individuels, soit en collant une chaîne de connexion standard. J'utilise toujours la chaîne de connexion parce que c'est ce que j'ai déjà dans mes fichiers .env. Ça ressemble à ça :

postgresql://user:password@localhost:5432/mydatabase

Colle-la, clique sur connecter. BaseVolt se connecte à Postgres en utilisant le protocole standard compatible libpq, donc tout ce qui marche avec psql marche ici. Mode SSL, ports custom, chemins de socket Unix, tout est supporté.

Cette étape prend environ 10 secondes.

Étape 3 : Laisse BaseVolt lire ton schéma

Une fois connecté, BaseVolt introspecte ta base de données. Il lit tes tables, tes colonnes, tes types de données, tes clés primaires et étrangères, tes index. Tout ça se fait localement, via ta connexion existante.

Tu verras tes tables listées dans la sidebar, groupées par schéma. Clique sur n'importe quelle table et tu es dans la vue grille par défaut, affichant la première page de lignes. Les colonnes de clés étrangères affichent la valeur lisible de la ligne liée au lieu d'un ID brut, ce qui est un petit truc qui m'évite beaucoup de requêtes JOIN.

La lecture du schéma est mise en cache, donc la navigation est instantanée après le premier chargement. Si tu changes ton schéma en dehors de BaseVolt, il y a un bouton refresh pour ré-introspecter.

Cette étape prend environ 5 secondes, selon le nombre de tables que tu as.

Étape 4 : Parcours avec les vues grille, kanban, galerie et dashboard

C'est là que ça cesse d'être un outil de requête et devient un panneau d'administration.

La vue grille est ton navigateur de tables standard. Colonnes triables, édition en place, filtrage des lignes par n'importe quelle colonne. Tu peux éditer une cellule, taper Entrée, et ça écrit dans Postgres. Il y a un undo pour l'édition en cours. Pour une table users, c'est comme ça que je fais des corrections de données rapides sans écrire de UPDATE.

La vue kanban fonctionne sur toute table qui a une colonne que BaseVolt peut traiter comme un statut. J'ai une table tasks dans une de mes bases Postgres avec une colonne status qui est un enum : todo, in_progress, done. BaseVolt propose automatiquement une vue kanban pour elle, avec les trois colonnes, des cartes déplaçables, et un compte par colonne. Glisser une carte met à jour le statut dans Postgres. C'est le truc que je n'ai jamais eu avec TablePlus et que j'ai toujours voulu.

La vue galerie est pour les tables avec des colonnes d'images ou de fichiers. J'ai une table products avec une colonne image_url, et la vue galerie m'affiche une grille de photos de produits avec le nom du produit en dessous. C'est comme ça que je QA un catalogue sans écrire une seule requête.

La vue dashboard est celle que j'utilise pour le reporting. Tu as un canvas, et tu peux déposer des graphiques (barres, lignes, camemberts) alimentés par des requêtes sur ton Postgres, plus des tables et des cartes de stats. J'ai un dashboard qui affiche les inscriptions par jour, une table des dix utilisateurs les plus récents, et une carte de stat avec le revenu total. Je partage une version en lecture seule avec mon cofondateur, qui ne veut pas écrire de SQL.

Construire un dashboard prend quelques minutes la première fois et ensuite c'est sauvegardé. Tu n'as rien à redéployer quand tu le modifies. Il est juste là.

Cette étape prend autant de temps que tu veux y passer, mais tu peux obtenir une vue utile en bien moins d'une minute.

Étape 5 : Utilise le serveur MCP pour le travail de schéma assisté par AI

C'est la partie qui a vraiment changé ma façon de travailler, et ça vaut la peine de l'expliquer parce que beaucoup de gens n'ont pas encore utilisé MCP.

MCP, le Model Context Protocol, est une façon standard pour les outils AI de parler à des systèmes externes. BaseVolt fait tourner un serveur MCP localement. Tu pointes ton outil de codage AI, Cursor en ce qui me concerne, vers ce serveur MCP. Maintenant Cursor peut voir ton schéma de base de données à travers BaseVolt.

Le workflow pratique ressemble à ça. Je suis dans Cursor, et je tape : « Ajoute une colonne timestamp last_login_at à la table users, et écris un backfill qui la définit au created_at le plus récent de la table sessions pour chaque utilisateur. »

Parce que Cursor peut voir mon schéma via le serveur MCP de BaseVolt, il connaît les noms exacts des colonnes, les types et les relations de clés étrangères. Il écrit une migration qui est réellement correcte, pas une devinette. Je la révise, je l'approuve, et elle tourne sur mon Postgres. Le tout prend peut-être 30 secondes et je n'ai pas à changer de contexte pour aller dans un client SQL chercher des noms de colonnes.

Ça marche avec Claude, Cursor et Windsurf, tout ce qui parle MCP. Pour la gestion de schéma, le refactoring de schéma, et même l'exploration de données, c'est un vrai gain de productivité. Je passais avant une quantité surprenante de temps à sauter entre mon éditeur et un client SQL juste pour me rappeler si une colonne s'appelait user_id ou users_id. Cette friction a disparu.

Pour l'activer, il y a un réglage dans BaseVolt qui démarre le serveur MCP et te donne la chaîne de connexion à coller dans la config de ton outil AI. Ça tourne localement, donc ton schéma et tes résultats de requêtes restent sur ta machine.

Tableau comparatif

Voilà comment les options se comparent. J'ai essayé d'être juste, parce que ce sont tous de vrais outils avec de vrais utilisateurs, moi y compris.

Outil	Temps de configuration	Docker requis	App native	Vues et dashboards	Intégration AI	Données quittent la machine	Coût
pgAdmin 4	5-10 min (ou pull Docker)	Optionnel, mais courant	Non, web	Non, grille de requêtes seulement	Non	Non (si local)	Gratuit
DBeaver	2-5 min	Non	Oui (Java)	Non, grille de requêtes seulement	Non	Non	Gratuit (Community)
TablePlus / Postico	1-2 min	Non	Oui (native)	Non, grille de requêtes seulement	Non	Non	$59-89/an
Retool (cloud)	10-20 min	Non (hébergé cloud)	Non, web	Oui, panneau d'administration complet	Limité	Oui, via les serveurs cloud	Tier gratuit, puis $10+/utilisateur/mois
NocoDB	5-10 min (auto-hébergé)	Oui, typiquement	Non, web	Oui, panneau d'administration complet	Non	Dépend de l'hébergement	Gratuit (auto-hébergé)
BaseVolt	Moins d'1 min	Non	Oui (native)	Oui, grille/kanban/galerie/dashboard	Oui, serveur MCP intégré	Non	Tier gratuit (2 sources), Pro $99/an

Quelques notes sur le tableau, parce que les tableaux aplatissent les nuances :

Le « les données ne quittent pas la machine » de pgAdmin n'est vrai que si tu le lances localement. Si tu utilises le pgAdmin hébergé dans le cloud, évidemment tes données passent par leurs serveurs.
Les fonctionnalités AI de Retool existent mais sont côté cloud, ce qui veut dire que ton schéma et tes requêtes vont vers leur fournisseur AI. L'approche MCP de BaseVolt garde l'interaction AI dans ton éditeur local.
NocoDB est vraiment gratuit et open-source, ce qui est super. Le coût, c'est que tu fais tourner un serveur, ce qui est une charge de maintenance.
TablePlus est excellent dans ce qu'il fait. Il est dans ce tableau comme référence « client SQL natif rapide ». Ce n'est juste pas un panneau d'administration.

La ligne qui compte pour moi, et peut-être pour toi, c'est la dernière. Moins d'une minute à configurer, pas de Docker, app native, de vraies vues et dashboards, intégration AI qui tourne localement, données qui restent sur ma machine, et un tier gratuit réellement utilisable. C'est la combinaison que je n'ai trouvée nulle part ailleurs.

Quand cette approche gagne (et quand elle ne gagne pas)

Je veux être honnête là-dessus, parce qu'aucun outil n'est bon pour toutes les situations, et faire semblant du contraire, c'est comment on se retrouve avec du marketing au lieu d'une recommandation utile.

L'approche local-first, app de bureau gagne quand :

Tu es un développeur individuel ou une petite équipe qui travaille avec Postgres. C'est le sweet spot. Tu veux un panneau d'administration natif et rapide, tu ne veux pas faire tourner de serveur, et tu n'as pas besoin de partager une UI web avec 30 personnes.
Ton Postgres est local ou sur une machine que tu peux atteindre directement. Si tu te connectes à localhost:5432 ou à un VPS via un réseau privé, une app de bureau est le choix naturel.
Tu te soucies que tes données ne quittent pas ta machine. Ça compte pour les bases de dev locales avec des seed data qui reflètent la production, pour les bases avec des PII, et pour quiconque est simplement soucieux de sa vie privée par défaut.
Tu veux du travail de schéma assisté par AI sans envoyer ton schéma à un service AI cloud. L'approche serveur MCP garde l'AI dans ton éditeur local tout en lui donnant accès à ton vrai schéma.
Tu veux des vues de panneau d'administration, pas juste une grille SQL. Si kanban, galerie et dashboards changeraient vraiment ta façon d'interagir avec tes données, un outil de requête ne suffira pas.

L'approche local-first ne gagne pas quand :

Tu as besoin d'un panneau d'administration web partagé across une grande équipe distribuée. Si tu as 40 personnes across trois fuseaux horaires qui doivent toutes regarder la même base Postgres via un navigateur, pgAdmin déployé sur un serveur, ou Retool, ou NocoDB, est probablement le bon choix. Une app de bureau n'est pas un service web partagé, et faire semblant le serait malhonnête.
Tu as besoin que le panneau d'administration soit accessible depuis un téléphone ou une machine aléatoire sans rien installer. Les outils web gagnent ici par définition. BaseVolt nécessite d'installer une app de bureau, ce qui est un coût unique mais réel.
Tu es sur Linux. Je vais être direct : BaseVolt est sur macOS et Windows pour le moment. Si tu vis sur Linux, tu es mieux avec DBeaver ou un NocoDB auto-hébergé. Je ne vais pas faire semblant qu'un outil qui ne tourne pas sur ton OS est un bon choix pour toi.
Tu as besoin de fonctionnalités DBA avancées comme la planification de jobs pgAgent, l'instrumentation du serveur, ou la gestion fine des replication slots. pgAdmin a encore l'avantage là-dessus parce qu'il est construit par l'équipe Postgres pour les DBA Postgres. BaseVolt est conçu pour les développeurs et les petites équipes qui veulent un panneau d'administration, pas pour les DBA qui gèrent des clusters de production.

Le résumé honnête, c'est que BaseVolt est le bon outil pour le cas développeur-et-petite-équipe, ce qui représente une grande partie des gens qui utilisent Postgres. Ce n'est pas le bon outil pour le cas DBA-qui-gère-une-flotte, et ce n'est pas le bon outil pour le cas grande-équipe-panel-web-partagé. Si tu es dans un de ces cas, utilise pgAdmin ou un outil cloud. Si tu es dans le premier cas, l'approche local-first de bureau est, dans mon expérience, nettement meilleure que les alternatives.

En résumé

La situation des outils d'administration Postgres est restée stagnante pendant longtemps, et je pense que la raison, c'est que la plupart des outils ont été construits pour une audience différente de celle qui les utilise aujourd'hui. pgAdmin a été construit pour les DBA. DBeaver a été construit pour les power users agnostiques à la base de données. TablePlus a été construit pour les gens qui veulent un client SQL rapide. Les panneaux d'administration cloud ont été construits pour les équipes qui veulent une UI web partagée.

Ce qui manquait, depuis longtemps, c'était quelque chose construit pour le développeur qui a une base Postgres et veut un panneau d'administration moderne sans le Docker, sans le serveur, et sans l'aller-retour cloud. C'est le vide que BaseVolt comble, et c'est pour ça que je l'utilise.

Si tu as serré les dents devant pgAdmin dans un navigateur, ou plissé les yeux devant le labyrinthe de barres d'outils de DBeaver, ou payé TablePlus sans jamais avoir de vue kanban, essaye. Ça s'installe en moins d'une minute, le tier gratuit te permet de connecter deux sources de données, et tes données ne quittent jamais ta machine. L'intégration MCP seule a changé ma façon de faire du travail de schéma, et les vues sont le truc que je ne savais pas me manquer jusqu'à ce que je les aie.

Essayez-le sur basevolt.app — pas d'inscription, pas de carte bancaire.

Si tu construis quelque chose avec, ou si tu as des idées sur comment le paysage des outils Postgres pourrait être meilleur, j'aimerais vraiment l'entendre. Retrouvez-moi sur X.