ERD Editor ships the same.erd.json to multiple hosts, including an MCP server

One file format, eight hosts, and the .erd.json extension as the contract

ERD Editor's central claim is that it is one editor and one file format, available in more places than is usual for a diagramming tool. The README lists the surfaces explicitly:

| Surface | What it is | | --- | --- | | Web app at erd-editor.io | Installable PWA that launches offline, with real-time collaboration | | Google Drive | Adds the editor to Drive's Open with and New menus, saving back to the same file | | VS Code | Opens `.erd.json` files in a custom editor | | IntelliJ | The same, for IntelliJ-based IDEs | | Obsidian | Opens `.erd` and `.erd.json` in a vault tab, desktop only | | Your app | The framework-free `<erd-editor>` custom element | | Coding agents | An MCP server for Claude Code, Codex or another client |

The file extension is what makes that table coherent. `.erd.json` is JSON, which means it diffs, merges and reviews like any other text file, and the Obsidian host also accepts the shorter `.erd` spelling.

The onboarding trick is worth knowing because it removes a configuration step: to try it in an IDE, create an empty file with a `.erd.json` extension and open it. In Obsidian the equivalent is the command palette entry ERD Editor: Create new diagram, and in Google Drive it is New, then More, then ERD Editor.

Embedding it in your own application is a normal npm install, and the README is explicit that the custom element is framework-free, meaning it does not require a React or Vue wrapper to use:

npm install @dineug/erd-editor

The Obsidian host is the one desktop-only limitation stated outright, so if your vault is synced and edited on mobile, the diagram editing surface is not there.

Import and Add is the feature that makes the editor composable

Most schema tools treat import as a one-shot conversion that replaces your canvas. ERD Editor has two import modes, and the second one is the interesting design decision.

Plain Import replaces the diagram. The README states that a schema picked from the Import menu, the command palette or a host's file dialog arrives with its tables placed by their relationships, in rows when it has none, and that one undo puts the previous diagram back.

Import and Add does not replace. The menu beside Import, and its five formats in the command palette, add a `.sql`, GraphQL, DBML, AML or `.erd.json` file to the diagram: its tables arrive below everything already there, laid out the same way, an `.erd.json` file keeping its own placement, selected, with one undo removing them.

That single capability changes how the tool fits a workflow. You can keep one diagram per bounded context and pull a third party's schema into it to see how it connects, without losing what you had and without a merge step. The README also states that a table whose name is already taken arrives as a second table rather than merging, which is the right default for exploration and one you need to know about before you assume names deduplicate.

Two more details worth planning for. When a SQL, DBML, AML or GraphQL file is imported into the schema list on erd-editor.io or into the Google Drive editor, it becomes a new diagram rather than a modification. And auto layout places tables again by Force, Flow or a vertical or horizontal tree, keeping table groups together in one undo step, with Force showing a preview you apply or cancel.

SQL DDL import is forgiving by design, and tells you so

The SQL importer reads a `.sql` dump from any of eight vendors, though the README as published truncates before naming them. The parser reads `CREATE TABLE`, `CREATE INDEX`, `ALTER TABLE` constraints, and table and column comments, with the comment support covering `COMMENT ON` syntax and SQL Server's `sp_addextendedproperty`.

The design decision that matters is the failure mode. The README states that the parser skips what it does not recognize, so an awkward dump imports partially rather than failing outright.

That is the right choice for real schemas and the wrong choice if you are validating anything. Partial import means you must read the result rather than trust it, because a silently dropped constraint will export back out as a missing foreign key. There is no mention in the README of a strict mode, a warning count or a report of skipped statements, so treat a SQL import as a starting point for cleanup rather than a lossless round trip.

Referential actions are read on import. SQL, DBML and AML import all understand On Delete and On Update, with the supported values being NO ACTION, CASCADE, SET NULL, SET DEFAULT and RESTRICT. The editor marks one action that the current database leaves out, and shows them at the child end of the relationship line as `D:C U:R`, which you can hide through the View Option called Referential Actions.

Alternate keys work the same way in both directions. View Option's Alternate Key marks the columns of each unique index over two or more columns as `AK1.1` and `AK1.2`, and SQL import reads a multi-column UNIQUE as one such index.

GraphQL, DBML and AML import each drop their own wrapper types

The other three importers follow the same principle: take what maps, skip what does not, and say which is which in the documentation.

GraphQL SDL import works from any tool that emits SDL. Object types become tables, scalars map to the diagram's dialect, and the fields pointing at another type become relationships. What gets dropped is the interesting part: root types and the wrapper types that Relay, Federation and Hasura generate are left out rather than drawn as tables. That is a deliberate choice, and it means a Federation schema imports as the entities you care about rather than as a diagram dominated by synthetic node types.

DBML import accepts files written for dbdiagram.io or dbdocs.io, or emitted by `sql2dbml` or `prisma-dbml-generator`. Tables, columns, indexes, enums, header colors, every `Ref` spelling and each `TableGroup` arrive, while a `Project` or a sticky `Note` is skipped rather than refused.

AML import is for Azimutt files, in either the v2 or the legacy v1 spelling. Entities, attributes, indexes, enums, colors and every relation arrow arrive; a check or struct type is skipped, and a view arrives as a table.

So DBML is the richest of the three, since it also carries table groups, and AML has the notable behaviour of materialising views as tables. If your source format is DBML or AML you keep structure that SQL import would flatten.

For generating output, the project description states that the editor exports DDL and code for 22 languages. The README as published is cut off during the Import and Add description and does not reach the export section, so which targets are covered, and which referential actions each one supports, cannot be read from it.

The MCP server is what makes this different from a diagram tool

The coding agent integration is the part with no real comparison, and the repository layout backs it up. The top level contains `packages/`, `functions/`, `docker/`, `data/`, `json-schema/`, `tools/` and `scripts/`, alongside an `AGENTS.md` and a `build-target.ts`, which is a much larger footprint than a diagramming canvas.

The README describes the MCP server as `@dineug/erd-editor-mcp`, usable by Claude Code, Codex or another client, and it works live in VS Code, a JetBrains IDE or Obsidian, or directly on the file. That last mode is the one worth understanding: an agent can operate on the file without an editor running, which turns schema editing into a reviewable text change.

The practical consequence is that a schema becomes something a coding agent can propose edits to, and a reviewer sees a diff of a JSON file rather than a picture. Combined with Import and Add, the workflow is coherent: an agent pulls a schema into a diagram, lays it out, and the human reviews the text.

The repository also has a `json-schema/` directory, which suggests the file format carries a published schema, and the clean diffs feature is designed for exactly this. Scroll position and zoom, the open tab, the code generator's language and name cases, and the bracket type are locked by default, so the file keeps the values it had when locked and looking around never changes it. The file is also written in a fixed order and leaves out measured widths, connector anchors and removed items.

That combination, locked view state, fixed write order, no measured geometry, is what makes an agent-driven diff small. It is the least obvious design work in the project and the most important for this use case.

Building from source, and where the limits are

The monorepo is a pnpm workspace with a pinned toolchain, and the package metadata is specific about it:

{
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=22.12.0"
  }
}

The engines field means Node 22.12.0 or newer, which is worth checking before you clone. The scripts are all run through a `vp` binary: build is `vp run -r build`, test is `vp run -r test`, and there are separate `size`, `peer-graph` and `check` entries, the last of which chains `vp check`, `tsc --noEmit`, a node test run over `tools/vite-config.test.ts` and `scripts/check-task-inputs.mjs`.

Those two custom scripts are the ones with a purpose. `check-bundle-size.mjs` means bundle size is a gate in this project, and `check-peer-graph.mjs` means dependency peer ranges are validated automatically. For an editor distributed as a custom element, PWA and IDE plugin, keeping the core small enough to embed is a real constraint rather than an aspiration.

The limits to hold in mind. The Obsidian host is desktop only. The SQL importer is lossy by design. The MCP integration has no documented setup in the published README, only a package name and the list of clients it targets. And the export targets, which is the feature most teams would evaluate first, are described in the repository description as 22 languages but are not enumerated in the README text available here.

Licence is MIT, so embedding the custom element in a commercial product carries no copyleft obligation. The repository is not archived and the last push was on 2026-10-16, after the v4.0.0 release on 2026-10-11, with v3.10.0 from 2026-10-03 and v3.9.2 from 2026-09-28. Three releases in under three weeks on a monorepo of this shape means a major version is cheap here, so pin a version rather than tracking main for anything you depend on.

Editorial conclusion

Adopt ERD Editor when your team lives across a browser, VS Code, a JetBrains IDE and Obsidian and wants one schema file that follows the person rather than the tool, or when you want a coding agent to edit diagrams through the MCP server. Do not adopt it as a headless schema pipeline, because every listed surface is an interactive editor, and do not plan around code generation for a specific target until you confirm it is among the exports, since the README as published stops before the export section. Verify first that the dialect you need is covered by the SQL importer, which the README says handles eight vendors, and pin a version because v4.0.0 landed on 2026-10-11 and the file format is written in a fixed order.

Frequently asked questions

Official sources

1. dineug/erd-editor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases