DEV Community: Patu

Keep an ER diagram of your database, updated on every push

Patu — Tue, 01 Sep 2026 17:33:23 +0000

Paste a SQL schema, get an interactive entity-relationship diagram on a stable link. Wire it into CI and the diagram regenerates itself every time the schema changes: no diagram to draw, ever again.

The problem with hand-drawn diagrams

A database diagram is out of date the moment someone adds a column. You draw it once for the onboarding doc, and three migrations later it lies.

mcdview takes the opposite route: the schema file is the source of truth. Point it at your schema.sql and it generates the diagram: a single self-contained HTML page, no runtime, no database connection.

What the diagram does

Every table and relationship is interactive: click a table to isolate it, highlight the hub tables everything depends on, surface dependency cycles, flip between light and dark. You can export the same model as SVG, a Mermaid erDiagram, or a Markdown data dictionary.

Put it in CI: the diagram updates itself

Your schema lives in the repo. On every push that touches it, CI sends the file to mcdview.dev, which regenerates the diagram behind the same stable link. Bookmark it once; it is always current.

GitHub Actions

name: er-diagram
on:
  push:
    branches: [main]
    paths: [db/schema.sql]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: Gheop/mcdview-action@v1
        with:
          file: db/schema.sql
          key: ${{ secrets.MCDVIEW_KEY }}

GitLab CI

include:
  - component: gitlab.com/Gheop/mcdview/mcdview@~latest
    inputs:
      file: db/schema.sql
      key: $MCDVIEW_KEY

No secret to manage? Use oidc: true instead of a key: the pipeline proves its own identity with a signed token, and the diagram is bound to that project.

include:
  - component: gitlab.com/Gheop/mcdview/mcdview@~latest
    inputs:
      file: db/schema.sql
      oidc: true

A badge for your README

[![mcdview](https://mcdview.dev/badge/<token>.svg)](https://mcdview.dev/v/<token>)

What makes it different

Three things you rarely get in one tool:

One file, no account. Paste a schema, get a link. The page is a single static HTML file: nothing runs when you open it, no database is contacted, nothing to sign up for.
It lives in CI. A GitHub Action or GitLab component regenerates the diagram on every push, behind the same stable link, with a README badge. Zero-key with OIDC.
It remembers. Every push is a version: scrub the time-lapse, diff any two states, see what a migration changed.

On top of that: isolate a table, spot hub tables and cycles, switch light or dark, and export to SVG, Mermaid or a Markdown data dictionary.

Try it in 30 seconds

No sign-up. Open mcdview.dev. Supports PostgreSQL, MySQL, SQLite dumps, pgModeler .dbm, DBML and Prisma.

Turn any SQL schema into an interactive ER diagram

Patu — Sun, 30 Aug 2026 11:29:06 +0000

Reading a database you did not design usually starts the same way: you open the schema, scroll through a few hundred lines of CREATE TABLE, and try to hold the foreign keys in your head. A picture would help, but drawing one by hand goes stale the moment the schema changes.

I built mcdview to skip that step. You drop a schema file and you get back a single self-contained HTML page: an interactive entity-relationship diagram you can zoom, search, isolate one table with its neighbours, and share by link. No account, nothing to install.

Here is one generated from the Pagila sample database, so you can see the output before reading further: mcdview.dev/v/2slcbFWyTvqJvIAxorPlSQ

What it reads

The point was to take whatever you already have, not to make you export to a specific format first. So it accepts:

SQL: PostgreSQL, MySQL/MariaDB, SQLite and about 15 dialects, detected automatically. A plain pg_dump works. Several .sql files at once work too, for a schema split across files, with foreign keys resolved across them.
pgModeler .dbm, MySQL Workbench .mwb
dbml (dbdiagram.io), Prisma, Rails schema.rb
Mermaid erDiagram, Drizzle ORM

The page you get

The generated page is static HTML with no runtime dependency, so it is safe to host anywhere or open straight from disk. The diagram itself is interactive: pan and zoom, a search box, click a table to isolate it with the tables it references, a minimap for large models, light and dark themes. Audit-trail columns like created_by or modified_by are detected and folded away by default so they stop cluttering the graph, with a toggle to bring them back.

Using it from CI

There is a small HTTP API. A create call returns a public link and a management key; an update call regenerates the diagram under the same link, so you can keep one stable URL in your README and refresh it on every build. From the second version on, the update also returns a diff between versions (tables and indexes added, changed, removed). You can also pull the Mermaid erDiagram as plain text to paste into a GitHub or GitLab README, which both render natively.

Open source

The generator is MIT-licensed: github.com/Gheop/mcdview. It is a self-contained Python script, so you can run it locally or in your own pipeline instead of the hosted service if you prefer.

Try it on your own schema: mcdview.dev. Feedback welcome, especially on dialects or formats that trip it up.

Don't trust your SVG optimizer. Render-diff its output.

Patu — Sat, 18 Jul 2026 13:46:53 +0000

SVG optimizers are wonderful right up to the day one quietly breaks an icon.

Run SVGO (or any optimizer) across a big icon set and you'll eventually hit it: a <g> gets collapsed, a path gets rewritten into a mathematically "equivalent" form, and in most renderers it looks identical, but in one specific renderer, or at one specific size, it's subtly wrong. A shape that was outlined is now filled. A stroke disappears. You don't notice until it's in production, because it didn't show up on the five icons you spot-checked.

Here's the uncomfortable part: most optimizers guarantee "smaller," not "renders the same." Those are different promises. An optimizer can shave bytes and, on an edge case, change what the file draws. The transforms are usually safe. "Usually" is the problem.

The fix isn't a better optimizer. It's verification.

Instead of trusting that a transform preserved rendering, check it. After optimizing, rasterize the original SVG and the optimized SVG, compare the two bitmaps, and if they diverge beyond a small tolerance, throw the optimized version away and fall back.

The guarantee flips from "these transforms are provably safe" (hard, and false in the edge cases) to "the pixels didn't change" (easy to check, and exactly what you care about).

A sketch of the idea:

opt := optimize(original)         // your SVG minifier of choice
a := rasterize(original, 512)     // longest edge 512px is plenty
b := rasterize(opt, 512)
if sameSize(a, b) && diffFraction(a, b, tolerance) < 0.02 {
    use(opt)                      // pixels match: trust it
} else {
    use(fallback(original))       // diverged: don't ship it
}

A few things that matter in practice:

Flatten onto an opaque background before comparing. A shape that lost its fill and fell back to transparent should count as a difference, not get masked by alpha.
Allow a small per-channel tolerance (say 16/255). Anti-aliasing shifts sub-pixels when path data is rewritten; that's fine. A filled-vs-unfilled shape is not.
A small render is enough. You're catching gross divergence (a dropped stroke, a flipped fill), not fine detail, so a 512px raster keeps the check cheap.

You render twice, which isn't free, but for build-time optimization of an icon set you pay it once and never ship a broken icon.

The tools

The optimizer I use is silk, a pure-Go SVG optimizer in the spirit of SVGO (path data, structural passes). It ships as a single static binary, no Node toolchain, which is why it drops into a Go service or a minimal CI image where a JS toolchain would be a pain. Like most optimizers, it guarantees smaller, not identical, so the render-diff above is the layer I put around it: it lives in Patu, the asset service these came out of, and falls back to a conservative minifier whenever the render moved.

silk (MIT): https://github.com/Gheop/silk

There's a sibling for fonts, woffify: TTF/OTF/WOFF to WOFF2 plus glyph subsetting (via HarfBuzz), one binary. A raw TTF shipped instead of a subsetted WOFF2 is usually two-thirds-plus wasted bytes.

woffify -subset-text "$(cat page.txt)" < Inter.ttf > Inter.woff2

woffify (MIT): https://github.com/Gheop/woffify

If you optimize SVGs at scale, steal the render-diff idea even if you never touch these tools. It's the cheapest insurance against the one broken icon you won't catch by eye.