LibreDB Studio: cliente de banco de dados open source no seu servidor
Trabalho na equipe que desenvolve o LibreDB Studio e venho apresentar o projeto aqui, com
os números que nós mesmos medimos e também com o que não funcionou.
É um cliente de banco de dados de código aberto, licença MIT, que roda no seu próprio
servidor. Não existe versão paga e não hospedamos nada: a ferramenta sobe como container
dentro da mesma rede do banco e as pessoas acessam pelo navegador. O banco não precisa
abrir porta para fora.
Para subir, basta um comando:
docker run -d -p 3000:3000 ghcr.io/libredb/libredb-studio:0.17.0
No primeiro start ele cria a conta de administrador e escreve a senha no log do container.
Se preferir definir você mesmo, passe ADMIN_PASSWORD como variável de ambiente.
Sobre a compatibilidade, que é onde quero ser honesto. Temos dezoito drivers próprios:
PostgreSQL, MySQL, SQLite, libSQL, DuckDB, Oracle, SQL Server, ClickHouse, Druid, Trino,
Cassandra, Elasticsearch, OpenSearch, MongoDB, Couchbase, Redis, Prometheus e Kafka. Além
deles, vinte e oito motores falam o protocolo de algum desses e conectam pelo driver que
já existe: MariaDB, TiDB, Citus, TimescaleDB, YugabyteDB, CockroachDB, Valkey, KeyDB,
DragonflyDB, ScyllaDB, FerretDB, Redpanda e outros. Dezoito mais vinte e oito dá quarenta
e seis.
Só que protocolo igual não significa catálogo igual. Um cliente não apenas conecta: ele lê
a lista de tabelas, contagem de linhas e tamanho, índices, plano de execução e sessões, e
tudo isso vem do catálogo do sistema de cada motor. A conexão passa, a tela abre e vem
vazia.
Então subimos os vinte e oito no Docker e passamos as mesmas quinze telas em cada um.
Dezoito responderam em todas. Nove responderam em parte. Em um, só o editor de consultas
funcionava.
Duas coisas que aprendi nesse caminho: o StarRocks devolve zero para tamanho de tabela e
número de linhas de forma consistente, enquanto o Doris, do qual ele descende, devolve os
valores reais no mesmo lugar. E alguns motores devolvem zero por um tempo depois de
inserir dados, não por defeito, mas porque o coletor de estatísticas é lento. Marcamos um
motor saudável como quebrado exatamente por isso e só percebemos na segunda rodada.
Cinco dos dezoito drivers são somente leitura por decisão de projeto: Druid,
Elasticsearch, OpenSearch, Prometheus e Kafka. Preferimos dizer isso em vez de listar como
suporte completo.
O código está público: https://github.com/libredb/libredb-studio
Se alguém aqui usar um motor que não medimos bem, prefiro saber que falhou a não saber de
nada.
os números que nós mesmos medimos e também com o que não funcionou.
É um cliente de banco de dados de código aberto, licença MIT, que roda no seu próprio
servidor. Não existe versão paga e não hospedamos nada: a ferramenta sobe como container
dentro da mesma rede do banco e as pessoas acessam pelo navegador. O banco não precisa
abrir porta para fora.
Para subir, basta um comando:
docker run -d -p 3000:3000 ghcr.io/libredb/libredb-studio:0.17.0
No primeiro start ele cria a conta de administrador e escreve a senha no log do container.
Se preferir definir você mesmo, passe ADMIN_PASSWORD como variável de ambiente.
Sobre a compatibilidade, que é onde quero ser honesto. Temos dezoito drivers próprios:
PostgreSQL, MySQL, SQLite, libSQL, DuckDB, Oracle, SQL Server, ClickHouse, Druid, Trino,
Cassandra, Elasticsearch, OpenSearch, MongoDB, Couchbase, Redis, Prometheus e Kafka. Além
deles, vinte e oito motores falam o protocolo de algum desses e conectam pelo driver que
já existe: MariaDB, TiDB, Citus, TimescaleDB, YugabyteDB, CockroachDB, Valkey, KeyDB,
DragonflyDB, ScyllaDB, FerretDB, Redpanda e outros. Dezoito mais vinte e oito dá quarenta
e seis.
Só que protocolo igual não significa catálogo igual. Um cliente não apenas conecta: ele lê
a lista de tabelas, contagem de linhas e tamanho, índices, plano de execução e sessões, e
tudo isso vem do catálogo do sistema de cada motor. A conexão passa, a tela abre e vem
vazia.
Então subimos os vinte e oito no Docker e passamos as mesmas quinze telas em cada um.
Dezoito responderam em todas. Nove responderam em parte. Em um, só o editor de consultas
funcionava.
Duas coisas que aprendi nesse caminho: o StarRocks devolve zero para tamanho de tabela e
número de linhas de forma consistente, enquanto o Doris, do qual ele descende, devolve os
valores reais no mesmo lugar. E alguns motores devolvem zero por um tempo depois de
inserir dados, não por defeito, mas porque o coletor de estatísticas é lento. Marcamos um
motor saudável como quebrado exatamente por isso e só percebemos na segunda rodada.
Cinco dos dezoito drivers são somente leitura por decisão de projeto: Druid,
Elasticsearch, OpenSearch, Prometheus e Kafka. Preferimos dizer isso em vez de listar como
suporte completo.
O código está público: https://github.com/libredb/libredb-studio
Se alguém aqui usar um motor que não medimos bem, prefiro saber que falhou a não saber de
nada.
Entre ou Registre-se para fazer um comentário.