ChartDB – editor gratuito y de código abierto para diseñar bases de datos

• ChartDB es un editor de diagramas de BD para visualizar rápidamente esquemas de bases de datos y trabajar con ellos como diagramas ER, con foco en la colaboración en equipo y las migraciones de esquema
• Cloud funciona en el navegador y destaca que permite obtener un diagrama en 15 segundos sin acceso a la base de datos
• Self-Hosted se ofrece como una opción gratuita y de código abierto, pensada para necesidades de seguridad y personalización donde se requiere controlar directamente los datos y la configuración
• Soporta importación de esquema con una sola consulta, generación de diagramas ER con IA, exportación de SQL DDL, sincronización automática, colaboración en tiempo real, documentación embebible y seguimiento de cambios
• Puede usarse para diseñar múltiples DBMS relacionales y data warehouses en la nube, incluidos PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake y BigQuery

---

Diagramas de esquemas de BD en el navegador

• ChartDB es una herramienta que visualiza al instante esquemas de bases de datos y genera diagramas ER
• Se presenta como un editor de diagramas de BD para colaboración en equipo y migraciones de esquema
• El botón de inicio enlaza a la app de ChartDB y aparece junto al mensaje de inicio gratuito y sin necesidad de tarjeta de crédito
• En GitHub, ChartDB aparece con +19K stars

Opciones Cloud y Self-Hosted

• ChartDB Cloud es una forma de visualizar bases de datos en el navegador
  • Se describe como adecuada por su facilidad de uso y accesibilidad para equipos
  • Indica que puede usarse sin acceso a la base de datos
  • Destaca que permite obtener un diagrama en 15 segundos
• Self-Hosted es un editor gratuito y de código abierto para diseñar bases de datos
  • Permite controlar por completo los datos y la configuración
  • Es una opción pensada para entornos que requieren seguridad y personalización
• ChartDB explica que puede visualizar una BD con “una sola consulta”

Flujo de trabajo Import → Edit → Export

• Instant Import

  • Proporciona una sola consulta para importar el esquema completo de cada base de datos
  • Indica que la importación del esquema puede hacerse en 15 segundos

• Relational DBMS

  • Menciona MySQL, MariaDB, PostgreSQL, Microsoft SQL Server y SQLite como DBMS populares y los muestra como compatibles

• Export SQL

  • Permite descargar el diagrama como un script SQL DDL para ejecutarlo en la base de datos
  • También puede exportarse como imagen para incluirla en documentación

• Examples

  • Ofrece ejemplos prediseñados para configuración rápida y referencia de diseño
  • Ese apartado aparece marcado como WIP

• Advanced Query Editor

  • Incluye funciones de deshacer, rehacer, copiar, pegar y duplicar
  • Permite agregar tablas, áreas temáticas y notas

• Beautiful Shares

  • Permite generar vistas previas visuales de diagramas de bases de datos para compartirlas con otras personas

Funciones para crear, compartir y sincronizar diagramas

• ChartDB - AI Agent
  • Convierte una idea de base de datos escrita en un prompt en un diagrama ER optimizado y editable
• Instant Import
  • Función para importar el esquema completo de una BD con una sola consulta
• Export SQL
  • Genera scripts DDL en el dialecto SQL que se desee
• Sync Database
  • Sincroniza automáticamente la base de datos en vivo con el diagrama
• Real time collaboration
  • Permite invitar a miembros del equipo para ver y editar diagramas en tiempo real
• Amazing Docs
  • Genera diagramas embebibles y documentación expandible personalizable
• Keep on track
  • Hace seguimiento de los diff de cambios de esquema y del historial de versiones

Bases de datos compatibles

• ChartDB indica que soporta diseño para bases de datos y data warehouses en la nube
• Los elementos que aparecen como compatibles son los siguientes
  • PostgreSQL
  • MySQL
  • SQL Server
  • SQLite
  • MariaDB
  • ClickHouse
  • CockroachDB
  • Oracle
  • Snowflake
  • BigQuery

Preguntas operativas que pueden revisarse en el FAQ

• Incluye una pregunta sobre si ChartDB modifica la base de datos
• Hay un apartado que pregunta si se puede embeber un ERD en vivo en Notion, Miro y Confluence
• También aparece una pregunta para verificar si puede probarse gratis el plan Cloud de ChartDB
• El FAQ también incluye cómo obtener soporte, cómo sincronizar diagramas y bases de datos, y si ofrecen facturas y pagos para empresas

[GN⁺]

Opiniones de Hacker News

• He visto muchas veces que equipos de proyecto se lanzan a desarrollar una aplicación nueva sin ningún diagrama básico que describa algún aspecto de la solución, incluido el modelo de datos.
  No sé qué haría falta para que un diagrama ER simple se vuelva estándar en la documentación de proyectos. Hay muchas herramientas relacionadas, pero en la práctica casi no se usan.
  Quizá, para que la gente los use, Microsoft tendría que incorporarlos como una función de Excel o PowerPoint. Los diagramas no tienen que ser completos; basta con que comuniquen la estructura y las relaciones clave en su contexto. Si hace falta, se pueden crear varios diagramas pequeños para la misma base de datos y así documentar requisitos y diseño.

  • Se me ocurren algunas razones. Las personas con formación en sistemas de información gerencial (MIS) suelen interesarse más por las bases de datos que quienes vienen de ciencias de la computación (CS), y tienden a empezar con un ERD para luego pasar al código. La gente de CS suele querer programar primero.
    Además, UML fue casi un desastre. Desde los 90 se instaló como el lenguaje de diagramas representativo, pero no tenía componentes de base de datos, y había que adaptar los diagramas de clases para usarlos como ERD. UML no es código, y programar con UML también es difícil o casi imposible. Con un ERD es mucho más fácil ir y venir entre código y diagrama, algo que no ocurre con otros tipos de programación.
    Creo que el auge y el fracaso de UML tuvieron un papel importante en que los desarrolladores dejaran de hacer diagramas. Además, para la mayoría de los desarrolladores alcanza con las herramientas de navegación de código que muestran la estructura del código como un árbol en el panel izquierdo del editor.
  • Estoy de acuerdo, porque soy de los que empiezan mirando los datos para entender un sistema, pero siento que no somos mayoría. Al menos en el ecosistema de Microsoft, personalmente no me alegró que creciera el enfoque code-first.

• Antes era bastante partidario de crear ERD, y los usaba a menudo como tarea de onboarding incluso en bases de datos con más de 100 tablas. Pero los ERD completos son cada vez menos comunes, y me parece bien.
  Tienen un costo de mantenimiento alto, así que su valor no dura mucho. Está bueno tener un ERD bien pulido, pero no es indispensable.
  Para crear ERD a partir de código se usan mucho herramientas como dbdiagram.io o eraser.io. ERWin es algo así como el precursor de los diagramas UML/ERD, pero es caro.

  • Hacer este tipo de cosas a mano es casi un error. Como dices, es difícil de mantener. Creo que toda base de datos debería poder generar automáticamente diagramas, o al menos contar con una herramienta para generarlos automáticamente.

• Me da curiosidad por qué la gente usa herramientas así. ¿Es para hablar con gerentes?
  Lo pregunto en serio. Tal vez yo también debería usarlas, pero todavía no entiendo para qué las necesito.

  • Hay que usarlas cuando la complejidad llega a un punto en que empiezan a tener sentido. Si el proyecto ya maduró y no tienes, o no quieres tener, todo el modelo de base de datos en la cabeza, deberías usarlas.
    También son necesarias si tienes varios modelos en distintos sistemas, si trabajas con otras personas y quieres facilitar la comunicación sobre el modelo de base de datos, si tienes que explicarlo públicamente o si quieres planificar el modelo por adelantado.
    Con “usarlas” me refiero al diagrama final, no necesariamente a esta herramienta en particular.
  • He usado herramientas de este tipo para ordenar un diseño que tenía en la cabeza. Personalmente me gusta DBML, porque es fácil meterlo en control de código fuente y también hay plugins para editores.
    https://dbml.dbdiagram.io/home/
  • Por aquello de que “una imagen vale más que mil palabras”.
    Si alguna vez recibiste un proyecto con 80 tablas sin documentación, o como mucho un documento de 50 páginas con un volcado del esquema de la base de datos, lo vas a entender.
    Puedes dibujar las tablas y relaciones principales en un solo ERD (diagrama entidad-relación), y entenderlo en minutos, no en horas o días como con un volcado de esquema.
    En la etapa de diseño del esquema puedes usar varios editores de ERD o herramientas de diagramas basadas en texto como PlantUML, MermaidJS o DBML, y también guardar el código fuente del diagrama en control de versiones.
    Además, si generas en CI un ERD detallado del esquema actual de la base de datos y lo revisas periódicamente, puedes comprobar si coincide con el diseño original y si realmente entiendes el esquema actual.
  • Se vuelve mucho más fácil comunicarse con la gente de negocio y explicar restricciones técnicas o requisitos de datos. También ayuda al diseño colaborativo en proyectos complejos, y deja claro dónde no estamos cumpliendo los requisitos de datos.
  • Igual que documentación tipo JavaDoc, ofrece una perspectiva más concisa de cómo funciona algo.
    De verdad detesto la actitud de “¡el código se explica solo!”.

• Veo muchos servicios parecidos. Pero lo que busco es una herramienta que pueda usar directamente o controlar mediante scripts.
  Mi caso de uso es generar diagramas de base de datos relativamente simples a partir de una descripción de modelo que tengo como parte de otro proceso. Tengo nombres de tablas, nombres de columnas y relaciones dentro de una estructura en memoria, y quiero dibujar un diagrama parecido a un ER.
  Actualmente estoy viendo la opción de generar archivos puml con mis datos y luego ejecutar PlantUML para producir png o svg.
  Por lo que he encontrado, la mayoría son herramientas completas de diseño de bases de datos con su propio editor pero sin API, y herramientas como esta o dbdiagram.io suelen ser solo online, así que no son una opción para mí. Si alguien tiene recomendaciones, se agradecerían mucho.

  • Me pregunto si has probado SchemaSpy.

• Me habría gustado que esto existiera hace 5 años, cuando empecé un proyecto. Tenía que diseñar el esquema de la base de datos para un proyecto full-stack con Postgres, y trabajaba con un experto de un área científica.
  Revisar juntos los diagramas fue de gran ayuda, porque ese experto podía detectar problemas que podrían surgir por requisitos específicos del dominio en el futuro.
  En ese proceso tuvimos muchas reuniones uno a uno, y yo tomaba nota, mirando el diagrama, de lo que debía cambiar antes de la siguiente reunión.
  Si hubiera tenido una herramienta así, habría podido hacer cambios directamente durante las reuniones y reducir mucho las iteraciones. Existían cosas como pgAdmin, pero no parecían amigables para una persona no técnica; una herramienta como esta podría reducir la fricción.

• Está genial, pero el principal problema de estas herramientas es que son unidireccionales y tratan de convertirse en la autoridad central. Pero esto es un dibujo, no la base de datos.
  Entiendo por qué la gente las usa, pero yo no necesito herramientas así.
  Por eso todas ofrecen “exportar a SQL” y esperan que todos los cambios en la base de datos se reflejen en el diagrama. Pero el diagrama no es la base de datos, así que ahora tienes dos trabajos.

  • Decir “el diagrama no es la base de datos” es como decir “el mapa no es el territorio”.
    El diagrama es un modelo, y el modelo siempre existe, ya sea explícito o solo en la cabeza.
    El modelo mental puede estar equivocado, pero nadie puede verlo para señalar errores. Ni siquiera uno mismo.

• DBeaver también admite ERD: https://dbeaver.com/docs/dbeaver/ER-Diagrams/
  Es interactivo y se puede modificar. Es difícil decir que sea “bonito”, pero todo el producto es FOSS y resulta tremendamente útil para trabajar con bases de datos.

  • Tuve bastantes problemas para hacer que los ERD en DBeaver funcionaran como quería. Para alguien como yo está bien, porque puedo toquetear hasta que salga.
    Pero no fue así para algunas personas con las que trabajé. Normalmente, cuando necesitas algo así es al colaborar en el diseño con personas que no están cómodas con SQL, pero sí tienen conocimiento del dominio y llegan con una hoja de cálculo de Excel del tamaño de una base de datos pequeña.

• No entiendo por qué una landing page estática tiene tanto tironeo al hacer scroll