drawDB: A Browser-Based ERD Editor and SQL Generator Under AGPL-3.0

What drawDB Solves and Who It Is For

drawDB addresses a common pain point: turning a database schema into a visual diagram and back into SQL without leaving the browser. It is an entity relationship diagram (ERD) editor that also generates SQL scripts and migrations. The intended user is a developer or data modeler who wants to sketch tables, relationships, and columns quickly, then export a ready-to-run schema. The README emphasizes that no account is required, which lowers the barrier for ad-hoc design tasks. This is not a full database management tool; it focuses on the design and generation phase, not on executing queries or managing live data.

How drawDB Works: From Diagram to SQL

The core mechanism is a visual editor where you build entities and relationships by clicking and dragging. Based on the repository layout and README, the application is a JavaScript frontend that runs entirely in the browser. When you create tables and define columns, the tool translates that model into SQL statements. It also supports importing SQL scripts, which suggests a reverse-engineering flow: you can load an existing schema, visualize it, and then modify or export it. The README mentions 'generate migrations', meaning the tool can produce ALTER statements or versioned schema changes. The data flow is straightforward: your diagram is the source of truth, and SQL is the output format. The editing state is kept in memory, and persistence is local unless you enable the optional sharing server.

Getting drawDB Running: Local, Build, and Docker

The README provides three setup paths. For local development, clone the repository, run `npm install`, then `npm run dev`. This starts a development server, presumably with hot reload. For a production build, the same clone and install steps apply, followed by `npm run build`. The Docker route is the simplest for a quick test: `docker build -t drawdb .` then `docker run -p 3000:80 drawdb`. This maps port 3000 on your host to port 80 in the container, so you access drawDB at `http://localhost:3000`. The Docker image serves the built static files via a web server, likely nginx. There is no database setup or configuration file to edit for basic use. The only optional configuration involves environment variables for the sharing server, which is a separate backend component.

The Optional Sharing Server and Its Constraints

Sharing diagrams is not built into the main repository. The README points to a separate server project, `drawdb-server`, and instructs you to set environment variables according to `.env.sample` to enable sharing. This means out of the box, drawDB is a local-only tool. If you want to send a diagram link to a colleague, you must deploy and configure an additional component. That is a real limitation for team collaboration. The sharing feature is optional, and the README says it is only needed 'if you need to share files'. For a solo developer, this is fine, but for a team evaluating drawDB, the extra infrastructure is a consideration. The absence of a built-in cloud sync or multi-user editing is a gap that competitors often fill.

Licensing: AGPL-3.0 and What It Means for You

drawDB is licensed under AGPL-3.0. This is a strong copyleft license. If you modify the code and run it as a network service, you must make your modified source available to users of that service. For internal use, this is often acceptable, but if you plan to embed drawDB in a commercial product or offer it as a hosted service, the AGPL obligations can be onerous. The README does not mention any dual licensing or commercial exceptions. This is a critical factor for engineering teams that want to integrate drawDB into a proprietary stack. You should consult a lawyer, but the general implication is that any derivative work distributed or provided over a network must be open-sourced under AGPL. This is a genuine barrier for some adoption scenarios.

Limitations and Cases Where drawDB Is the Wrong Tool

drawDB is not a database client. It does not execute queries, manage users, or handle performance tuning. It is a design-time tool. The README does not mention support for specific database vendors, so you must assume the SQL generation may not cover every dialect's quirks. For complex schemas with advanced constraints, triggers, or stored procedures, the visual editor may not offer the granularity you need. Also, the sharing feature is bolted on via a separate server, which adds operational overhead. If your workflow requires tight integration with version control, such as storing schema definitions as code and diffing them in pull requests, drawDB is not the right fit because it is primarily a GUI tool. The lack of a CLI or a file format that is easy to review in text is a limitation for teams that prefer schema-as-code practices.

Alternatives and How They Differ

A common alternative is a schema-as-code tool like Prisma or Sequelize, where you define models in code and generate migrations. These tools treat the schema as a programmatic artifact, enabling version control, automated testing, and CI/CD integration. drawDB, in contrast, treats the schema as a visual diagram. The difference is in the workflow: with drawDB you click and drag, with Prisma you write TypeScript. For developers who are comfortable writing code, a code-first approach offers more control and reproducibility. Another alternative is a desktop ERD tool like DBeaver, which connects to live databases and can reverse-engineer schemas. DBeaver is not browser-based and requires installation, but it provides a direct connection to your database, which drawDB does not. These alternatives are not drop-in replacements; they represent a different philosophy about where the schema definition lives.

Editorial conclusion

Adopt drawDB if you need a quick, no-account browser tool for designing ERDs and generating SQL for small to medium projects, especially if you prefer visual editing over writing DDL by hand. Avoid it if you require advanced collaboration, version control integration, or if AGPL-3.0 licensing conflicts with your distribution model. Before adopting, verify the current feature set on the homepage, test the SQL generation against your target database, and review the sharing server requirements if you need multi-user workflows.

Official sources

1. Official documentation
2. Official README
3. Project repository