prisma-erd-generator: an ER diagram that regenerates with your Prisma client

The diagram is a build output, not a document

prisma-erd-generator is a Prisma generator that creates an ER Diagram every time you generate your prisma client. The description puts it plainly: generate an ER diagram based on your Prisma schema every time you run npx prisma generate.

The interesting decision is not the drawing, it is the timing. A schema-driven diagram that is regenerated by the same command that generates the client cannot drift from the schema, because the two are produced by the same run against the same model. The alternative, a diagram in a wiki or a draw.io file, is accurate on the day someone draws it and misleading from then on.

The origin of the project explains the shape it ended up with. The README credits @Skn0tt, who started the effort with his web app ER diagram generator, and the npm package is prisma-erd-generator, at version 3.2.1 in the repository metadata, with a Node engine requirement of node >= 20.

The audience is Prisma users who want the diagram in the repository without a second tool in the loop. The repository even ships the generated artefact, with an ERD.svg committed at the root, so you can see the expected output before you install anything.

Two renderers, and the question is how big your build gets

The renderer option decides which engine draws the diagram, and it defaults to mermaid. The two options differ in a way that matters far more than the output aesthetics.

The mermaid renderer supports svg, png, pdf, md and mmd, and it needs @mermaid-js/mermaid-cli for images, which is around 470 MB because it bundles Chromium. The reason is given precisely: mermaid lays out with getBBox(), which needs a real DOM, and that is why the mermaid CLI ships Chromium.

The graphviz renderer supports svg and dot, and it needs @hpcc-js/wasm-graphviz, about 2 MB, with no browser. The reason is that Graphviz does its own layout in WebAssembly, so it works the same in a slim container or a CI job with nothing installed.

That is the entire trade in one sentence. Mermaid gives you crow's-foot ER notation, and Graphviz gives you a build that does not drag a browser into your image. The cost of the Graphviz route is that it has no crow's-foot notation, so cardinality shows up in the arrowheads and the relation label rather than in ER symbols. The README is also explicit that mermaidConfig and puppeteerConfig do not apply to graphviz, and that raster output stays mermaid-only, since rasterising would mean bringing back the browser this renderer exists to avoid.

Every other option works the same on both renderers: tableOnly, ignoreEnums, ignoreViews, ignorePattern, usePrismaNames, showIndexes, includeComments, sortFields and disableEmoji.

Text output is the way to avoid the browser entirely

The output option is where the dependency decision actually gets made, and the README's table of extensions is the thing to read.

svg is the default, landing at./prisma/ERD.svg, and png and pdf sit alongside it. All three need @mermaid-js/mermaid-cli. Then there are md, which is mermaid in a fenced code block, and mmd, which is bare mermaid, and neither needs the CLI.

That distinction matters more than it looks. An md file with a mermaid block is a diagram your repository renders, as long as your host renders mermaid, with no renderer installed anywhere. An mmd file is the same content without the fence, for a tool that wants to embed it. Neither requires a browser, and neither requires the graphviz package.

This is also why the install instructions are split into two. For images, you install the generator together with @mermaid-js/mermaid-cli and puppeteer:

npm i -D prisma-erd-generator @mermaid-js/mermaid-cli puppeteer

For text only, the generator alone is enough:

npm i -D prisma-erd-generator

The same split reappears in the 3.x upgrade notes. @mermaid-js/mermaid-cli is no longer a hard dependency, and if you output an image and relied on it being installed for you, you add it explicitly. If you output.md or.mmd, you can now drop both and skip the Chromium download entirely.

The version table is tied to your Prisma major

The README states the compatibility rules in three lines, and they are worth memorising because getting it wrong is a confusing failure.

Prisma >= 5 uses 3.x.x or 2.x.x. Prisma = 4 uses 1.x.x. Prisma < 4 uses 0.11.x.

So the generator version is not chosen on its own merits, it is chosen by the Prisma version in your project, and a project on Prisma 4 is two major versions behind. The 3.x line itself is the current one, with v3.2.1 and v3.2.0 both published on 2026-08-27 and v3.1.0 on 2026-08-25, and the last push to the repository was on 2026-09-15.

The upgrade note for 3.x is narrow and worth reading rather than skipping. @mermaid-js/mermaid-cli is no longer a hard dependency, and nothing else changed, but if you output an image and relied on it being installed for you, add it explicitly.

Beyond the version choice, the configuration is ordinary Prisma generator syntax. The block goes in schema.prisma, the provider is the package name, and the output path is an option on the same block:

generator erd {
  provider = "prisma-erd-generator"
  output = "../ERD.svg"
}

With that in place, npx prisma generate produces the diagram as a side effect of producing the client, which is the entire point of the design.

Turning the generator off in a Docker build is a documented step

There is a failure mode that anyone who runs prisma generate in a container will hit immediately, and the README addresses it head on.

You will not always need to generate a new ERD. For instance, when you are building your docker containers you often run prisma generate, and if this generator is included, odds are you aren't relying on an updated ERD inside your docker container. It also adds additional space to the container because of dependencies such as puppeteer.

Two ways to disable it are given. The environment variable route is one line:

DISABLE_ERD=true

The configuration route sets a flag in the generator block:

generator erd {
  provider = "prisma-erd-generator"
  disabled = true
}

And there is a third approach the author uses himself, which is the most reliable of the three because it removes the generator before the dependencies are installed at all. You remove the generator lines from your schema before installing dependencies and running the prisma generate command, using sed to remove the lines the generator is located on, as in this Dockerfile example that deletes lines 5-9 from prisma/schema.prisma:

# remove and replace unnecessary generators (erd generator)
# Deletes lines 5-9 from prisma/schema.prisma
RUN sed -i '5,9d' prisma/schema.prisma

The line-number fragility of that approach is obvious, and the reason the environment variable and the disabled flag exist is to give you a stable alternative.

For debugging there is a matching pair of switches as well, ERD_DEBUG=true as an environment variable or erdDebug = true in the configuration, and re-running prisma generate then produces a directory and files labelling the steps that created the ERD.

Yarn 3 and pnp break the mmdc lookup, and the fix is a shell script

There is one failure mode in this project that is worth knowing about before you hit it, because the error message will not explain it.

To render an image you must have mmdc installed, and it ships with the optional @mermaid-js/mermaid-cli peer dependency. By default the generator searches for an existing binary file at /node_modules/.bin, and if it fails to find that binary it will run find ../.. -name mmdc to search through your folder for an mmdc binary. If you are using a different package manager or have a different location for your binary files, you can specify the path to the binary file with the mmdcPath option.

The specific trap is Yarn 3 and above. Yarn 3+ doesn't create a node_modules/.bin directory for scripts when using the pnp or pnpm nodeLinkers. It instead makes scripts available directly from the package.json file using yarn <script_name>, which means that there won't be an mmdc file created at all.

The documented workaround is to create your own shell script named mmdc inside your project's files that runs yarn mmdc, and the README notes that this shell script does not need to be added to your package.json file's scripts section, because the generator will access the script directly. The example script is four lines:

#!/bin/bash

# $@ passes the parameters that this mmdc script was run with along to the mermaid cli
yarn mmdc $@

You then make it executable with chmod +x mmdc and set the mmdcPath option to point at the directory where you put it. The fix is unglamorous, and it is the kind of detail that separates a project that works for its author from one that works in your repository.

MIT, changesets, tsup, and a package that publishes two entry points

The licence is MIT, with the LICENSE file at the root of the repository, and the package metadata sets the same. The package is published publicly with provenance enabled and an explicit npm registry, so the artefact is meant to be verifiable.

The build and release tooling is modern and conventional. The build is tsup with a prebuild step that removes dist, the tests run under vitest with its own config, linting is oxlint and formatting is oxfmt, and the lockfile is bun.lock, so the project develops with Bun. The release path uses changesets, with the ci:publish script running the build and then changeset publish, and a release script that runs changeset, plus a RELEASING.md at the root describing the process. There is a .changeset directory, so version bumps come from changeset entries rather than manual edits.

The package exposes two module formats from one build, with the exports map pointing at ./dist/index.js for import and ./dist/index.cjs for require, and the same dist/index.d.ts for types. The bin field points at ./dist/index.js, which is what makes the package usable as a Prisma generator binary rather than only as a library.

The repository also has a test suite in __tests__, a prisma directory that holds the example schema, an example-mermaid-config.js at the root, and a types directory. The contributor list in the README badge is long, which is the expected shape for a tool that has been through a Hacktoberfest and several major version bumps.

Editorial conclusion

prisma-erd-generator fits a team that wants its ER diagram to be a build output rather than a document someone maintains by hand, and that is comfortable with the diagram being regenerated in CI. It does not fit a container image that should stay small, and it does not suit a project that has settled on a different diagram tool already. Before you install, decide whether you want an image or the md and mmd text output, because that choice determines whether your build downloads a headless Chromium, and pick the generator line for your Prisma major since the version table is explicit about it.

Frequently asked questions

Official sources

1. keonik/prisma-erd-generator on GitHub
2. License: MIT
3. Project website
4. README
5. Releases