libredb
Curioso
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Escribo esto porque es un montaje que repito en cada proyecto y casi nunca lo veo explicado completo. El problema es viejo: cada persona del equipo instala su cliente de base de datos en su portátil, y para que eso funcione la base acaba con el puerto abierto hacia fuera. Cuantos más portátiles, más caminos hacia la base.
La alternativa es poner el cliente dentro de la red donde ya vive la base, en un contenedor, y que las personas entren por el navegador. La base no abre ningún puerto al exterior.
Montaje mínimo con Docker
docker run -d --name dbclient -p 3000:3000 ghcr.io/libredb/libredb-studio:0.17.0
En el primer arranque se crea la cuenta de administrador y la contraseña se escribe en el log del contenedor. Si prefieres fijarla tú, pásala como variable de entorno ADMIN_PASSWORD antes de levantar el contenedor.
Si la base también corre en Docker, lo importante es que los dos contenedores compartan red, y entonces el servidor de base de datos se llama por el nombre del contenedor, no por localhost:
docker network create interna
docker network connect interna dbclient
Lo que de verdad conviene configurar
Marca la conexión como solo lectura cuando se la des a alguien que únicamente consulta. En una herramienta seria esa marca no es un aviso visual: rechaza la escritura antes de que la consulta salga hacia el motor.
Una advertencia que me costó tiempo
Al elegir herramienta vas a leer listas largas de motores compatibles. Ojo con eso, porque compatible de protocolo no es lo mismo que compatible de verdad. Muchos motores hablan el protocolo de otro: TiDB habla MySQL, Citus y TimescaleDB hablan PostgreSQL, Valkey habla Redis. La conexión entra sin problema. Pero un cliente no solo conecta: lee el catálogo del sistema para mostrarte tablas, tamaños, índices, planes y sesiones, y ese catálogo sí cambia de un motor a otro. Resultado: conectas, abres la vista y está vacía.
Nosotros levantamos veintiocho motores en Docker y pasamos las mismas quince pantallas en cada uno. Dieciocho respondieron en todas, nueve solo en parte, y en uno funcionaba únicamente el editor de consultas. Dos detalles que no esperaba: StarRocks devuelve cero en tamaño y número de filas de forma estable, mientras que Doris, del que desciende, sí devuelve los valores reales; y algunos motores devuelven cero durante un rato después de insertar datos porque el recolector de estadísticas va lento, cosa que nos hizo marcar como defectuoso un motor que estaba sano.
Si vas a probar esto, la fuente que uso es LibreDB Studio, licencia MIT y código público: https://github.com/libredb/libredb-studio
Si alguien tiene un montaje distinto para el mismo problema, me interesa leerlo.
La alternativa es poner el cliente dentro de la red donde ya vive la base, en un contenedor, y que las personas entren por el navegador. La base no abre ningún puerto al exterior.
Montaje mínimo con Docker
docker run -d --name dbclient -p 3000:3000 ghcr.io/libredb/libredb-studio:0.17.0
En el primer arranque se crea la cuenta de administrador y la contraseña se escribe en el log del contenedor. Si prefieres fijarla tú, pásala como variable de entorno ADMIN_PASSWORD antes de levantar el contenedor.
Si la base también corre en Docker, lo importante es que los dos contenedores compartan red, y entonces el servidor de base de datos se llama por el nombre del contenedor, no por localhost:
docker network create interna
docker network connect interna dbclient
Lo que de verdad conviene configurar
Marca la conexión como solo lectura cuando se la des a alguien que únicamente consulta. En una herramienta seria esa marca no es un aviso visual: rechaza la escritura antes de que la consulta salga hacia el motor.
Una advertencia que me costó tiempo
Al elegir herramienta vas a leer listas largas de motores compatibles. Ojo con eso, porque compatible de protocolo no es lo mismo que compatible de verdad. Muchos motores hablan el protocolo de otro: TiDB habla MySQL, Citus y TimescaleDB hablan PostgreSQL, Valkey habla Redis. La conexión entra sin problema. Pero un cliente no solo conecta: lee el catálogo del sistema para mostrarte tablas, tamaños, índices, planes y sesiones, y ese catálogo sí cambia de un motor a otro. Resultado: conectas, abres la vista y está vacía.
Nosotros levantamos veintiocho motores en Docker y pasamos las mismas quince pantallas en cada uno. Dieciocho respondieron en todas, nueve solo en parte, y en uno funcionaba únicamente el editor de consultas. Dos detalles que no esperaba: StarRocks devuelve cero en tamaño y número de filas de forma estable, mientras que Doris, del que desciende, sí devuelve los valores reales; y algunos motores devuelven cero durante un rato después de insertar datos porque el recolector de estadísticas va lento, cosa que nos hizo marcar como defectuoso un motor que estaba sano.
Si vas a probar esto, la fuente que uso es LibreDB Studio, licencia MIT y código público: https://github.com/libredb/libredb-studio
Si alguien tiene un montaje distinto para el mismo problema, me interesa leerlo.
