drawDB：在浏览器里画数据库 ER 图并直接生成 SQL

drawDB 值得用吗

如果你的工作流里存在"先画出表结构、再落到建表语句"这一环，drawDB 把这条路压到了三步：打开网页，拖几张表，复制 DDL。不用注册，不用装客户端，数据留在浏览器里。免费的编辑器支持 MySQL、PostgreSQL、SQLite、MariaDB、SQL Server、Oracle 等七种方言的导出，还能比较两个设计版本、生成表结构变更的迁移脚本。

它不打算替代重型建模工具，恰恰相反——它把自己限制在"从想法到可执行 SQL"这一段。这个边界决定了它的长短：轻场景里它几乎零成本；超大库建模、多人实时协同这类需求，它要么吃力、要么要换付费产品，文末的适用边界会展开。

这篇文章按一条路径往下走：先看懂它定位在哪、能力有哪些，再用一个"用户-订单"的例子把"画图 → 建表 → 生成迁移"完整串一遍，最后给自托管方式和选型建议。读完你既能立刻上手，也知道哪些坑要绕开。

功能别背，拆成一条主线和两条支线

drawDB 的功能如果平铺成清单会显得又多又散。拆成一条主线和两条支线更好记：

主线决定"从想法到 SQL 的最快路径"，两条支线分别解决"既有库怎么读明白"和"用完怎么不把设计泄露出去"。下面逐条展开。

主线：画图到 SQL，为什么能一站到底

可视化建表，先有"为什么"

很多建模工具要你先记字段类型的语法细节，drawDB 把这一步图形化：在画布上放一张表卡片，逐个加字段，定义名称、类型、约束（NOT NULL、UNIQUE、主键、自增），还能配默认值、CHECK 表达式和注释，这些都会跟着进导出语句。表之外，画布上还放得下另外几类对象：自定义类型、枚举、视图、备注便签和主题区域。

拖拽只是表象，真正值钱的是设计与实现解耦：你只负责说清"这张表有哪些列、什么约束"，具体方言的语法交给导出器处理。表格卡片以 DOM 节点渲染在无限画布上，表多了可以按主题区域归组、加备注说明，评审时一眼能看出模块边界。

多方言导出：一件事，为什么配七种语法

同一个设计，落到不同数据库，自增和类型的写法完全不同：PostgreSQL 用 GENERATED ... AS IDENTITY，MySQL 用 AUTO_INCREMENT，SQLite 的 ALTER TABLE 支持很受限。如果设计工具只认一种方言，换个库就得重画，这个成本往往被低估。

drawDB 支持七种方言：MySQL、PostgreSQL、SQLite、MariaDB、SQL Server、Oracle（官方标注 Beta）和一个跨库建模用的 Generic 通用模式，每种方言在源码里各对应一个独立导出器。画布上的设计是"通用层"，导出时才翻译成所选方言的 DDL——设计一次，换库不重画。

除 SQL 外，同一张图还能导出成 DBML（Database Markup Language，一种数据库无关的建模标记语言，可再导回）、Mermaid 图和 Markdown 格式的数据字典，JSON 则是它的原生保存格式。

迁移脚本：比较两个版本，生成 up 和 down

结构总在变。drawDB 的迁移面板比较的不是内存里的前后状态，而是已经保存到 Gist 的两个设计版本：把图分享出去后（走 GitHub 私密 Gist，见下文自托管一节），每次保存都会留下一个版本；在迁移面板里任选两个版本，工具会忽略坐标、颜色这类视觉字段，只对结构差异生成迁移 SQL——而且 up 和 down 各一份，升级能执行，回滚也有语句，可以打包下载。

这个设计意味着一件事：想在设计阶段管理版本和迁移，需要先开通分享功能。纯本地画图不分享，迁移面板就没有可比较的对象。官网版的后端已经配好，开箱即用；自托管则要额外部署 drawdb-server。

自动检测问题

导出之前，Issues 面板会扫一遍图里的不一致。源码里的检查项包括：表、字段、索引、类型、枚举、视图的名称留空；ENUM、SET 字段没给取值；索引或唯一约束没选字段；外键关系重名；表之间成环（循环依赖）。这些低级错误在生成 SQL 之前就被拦下，相当于给"画的图"做了一圈校验。

支线一：反向工程，从 DDL 重建一张图

接手一个没有文档的旧库，往往只有一坨建表脚本。drawDB 支持把粘贴进来的 SQL DDL（也支持 DBML）反向解析成 ER 图：识别 CREATE TABLE、补全字段、根据外键自动拉出表间连线。解析侧每种方言各配一个解析器，Oracle 有独立的 oracle-sql-parser，DBML 走官方的 @dbml/core。你不需要手动重画，贴进去几秒就得到一张可拖拽、可缩放的关系图。这条支线和主线正好互逆——主线是"图 → SQL"，它是"SQL → 图"。

支线二：零摩擦使用，数据留在本地

免费版不用注册，设计保存在浏览器的 IndexedDB 里（由 dexie 库管理，不是 LocalStorage——容量更大，适合存结构数据）。因为画图本身不请求任何后端，数据不离开浏览器，页面加载后断网也能继续画。界面文案已经翻译了 51 个语言包，简繁中文都在其中。

需要说清楚的是：drawDB 没有 Service Worker，也不算严格意义的 PWA，别指望离线安装；换设备或清缓存前，记得导出一次 JSON 备份。

一个例子：把上面的机制串起来

机制单独看是静态的。用最小业务串一遍，看它们怎么配合。

第一步，新建一个空图。在画布上建两张表：

• users：id、email
• orders：id、user_id、amount

第二步，把 orders 的 user_id 拖到 users 的 id 上，建立外键关系，图里出现一条连线。

第三步，打开 SQL 面板，方言选 PostgreSQL，复制生成的建表语句。users.id 的自增导出为 INTEGER GENERATED BY DEFAULT AS IDENTITY——PostgreSQL 方言不生成 SERIAL——主键落在独立的表级子句里，外键则统一输出成 ALTER TABLE 语句。完整输出大致长这样：

CREATE TABLE IF NOT EXISTS "users" (
  "id" INTEGER GENERATED BY DEFAULT AS IDENTITY,
  "email" VARCHAR(255) NOT NULL,
  PRIMARY KEY("id")
);

CREATE TABLE IF NOT EXISTS "orders" (
  "id" INTEGER GENERATED BY DEFAULT AS IDENTITY,
  "user_id" INTEGER NOT NULL,
  "amount" DECIMAL(10, 2) NOT NULL,
  PRIMARY KEY("id")
);

ALTER TABLE "orders"
ADD FOREIGN KEY("user_id") REFERENCES "users"("id")
ON UPDATE NO ACTION ON DELETE NO ACTION;

同一张图切到 MySQL 方言，自增会变成 AUTO_INCREMENT。字段类型取决于你在画布上的选择，这里按常见选择导出。

第四步，分享这张图，给 users 加一列 created_at，再把改动保存为一个新版本。到迁移面板里选这两个版本比较，就能拿到 created_at 对应的增量语句和对应的回滚语句——全程没有在外部工具里手写一行 SQL。

技术实现与自托管

drawDB 是纯前端应用：React 18 + Vite + Tailwind CSS 4，组件库用字节跳动的 Semi Design（@douyinfe/semi-ui），SQL 与 JSON 面板内嵌 Monaco 编辑器，本地存储交给 dexie（IndexedDB）。表格卡片以 DOM 节点渲染，表间连线走 SVG 路径，整体不依赖后端，所以能静态部署。核心数据指标：仓库 39,723 Star、3,270 Fork、150 名贡献者（2026-09-28），AGPL-3.0 协议，代码约 99% 是 JavaScript，最近一次推送是 2026-09-26，维护活跃。

本地开发：

git clone https://github.com/drawdb-io/drawdb
cd drawdb
npm install
npm run dev

启动后访问 http://localhost:5173（Vite 默认端口）。

Docker 有两条路。要对外提供稳定服务，按 README 的方式构建镜像：

git clone https://github.com/drawdb-io/drawdb
cd drawdb
docker build -t drawdb .
docker run -p 3000:80 drawdb

镜像分两段构建：先用 Node 20 跑 npm run build，再用 Nginx 托管产出的静态文件，容器内监听 80 端口。

仓库里另有一个 compose.yml，起的是容器内的 Vite 开发服务器（映射 5173 端口），适合内网试跑和改代码，不适合当生产服务。

需要分享功能（私密 Gist 存图、版本历史、迁移面板）时，才额外部署配套的 drawdb-server。它只做两件事：转发 GitHub Gist 的 REST 请求、把页面里的 bug 反馈发成邮件，按 .env.sample 配置环境变量即可。不部署它，画图和导出 SQL 不受影响。

顺手能用上的细节

主线之外还有几样免费功能，不展开讲，用到时知道有就行：

• 模板：内置 6 套常见场景的预设表结构，起步不用从空画布开始。
• 快捷键：常用操作都配了快捷键，官方文档有完整清单。
• 全屏模式：把画布全屏投出来，适合评审会上对着大屏讲表结构。
• 编辑辅助：撤销 / 重做、复制粘贴、复制表，还能把表归进"主题区域"、给表加备注。

这些都在免费版里，不需要注册。

适用边界

适合：

• 项目早期把表结构画出来，和产品、后端一起评审
• 教学场景：讲数据库设计、ORM 关联关系，比甩 DDL 直观
• 反向工程：快速读懂没有文档的历史库
• 配合分享功能管理设计版本，评估一次结构变更的影响面

不适合或要注意：

• 上百张表的大库：表格卡片是 DOM 节点渲染，规模上去后滚动和拖拽会先感到吃力，drawDB 不是为超大规模建模设计的
• 多人实时协同：开源编辑器没有这项能力，官方的付费计划 drawDB Pro 才提供实时协同、云存储、团队访问控制和 AI 辅助设计
• 直接执行 DDL：drawDB 只生成 SQL，不连库执行，你仍需拿到目标库跑一遍
• 闭源商业项目：AGPL-3.0 要求衍生作品同样开源，改源码前先评估协议影响

常见问题

画完的数据存在哪？会不会丢？ 存在浏览器的 IndexedDB 里。同设备同浏览器不清缓存就不会丢；换设备、换浏览器或清缓存之前，先用导出功能备份一份 JSON。

必须联网才能用吗？ 页面加载之后不用。设计存在浏览器本地，画图和导出都不依赖网络；但项目没有 Service Worker，清掉缓存后首次打开仍需联网拉取应用资源。

Oracle 支持到什么程度？ 官方标注为 Beta。常规建表与导出可用，涉及 Oracle 特有语法时建议先跑一个小样例验证，别直接上生产库。

能在 CI 或自动化流程里用吗？ 可以。图能导出成 JSON，可供脚本读取；社区还有 drawdb-mcp 这类 MCP 服务器，把设计图暴露给 AI 代理读取、修改并导出 SQL。

下一步怎么用

给你三条参考路径，按场景选：

• 偶尔画张图：直接用官网编辑器，不需要注册，画完导出 SQL 即可。
• 对数据敏感或要内网用：走 Docker 自托管；要版本管理和迁移脚本，再加一套 drawdb-server。
• 团队要协同设计：评估 drawDB Pro，或者接受"各自画图、导出 SQL 合并"的协作流程。

一句话收尾：drawDB 解决的不是"画图画得多精致"，而是"从结构想法到可执行建表语句"这件事能不能五分钟内做完。想清楚这一点，它值不值得用就不难判断了。