ChartDB – Editor gratuito e open source para design de bancos de dados

• O ChartDB é um editor de diagramas de DB para visualizar rapidamente esquemas de banco de dados e manipulá-los como diagramas ER, com foco em colaboração em equipe e migração de esquemas
• O Cloud funciona no navegador e afirma permitir obter um diagrama em 15 segundos sem acesso ao banco de dados
• O Self-Hosted é oferecido como software gratuito e open source, adequado a necessidades de segurança e personalização em que é preciso controlar diretamente dados e configurações
• Oferece suporte a importação de esquema baseada em uma única query, geração de diagramas ER com IA, exportação de SQL DDL, sincronização automática, colaboração em tempo real, documentação incorporável e rastreamento de alterações
• Pode ser usado no design de vários SGBDs relacionais e data warehouses em nuvem, incluindo PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake e BigQuery

---

Diagramas de esquemas de DB no navegador

• O ChartDB é uma ferramenta para visualizar instantaneamente esquemas de banco de dados e gerar diagramas ER
• É apresentado como um editor de diagramas de DB usado para colaboração em equipe e migração de esquemas
• O botão de início leva ao app do ChartDB, acompanhado das mensagens de começar gratuitamente e de que não é necessário cartão de crédito
• No GitHub, o ChartDB aparece com +19K stars

Opções Cloud e Self-Hosted

• O ChartDB Cloud é uma forma de visualizar bancos de dados no navegador
  • É apresentado como adequado para facilidade de uso e acessibilidade para equipes
  • É indicado que pode ser usado sem acesso ao banco de dados
  • Afirma permitir obter um diagrama em 15 segundos
• O Self-Hosted é um editor gratuito e open source para design de bancos de dados
  • Permite controlar totalmente dados e configurações
  • É uma opção adequada para ambientes que exigem segurança e personalização
• O ChartDB explica que é possível visualizar um DB com uma “única query”

Fluxo de trabalho Import → Edit → Export

• Instant Import

  • Fornece uma única query para importar o esquema completo de cada banco de dados
  • A importação do esquema é indicada como possível em até 15 segundos

• Relational DBMS

  • Menciona MySQL, MariaDB, PostgreSQL, Microsoft SQL Server e SQLite como SGBDs populares e os marca como suportados

• Export SQL

  • Permite baixar o diagrama como scripts SQL DDL para executar no banco de dados
  • Também permite exportar como imagem para inserir em documentos

• Examples

  • Oferece exemplos pré-projetados para configuração rápida e referência de design
  • Esse item aparece marcado como WIP

• Advanced Query Editor

  • Oferece funções de desfazer, refazer, copiar, colar e duplicar
  • Permite adicionar tabelas, áreas temáticas e notas

• Beautiful Shares

  • Gera uma pré-visualização visual de diagramas de banco de dados para compartilhar com outras pessoas

Recursos de geração, compartilhamento e sincronização de diagramas

• ChartDB - AI Agent
  • Converte a ideia de banco de dados inserida no prompt em um diagrama ER otimizado e editável
• Instant Import
  • Recurso para importar todo o esquema do DB com uma única query
• Export SQL
  • Gera scripts DDL no dialeto SQL desejado
• Sync Database
  • Sincroniza automaticamente o banco de dados em produção com o diagrama
• Real time collaboration
  • Permite convidar membros da equipe para visualizar e editar diagramas em tempo real
• Amazing Docs
  • Gera diagramas incorporáveis e documentação expansível personalizável
• Keep on track
  • Rastreia diffs e histórico de versões das alterações de esquema

Bancos de dados suportados

• O ChartDB informa que oferece suporte a design para bancos de dados e data warehouses em nuvem
• Os itens indicados como suportados são os seguintes
  • PostgreSQL
  • MySQL
  • SQL Server
  • SQLite
  • MariaDB
  • ClickHouse
  • CockroachDB
  • Oracle
  • Snowflake
  • BigQuery

Perguntas operacionais presentes no FAQ

• Inclui uma pergunta sobre se o ChartDB modifica o banco de dados
• Há um item perguntando se é possível incorporar um ERD ao vivo no Notion, Miro e Confluence
• Há um item verificando se é possível testar gratuitamente o plano ChartDB Cloud
• Como receber suporte, como sincronizar diagramas e bancos de dados, e se há emissão de faturas e pagamentos empresariais também aparecem como itens do FAQ

[GN⁺]

Opiniões no Hacker News

• Já vi com frequência equipes de projeto mergulharem no desenvolvimento de uma nova aplicação sem nenhum diagrama básico que explique qualquer aspecto da solução, incluindo o modelo de dados.
  Não sei o que seria necessário para que um simples diagrama ER virasse padrão na documentação de projetos. Existem muitas ferramentas relacionadas, mas, na prática, quase não são usadas.
  Talvez, para as pessoas usarem, a Microsoft precise colocar isso como um recurso do Excel ou do PowerPoint. O diagrama não precisa ser completo; basta comunicar as estruturas e relações principais dentro do contexto. Se necessário, dá para criar vários diagramas pequenos para o mesmo banco de dados a fim de documentar requisitos e design.

  • Consigo pensar em alguns motivos. Pessoas com formação em sistemas de informação gerencial (MIS) normalmente se interessam mais por bancos de dados do que as de ciência da computação (CS), e tendem a começar pelo ERD para depois ir para o código. O pessoal de CS costuma querer codar primeiro.
    Além disso, UML foi quase um desastre. Desde os anos 90, ela se firmou como a linguagem de diagramas representativa, mas não tinha componentes de banco de dados, e era preciso adaptar diagramas de classes para usá-los como ERD. UML não é código, e programar em UML é difícil ou quase impossível. Com ERD, é muito mais fácil ir e voltar entre código e diagrama, mas isso não acontece em outros tipos de programação.
    Acho que a ascensão e o fracasso da UML tiveram um papel grande em fazer desenvolvedores pararem de desenhar diagramas. Além disso, para a maioria dos desenvolvedores, uma ferramenta de navegação de código que mostra a estrutura do código em árvore no painel esquerdo do editor já é suficiente.
  • Concordo, porque sou do tipo que olha primeiro para os dados ao entender um sistema, mas sinto que não somos maioria. Pelo menos no ecossistema Microsoft, o crescimento da abordagem code first não foi algo de que eu tenha gostado pessoalmente.

• Antigamente eu era bem favorável a criar ERDs, e os usava com frequência como tarefa de onboarding até em bancos de dados com mais de 100 tabelas. Mas ERDs abrangentes estão ficando cada vez mais raros, e acho que tudo bem.
  O custo de manutenção é alto, então o valor não dura muito. É bom ter um ERD bem lapidado, mas não é indispensável.
  Para transformar ERD em código, ferramentas como dbdiagram.io ou eraser.io são bastante usadas. O ERWin é meio que um dos originais dos diagramas UML/ERD, mas é caro.

  • Fazer esse tipo de coisa à mão beira o erro. Como você disse, é difícil de manter. Acho que todo banco de dados deveria gerar diagramas automaticamente, ou pelo menos ter uma ferramenta de geração automática.

• Fico curioso sobre por que as pessoas usam ferramentas assim. É para conversar com gestores?
  Pergunto sinceramente. Talvez eu também devesse usar, mas ainda não sei por que preciso disso.

  • Você deve usar quando a complexidade chega a um ponto em que isso passa a fazer sentido. Se o projeto amadureceu e você não tem, ou não quer ter, o modelo de banco de dados inteiro na cabeça, deve usar.
    Também é necessário quando há vários modelos em sistemas diferentes, quando você trabalha com outras pessoas e quer facilitar a comunicação sobre o modelo de banco de dados, quando precisa explicá-lo publicamente ou quando quer planejar o modelo com antecedência.
    Aqui, “deve usar” se refere ao diagrama final, não necessariamente a esta ferramenta específica.
  • Já usei ferramentas assim para organizar um design que estava na minha cabeça. Pessoalmente gosto de DBML, porque é fácil colocar em controle de versão e também há plugins para editores.
    https://dbml.dbdiagram.io/home/
  • Pelo motivo de que “uma imagem vale mais que mil palavras”.
    Se você já recebeu um projeto com 80 tabelas sem documentação, ou no máximo um documento de 50 páginas contendo um dump do schema do banco de dados, consegue entender.
    Dá para desenhar as tabelas e relações principais em um único ERD (diagrama entidade-relacionamento), e entendê-las em minutos, em vez de horas ou dias como em um dump de schema.
    Na etapa de design do schema, é possível usar vários editores de ERD ou ferramentas de diagramação baseadas em texto, como PlantUML, MermaidJS e DBML, e também colocar a fonte do diagrama no controle de versão.
    Além disso, se um ERD detalhado do schema atual do banco de dados for gerado na CI e revisado periodicamente, dá para verificar se ele bate com o design original e se o schema atual está sendo entendido corretamente.
  • Fica muito mais fácil se comunicar com pessoas da área de negócios e explicar restrições técnicas ou requisitos de dados. Também ajuda no design colaborativo em projetos complexos e deixa claro onde não estamos atendendo aos requisitos de dados.
  • Assim como documentação no estilo JavaDoc, oferece uma perspectiva mais concisa de como algo funciona.
    Eu realmente detesto a atitude de “o código já se explica sozinho!”.

• Vejo muitos serviços parecidos. Mas o que procuro é uma ferramenta que eu possa usar diretamente ou controlar por script.
  Meu caso de uso é gerar diagramas de banco de dados relativamente simples a partir de uma descrição de modelo que tenho como parte de outro processo. Tenho nomes de tabelas, nomes de colunas e relações dentro de uma estrutura em memória, e quero desenhar um diagrama meio ER.
  No momento estou considerando gerar arquivos puml com meus dados e depois executar o PlantUML para criar png ou svg.
  Quando procuro, a maioria são ferramentas completas de design de banco de dados com editor próprio, mas sem API; e ferramentas como esta ou o dbdiagram.io normalmente são apenas online, então não são uma opção para mim. Se alguém tiver recomendações, eu ficaria muito agradecido.

  • Fico curioso se você já testou o SchemaSpy.

• Eu queria que isso existisse há 5 anos, quando começamos um projeto. Em um projeto full-stack usando Postgres, precisei desenhar o schema do banco de dados e trabalhei com um especialista de uma área científica.
  Foi muito útil revisar o diagrama em conjunto, porque esse especialista conseguia encontrar problemas causados por requisitos específicos do domínio que poderiam surgir no futuro.
  Nesse processo fizemos muitas reuniões individuais, e eu anotava, olhando o diagrama, o que deveria ser alterado antes da próxima reunião.
  Se uma ferramenta dessas existisse, poderíamos ter feito as alterações diretamente durante as reuniões e reduzido bastante as iterações. Havia coisas como o pgAdmin, mas elas não pareciam amigáveis para pessoas não técnicas; esta ferramenta provavelmente reduziria esse atrito.

• Legal, mas o principal problema de ferramentas assim é que elas são unidirecionais e tentam se colocar como a autoridade central. Só que isso é um desenho, não o banco de dados.
  Entendo por que as pessoas usam, mas eu não preciso de uma ferramenta dessas.
  Por isso todas as ferramentas oferecem “exportar para SQL” e esperam que todas as mudanças no banco de dados sejam refletidas no diagrama. Mas o diagrama não é o banco de dados; agora você tem dois trabalhos.

  • Dizer que “o diagrama não é o banco de dados” é como dizer que “o mapa não é o território”.
    O diagrama é um modelo, e o modelo sempre existe, seja explícito ou apenas na cabeça.
    Um modelo mental pode estar errado, mas ninguém consegue vê-lo, então ninguém pode apontar os erros. Nem a própria pessoa.

• O DBeaver também oferece suporte a ERD: https://dbeaver.com/docs/dbeaver/ER-Diagrams/
  É interativo e editável. Não dá para chamar de “bonito”, mas o produto inteiro é FOSS e é extremamente útil para trabalhar com bancos de dados.

  • Tive bastante dificuldade para fazer o ERD no DBeaver funcionar do jeito que eu queria. Para alguém como eu, tudo bem: eu posso ficar mexendo até funcionar.
    Mas não era assim para algumas pessoas com quem trabalhei. Normalmente, o momento em que você precisa desse tipo de coisa é quando está colaborando no design com pessoas que não são familiarizadas com SQL, mas têm conhecimento de domínio e chegam trazendo uma planilha do Excel do tamanho de um pequeno banco de dados.

• Não entendo por que uma landing page estática tem tanta travada ao rolar a página.