LibreDB Studio es un gestor de base de datos open source que funciona en el navegador y se despliega en tu propio servidor con un solo comando de Docker. Todo tu equipo trabaja desde una única instancia compartida, en lugar de instalar un cliente de escritorio en cada máquina. La versión 0.16.0 salió el 17 de septiembre de 2026 con licencia MIT y conecta con 16 motores propios, de PostgreSQL, MySQL y Oracle a MongoDB, Redis y ClickHouse.
Antes de instalar: usa la versión 0.16.2 o posterior. Dos de las correcciones de la serie 0.16 cierran fallos entre cuentas en instancias compartidas. Los detalles están en la sección de seguridad, más abajo.
¿Qué es LibreDB Studio?
LibreDB Studio es un IDE SQL web (un web SQL IDE, o self-hosted SQL client) construido sobre Next.js, con el editor Monaco, el mismo motor de VS Code. El proyecto se posiciona entre los clientes de escritorio pesados, como DataGrip o DBeaver, y las herramientas de línea de comandos.
Cubre lo que esperas de un cliente de escritorio:
- autocompletado que conoce tu esquema
- planes EXPLAIN visuales
- diagramas entidad-relación interactivos, exportables a PNG o SVG
- comparación de esquemas con generación del SQL de migración
- una grilla de datos virtualizada con edición en línea
- exportación a CSV y JSON
Y agrega funciones que solo tienen sentido en un servidor compartido: inicio de sesión único con OIDC, un registro de auditoría de consultas y conexiones que provisiona el administrador.
También tiene un panel de IA. Genera SQL a partir de lenguaje natural, advierte antes de ejecutar consultas destructivas y explica los planes de ejecución. Funciona con Gemini, OpenAI o un modelo local vía Ollama. La IA es un panel dentro de un IDE SQL convencional, no el propósito del producto, y ninguna función de IA se activa hasta que configuras una API key.
Lo que cambió en la 0.16.0 es el árbol de esquemas. Cada motor declara ahora sus propios tipos de objeto, así que las vistas, las vistas materializadas, los diccionarios de ClickHouse, los paquetes de Oracle y las librerías de funciones de Redis aparecen con el nombre que usa cada motor. Antes, el árbol era una lista plana de tablas. Puedes abrir la definición de un objeto en una pestaña de solo lectura y, en funciones y procedimientos de PostgreSQL, también editarla y aplicarla.
¿Es gratis LibreDB Studio?
Sí. El código tiene licencia MIT y el repositorio afirma que no hay nada reservado tras un muro enterprise. SSO, RBAC, el registro de auditoría y el panel de monitoreo están todos en la versión open source. El proyecto se financia con GitHub Sponsors.
¿Qué bases de datos soporta?
A la versión 0.16 tiene proveedores propios para estos motores:
- SQL: PostgreSQL, MySQL, Oracle, SQL Server, SQLite, libSQL/Turso, DuckDB, ClickHouse
- Analítica y búsqueda: Apache Druid, Elasticsearch, OpenSearch, Trino
- Documentales y columnares: MongoDB, Couchbase, Cassandra
- Clave-valor: Redis
Más de veinte motores adicionales se conectan a través de uno de esos drivers porque hablan el mismo protocolo, como MariaDB, TiDB, Valkey, CockroachDB, TimescaleDB o YugabyteDB.
Aquí el proyecto hace algo poco habitual: prueba cada motor compatible contra una instancia real y publica un nivel de soporte (Full, Partial o Query editor only). También documenta las imprecisiones conocidas. Por ejemplo, en Citus el conteo de filas describe la tabla vacía del coordinador, no los shards. Revisa esa tabla antes de fiarte de un número en un motor compatible. La lista crece casi con cada versión, así que toma estas cifras como vigentes a la fecha de publicación de esta nota.
¿Cómo instalar LibreDB Studio con Docker o Helm?
El camino más rápido es Docker:
docker run -d -p 3000:3000 ghcr.io/libredb/libredb-studio:0.16.2
Abre http://localhost:3000. En el primer arranque, el servidor genera la contraseña de administrador y el secreto JWT, e imprime la contraseña una sola vez en el log del contenedor (docker logs <contenedor>).
La documentación del proyecto usa la etiqueta :latest. Nosotros fijamos 0.16.2 porque salieron versiones de parche el 19 y el 21 de septiembre, pocos días después de la 0.16.0, y una de ellas es una corrección de seguridad. Desde la 0.16.1, cada etiqueta se publica también en variantes -alpine y -alpine-slim. La -alpine-slim es la imagen más pequeña, pero no incluye el driver de DuckDB.
Sin Docker, puedes ejecutarlo con Node.js 20.9 o posterior:
npx @libredb/studio
En Kubernetes, fija la versión del chart:
helm repo add libredb https://libredb.org/libredb-studio/
helm repo update
helm install libredb libredb/libredb-studio --version 0.1.68
El chart 0.1.68 despliega por defecto la versión 0.16.2 de la aplicación. El README también documenta Homebrew, paquetes deb/rpm con servicio systemd, Snap y winget.
¿Cómo preparar un gestor de base de datos compartido para tu equipo?
El arranque sin configuración sirve para una prueba local, no para un equipo. Cuatro ajustes marcan la diferencia.
1. Desactiva los secretos autogenerados
Define AUTH_BOOTSTRAP=off, que es lo que el proyecto recomienda en producción. Después configura tú mismo JWT_SECRET (mínimo 32 caracteres; el README sugiere openssl rand -base64 32) y ADMIN_PASSWORD.
2. Usa SSO, no las cuentas locales
El proveedor local tiene exactamente dos cuentas: un administrador y un user opcional. Todas las personas que conocen la contraseña de user comparten esa misma identidad. La identidad por persona viene de OIDC:
NEXT_PUBLIC_AUTH_PROVIDER=oidc
OIDC_ISSUER=https://tu-proveedor.com
OIDC_CLIENT_ID=tu_client_id
OIDC_CLIENT_SECRET=tu_client_secret
OIDC_ROLE_CLAIM=realm_access.roles # opcional: asigna el rol de admin desde un claim
Funciona con cualquier proveedor OIDC, como Keycloak, Okta, Azure AD, Auth0, Zitadel o Google.
Si te quedas con las cuentas locales, la 0.16.0 agregó un segundo factor opcional: un código TOTP de 6 dígitos, que se activa por cuenta con ADMIN_TOTP_SECRET y USER_TOTP_SECRET, o con secrets.adminTotpSecret y secrets.userTotpSecret en el chart. El secreto debe ser base32 válido y decodificar a al menos 128 bits. Un valor inválido bloquea el inicio de sesión con un error que nombra la variable, en lugar de desactivar el factor en silencio.
3. Provisiona las conexiones para que nadie tenga credenciales
Un archivo YAML de seed connections define las conexiones de forma centralizada. Cada conexión se restringe por rol, y las contraseñas se inyectan desde variables de entorno con la sintaxis ${ENV_VAR}, nunca escritas en el archivo. Móntalo y apunta SEED_CONFIG_PATH a él. Las conexiones marcadas con managed: true son de solo lectura para los usuarios.
4. Elige almacenamiento persistente
El valor por defecto, STORAGE_PROVIDER=local, guarda los metadatos de conexión en el navegador de cada persona. Usa sqlite o postgres (con STORAGE_POSTGRES_URL) para guardarlos en el servidor, por usuario.
Con eso, la pestaña de auditoría del administrador registra las consultas ejecutadas desde la aplicación. Desde la 0.16.0 puedes exportarla filtrada.
¿Qué revisar antes de abrirlo a tu equipo?
En la serie 0.16 el proyecto encontró y corrigió dos fallos que solo aparecen en instancias compartidas:
- 0.16.0: en una conexión compartida, una cuenta podía revertir la transacción sin confirmar de otra cuenta. Ahora cada transacción pertenece a la cuenta que la abrió, con una concesión de cinco minutos de inactividad.
- 0.16.2: los mantenedores puntuaron con 8.8 el aviso GHSA-3wh2-8x78-jfw4. Una petición podía nombrar el identificador de conexión de otra sesión y recibir esa conexión viva, ya autenticada. Una cuenta
userpodía llegar a una conexión restringida a administradores. Las notas de la versión recomiendan actualizar si más de una cuenta accede a tu instancia.
Ambos se publicaron con todo detalle, y las reproducciones quedaron como tests. Es una buena señal sobre el proyecto, pero también te dice dónde está el riesgo: no ejecutes nada anterior a la 0.16.2 en una instancia multiusuario.
Tres límites que conviene conocer antes de pasarlo por una revisión de seguridad:
- El enmascaramiento de datos es solo del lado del cliente. El README lo dice explícitamente: las respuestas de la API siguen incluyendo los valores completos. Sirve para compartir pantalla, no para proteger datos.
- Reutilización de códigos TOTP entre réplicas. El registro de códigos usados vive en la memoria del proceso, así que con varias réplicas un código capturado puede reutilizarse una vez por cada réplica adicional. El proyecto lo documenta en
docs/SECURITY.md. - Servirlo desde una subruta exige construir tu propia imagen. Detrás de un proxy (por ejemplo, en
/tools/libredb),BASE_PATHse fija al compilar, así que la imagen publicada no se puede reubicar. Tienes que construir la tuya con el argumento de build de Docker.
¿DBeaver o LibreDB Studio?
La diferencia es de arquitectura más que de funciones.
- Un cliente de escritorio vive en la máquina de cada desarrollador, y cada persona guarda sus propias credenciales de conexión.
- LibreDB Studio es un único despliegue junto a tus bases de datos. Las personas inician sesión con tu proveedor de identidad, las credenciales se quedan en el servidor y cada consulta queda en un mismo registro de auditoría.
Ese intercambio encaja con equipos que hoy reparten contraseñas de base de datos para que la gente pueda consultar. Si buscas una DBeaver alternative para un equipo, este es el argumento.
Si trabajas solo, un cliente de escritorio no necesita servidor ni SSO. LibreDB publica ahora también una versión de escritorio para Linux (AppImage, .deb y Flatpak) que ejecuta el servidor como proceso local, sin pantalla de inicio de sesión. Su hoja de ruta pública todavía lista como pendientes, a la fecha de publicación de esta nota, los espacios de trabajo compartidos, SAML 2.0 y el enmascaramiento aplicado en el servidor.