Discussion :

[libredb]

Bonjour,

Nous développons LibreDB Studio et je voulais le présenter ici, parce qu'il est parti d'un problème que vous avez sans doute croisé aussi.

La façon habituelle de travailler consiste à installer un client lourd sur son poste. Résultat : les identifiants de production se retrouvent sur le portable de chacun, et chaque collègue utilise une version légèrement différente de l'outil. Nous avons inversé la logique : le client tourne à côté des données, sur votre propre serveur, et tout le monde ouvre la même URL. Rien ne sort de votre infrastructure, il n'y a ni offre hébergée ni compte chez nous.

En pratique c'est un seul conteneur. Vous le lancez, vous ouvrez le navigateur, et vous travaillez.

Seize pilotes sont écrits dans le produit : PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Apache Druid, Elasticsearch, OpenSearch, Trino et Cassandra. Vingt-six autres moteurs parlent l'un de ces protocoles réseau et se connectent via les mêmes pilotes, ce qui porte le total à quarante-deux, dont MariaDB, CockroachDB, YugabyteDB, TimescaleDB, Valkey et DragonflyDB.

Côté fonctionnalités : navigation dans les schémas, éditeur Monaco avec autocomplétion, édition des lignes dans une grille, comparaison de plans d'exécution, export des résultats, gestion de plusieurs connexions en parallèle. Il y a aussi un contrôle d'accès par rôles et du SSO OIDC, ce qui permet à une équipe de partager une instance sans partager un mot de passe.

Il existe également un mode agent qui lit la base et rend compte de ce qu'il a trouvé, en citant les mesures prises. Cette partie fonctionne avec un modèle local via Ollama, sans clé d'API et sans qu'aucune donnée ne quitte la machine. Nous avons mesuré vingt-huit modèles sur six types de tâches, huit cent quarante exécutions au total, et nous avons publié la liste, y compris les modèles qui ont échoué. Le constat gênant est que dans la plupart des échecs le problème venait de nos propres messages d'erreur, pas du modèle.

Licence MIT, sans partie réservée à une édition commerciale.

Le code : https://github.com/libredb/libredb-studio
Une démo en ligne si vous ne voulez rien installer : https://trial.libredb.org

Si quelqu'un l'essaie, votre avis m'intéresse beaucoup, en particulier si vous travaillez avec des moteurs que nous couvrons mal. Je reste disponible pour les questions.

Cordialement

[libredb]

Bonjour,

Je reviens sur mon propre sujet pour une petite mise à jour : la version 0.17.0 vient de sortir.

La principale nouveauté est un serveur MCP intégré, désactivé par défaut. Un agent IA comme Claude Code ou OpenCode peut lister les connexions que l'administrateur a explicitement autorisées, selon le rôle de l'utilisateur, inspecter le schéma et exécuter des requêtes en lecture seule sur PostgreSQL, SQLite, DuckDB ou SQL Server, sans que les identifiants ne quittent le serveur. On n'a pas voulu se reposer sur un filtrage du SQL envoyé : c'est la base elle-même qui refuse l'écriture. Sur PostgreSQL la requête tourne dans une transaction en lecture seule, SQLite et DuckDB sont ouverts en lecture seule, et sur SQL Server on vérifie que le compte ne peut pas écrire. Pour PostgreSQL et SQL Server, un compte à privilèges minimaux est en plus exigé. Côté limites, l'authentification repose sur un simple jeton d'accès (Bearer), sans OAuth, et les résultats des requêtes sont évidemment envoyés au modèle utilisé par l'agent.

Il y a aussi deux nouveaux connecteurs, eux aussi en lecture seule : Prometheus (PromQL via l'API HTTP) et Apache Kafka (topics, lag des consumer groups, lecture des messages sans rejoindre de groupe ni faire de commit d'offset). Cette version corrige également deux vulnérabilités, dont l'une exposait côté navigateur certains secrets des connexions gérées.

Une question pour les DBA du forum : vous laisseriez un agent IA interroger une base de production, même en lecture seule, ou seulement une réplique ?

Les notes de version : https://github.com/libredb/libredb-s...ses/tag/0.17.0