Journal LibreDB Studio : un client de bases de données qu'on héberge à côté de ses bases, pas sur chaque poste

Je bosse sur LibreDB Studio, un client de bases de données sous licence MIT qu'on héberge soi-même. L'idée, c'est d'arrêter d'installer et de maintenir un client lourd sur le poste de chacun. On lance un conteneur à côté des bases, et tout le monde ouvre une URL.

Pour essayer :

docker run -p 3000:3000 -e STORAGE_PROVIDER=sqlite ghcr.io/libredb/libredb-studio:0.15.0
Attention à STORAGE_PROVIDER, qui a l'air facultative et ne l'est pas vraiment. Sans elle, les connexions enregistrées restent dans le localStorage du navigateur au lieu d'aller côté serveur. Et si vous voulez qu'elles survivent au conteneur, montez un volume sur /app/data.

Il y a une démo publique, trial.libredb.org, avec les identifiants dans le README. Honnêtement elle ne vous servira pas à grand-chose : elle est restée bloquée sur une vieille version et annonce encore « 7+ moteurs ». C'est notre faute, pas la vôtre.

16 moteurs, une seule interface

PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL, DuckDB, MongoDB, Redis, Couchbase, ClickHouse, Druid, Elasticsearch, OpenSearch, Trino, Cassandra. Même explorateur partout, avec les diagrammes entité-association, la comparaison de schémas et la supervision quand le moteur fournit de quoi les alimenter.

S'ajoutent 26 moteurs qui parlent le protocole d'un de ces pilotes : Citus, CockroachDB, TimescaleDB, YugabyteDB, MariaDB, TiDB, Valkey, ScyllaDB, etc. On les a tous testés sur une instance réelle, et le détail est publié moteur par moteur dans docs/providers/, échecs compris.

SSO OIDC, rôles, journal d'audit des requêtes, diagrammes, tout est dans la version MIT. Pas par philanthropie. Un outil facturé par utilisateur, de toute façon on ne peut pas le déployer partout où on en a besoin, donc le modèle ne tenait pas.

L'IA reste désactivée tant qu'on ne la configure pas. Sans variable LLM_* le panneau ne s'affiche pas et rien ne sort de la machine. Si on la configure, le fournisseur est au choix, Gemini, OpenAI ou un Ollama local avec un modèle ouvert — dans ce dernier cas les requêtes ne quittent pas la machine non plus. Le mode plan, qui écrit une requête sans la lancer, marche sur les 16. Le mode agent, qui la lance vraiment, est en lecture seule et seulement sur PostgreSQL, SQLite et DuckDB.

Ce que ça ne fait pas

Druid, Elasticsearch et OpenSearch sont en lecture seule chez nous, leur dialecte SQL ne comportant ni UPDATE ni CREATE TABLE. Les commandes correspondantes sont marquées non gérées, comme ça on ne se prend pas l'erreur en pleine figure au moment de s'en servir.

Cassandra, c'est le pire cas. Le nombre de lignes et la taille qu'elle remonte ne veulent rien dire : l'estimation disponible compte les partitions des fichiers déjà écrits sur disque, et elle nous en a sorti 143 pour une table de 500 lignes. Du coup l'explorateur laisse les deux champs vides. C'est moins agréable qu'un chiffre, je sais.

Trino n'est pas une base, mais un moteur de requêtes. Il ne déclare aucune clé, aucun index, et la taille qu'il remonte est celle des systèmes derrière ses connecteurs.

L'image Docker fait 298 Mio compressés pour amd64. C'est lourd pour ce que ça fait et ça ne me plaît pas.

Dépôt : https://github.com/libredb/libredb-studio
Site : https://libredb.org

Le point sur lequel j'aimerais des avis : on a choisi de marquer explicitement les fonctionnalités qu'un moteur ne gère pas, et de publier les résultats de compatibilité avec les échecs dedans. Est-ce que ça vous sert, en pratique, ou est-ce que ça fait surtout du bruit en plus ?