VS Code extensions can draw a new ERD, render one inside documentation or inspect the structure of a connected database without opening a separate browser tool.
ERD Editor handles dedicated schema design; other extensions handle documentation diagrams, free-form drawing or database inspection. The extension details below are current as of August 2026, and the publisher name is included for verification before installation.
Three questions that narrow the field
Is the saved file text? This matters most if the diagram belongs in your repository. Text formats produce readable diffs and can go through code review; image files leave reviewers guessing.
Does it move DDL in and out? With an existing database, whether the extension can import CREATE TABLE statements, and export them back, decides how much typing you do. An extension that only draws pictures ends at pictures.
Where does the result go? A README, a slide deck, or an actual schema change each point to a different tool.
ERD Editor: a dedicated ERD canvas in the editor
Publisher: dineug
For real diagram work inside VS Code, this is the closest fit. Install it, create an empty file with the .erd.json extension, open it, and you get a purpose-built editing surface.
Beyond creating tables, columns and relationships, you can set cardinality four ways: zero-or-one, exactly one, zero-or-more, one-or-more. That's the same system crow's foot notation uses, so if the symbols are unfamiliar the ERD notation guide covers them.
The part that pays off at work is import and export. Paste in SQL DDL and get a diagram; export the diagram back out as DDL. It also imports from DBML and GraphQL schemas. Pull your production schema in once and you can check structure from the editor from then on.
Because the file is text-based, it belongs comfortably in a repository. The same editor also runs in the browser and in IntelliJ, so a team on mixed tooling can still share one file.
Mermaid: diagrams that live in the documentation
Publisher: Matt Bierner (Markdown Preview Mermaid Support)
If the goal is a structure diagram in a README or wiki, you don't need an ERD tool at all. Write a Mermaid code block in Markdown, install the preview extension, and the rendered diagram appears beside your text in the editor.
erDiagram
MEMBERS ||--o{ POSTS : "writes"
POSTS ||--o{ COMMENTS : "has"The advantage is that the artifact is code. It lives in git, changes show up as diffs, and GitHub renders the same picture. Syntax and how to read the relationship symbols are covered with a forum example in Mermaid ERD.
The cost is that you can't control layout, and details like data types and indexes have nowhere to go. It works best as the summary diagram, with precise design handled elsewhere.
Draw.io Integration: when you need a free hand
Publisher: hediet
This one runs draw.io inside VS Code. Open a .drawio, .dio, .drawio.svg or .drawio.png file and the draw.io editor opens in a tab. An offline build ships with the extension, so it works without a connection.
It suits teams who want ER diagrams, architecture sketches and flow charts in one repository under one tool. Turn on the Entity Relation shape library and the crow's foot connectors are right there; finding the shapes and setting line ends is covered in How to Make an ER Diagram in draw.io.
One detail worth knowing: the same .drawio file can also be opened as XML, and the two views stay in sync. Editing values as text and checking the result as a picture is a genuinely useful combination. Live Share also lets several people edit one diagram together.
Schema Designer in the MSSQL extension: for SQL Server
Publisher: Microsoft (MSSQL extension)
Working on SQL Server adds one more option. Microsoft's MSSQL extension now includes a Schema Designer, generally available as of 2026, which lets you create and edit tables, foreign keys, primary keys and constraints without writing T-SQL by hand.
It supports search, drag and drop, filtering, zoom, a mini-map and auto-arrange, which keeps large schemas manageable, and it carries you through reviewing changes visually and generating the script.
The equivalent inside SSMS is covered in How to Create a Database Diagram in SSMS. Choose based on whether you want to stay in the editor or work where the rest of your SQL Server tooling lives.
Database Client: looking at a live schema
Publisher: cweijan
When the goal is inspecting a database that already exists rather than designing a new one, a client extension is quicker. Database Client connects to MySQL, PostgreSQL and many other systems, providing a SQL editor and data grid alongside ER diagram views.
Since it works from a connection, the export-a-file step disappears. The trade is that the diagram lives inside the extension, so showing it to someone without database access still means exporting an image or DDL.
Before you install anything
The marketplace carries several extensions with similar names. Three checks save most of the trouble.
Look at the publisher. More than one extension can claim the same feature, so confirm the publisher matches the one named here. It's shown at the top of the extension page.
Look at the last update. An extension untouched for years can break when VS Code moves on. Last-updated date is a more practical signal than download count or star rating.
Check whether it works offline. In an air-gapped environment, an extension that needs to reach the internet is a non-starter. Draw.io Integration bundles an offline build, which is why it survives those environments.
Building your first diagram in ERD Editor
Once it's installed, the fastest way to learn it is to draw something:
- Create an empty file ending in
.erd.json, for exampleschema.erd.json. - Open it and the ERD editing surface appears instead of a text editor.
- Add a table, name it, and fill in columns and types. Mark the column that will be the primary key.
- Connect a relationship from parent to child and set the cardinality.
- Export as DDL and you have CREATE TABLE statements.
With an existing database you can skip straight past step 3: import the DDL first so the whole schema is on the canvas, then draw only what's new. Extraction commands per DBMS are in step 1 of SQL to ERD.
The same forum in Mermaid, with columns
The earlier snippet was two relationship lines. Real documentation usually carries the columns too:
erDiagram
MEMBERS ||--o{ POSTS : "writes"
MEMBERS ||--o{ COMMENTS : "writes"
CATEGORIES ||--o{ POSTS : "groups"
POSTS ||--o{ COMMENTS : "has"
MEMBERS {
bigint id PK
varchar email UK
varchar nickname
}
POSTS {
bigint id PK
bigint member_id FK
int category_id FK
varchar title
}Relationships at the top, table definitions below: the first few lines tell you the shape of the schema, and when a change lands, relationship edits and column edits show up as separate parts of the diff.
Combinations that work
Most teams end up using two or three of these rather than declaring a winner.
Documentation-first teams. If the goal is keeping a structure diagram in the README and wiki, the Mermaid preview alone is enough. Schema changes mean editing a code block, and review sees the diff. Nothing to manage as a separate image file.
Teams designing frequently. When every feature adds tables, designing in ERD Editor and exporting DDL fits better. Keep the .erd.json in the repository and send it to review alongside the migration, and structural changes get discussed where code review already happens.
SQL Server teams. Design in the MSSQL extension's Schema Designer without leaving the editor, then generate the script to apply. If SSMS is also in the picture, this continues from How to Create a Database Diagram in SSMS.
Sorted by purpose
| Extension | File format | DDL import | DDL export | Viewable without the extension |
|---|---|---|---|---|
| ERD Editor (dineug) | .erd.json (text) |
Yes (also DBML, GraphQL) | Yes | No |
| Mermaid preview (bierner) | Markdown code block | No | No | Renders on GitHub and GitLab |
| Draw.io Integration (hediet) | .drawio family (XML) |
No | No | Yes with .drawio.png / .drawio.svg |
| MSSQL Schema Designer (Microsoft) | Edits the database schema | Via connection | Generates script | No |
| Database Client (cweijan) | Connection-based | Via connection | Depends on the tool | No |
The two right-hand columns are where the real difference sits. DDL in and out means your work survives a change of tools, and being viewable without the extension removes a step every time someone outside the team needs to see the structure. Design work points to ERD Editor, documentation to Mermaid, and inspecting an existing database to a client extension.
When the image file is also the source
One detail worth knowing about Draw.io Integration: save as .drawio.png or .drawio.svg and the file is an ordinary image and an editable source at the same time. Image viewers show a picture; VS Code opens an editor.
Paste it into a wiki or an issue and it renders; open the same file from the repository and you can edit it. The usual problem of an exported image drifting away from its source file simply doesn't arise.
The trade is that git shows no meaningful diff for a binary image. For diagrams whose changes need review, a text format is better; for a picture that sits in documentation and gets touched occasionally, this is the more comfortable arrangement.
Using these on a team
The file format decides how you collaborate. Text formats go into the repository and get reviewed as diffs, which matters if you want schema changes to move through the same process as code. Image files hide what changed and are miserable to merge when two people edit at once.
Keep one path that doesn't require an installation. Sooner or later someone outside the team needs to see the structure. Agreeing in advance on how you export an image or share a link saves the scramble when that day arrives.
Extensions come and go. Nothing guarantees today's favorite is maintained in three years, which is the argument for keeping the source of truth as DDL or another text format. With the DDL, any tool can redraw the picture. Extracting it per DBMS is covered in SQL to ERD.
FAQ
Can I design an ERD entirely inside VS Code?
Yes. The ERD Editor extension opens a dedicated canvas in the editor where you create tables and connect relationships, and it both imports SQL DDL and exports it back out. If all you need is a diagram for documentation, a Mermaid preview extension is enough on its own.
Can I see an existing database's structure from VS Code?
With a connection extension, yes. Database Client and similar extensions render the tables of a connected database as an ER diagram, and on SQL Server the Schema Designer in Microsoft's MSSQL extension covers the same ground.
How do I share a diagram drawn in an extension?
It depends on the file format. If your teammates have the same extension installed, commit the file. For anyone without it, export an image or extract the DDL and load it into a browser-based tool that shares by link.
Should ERD files live in git?
If they're text, yes. Mermaid code and ERD Editor files are stored as text, so changes show up as diffs and can go through review. Binary files like images tell you nothing about what changed and are painful to merge, so keep the source in text and generate images when you need them.
Use ERD Editor for schema design, Mermaid for documentation, Draw.io Integration for free-form drawing and a database client extension for inspecting an existing database. Keeping the source as DDL or text makes it reusable if the extension changes.
When the picture has to leave the editor, pasting DDL into WorksCove ERD produces a diagram and a table specification you can share by link. Comparisons of the browser-based free options are in free online ERD tools.