Stop Redrawing Your Architecture: YAML, SQL, Terraform and EXPLAIN Plans to Diagrams in One Paste

I have a confession: for years, the most out-of-date file in every repo I worked on was docs/architecture.png.

It was never anyone's fault. The diagram was correct on the day someone drew it. Then a service got split, a Redis cache appeared, a queue was added, a table gained a foreign key. Nobody wanted to open a drawing tool and push boxes around again, so the picture slowly turned into fiction, and new teammates learned the system by reading YAML instead.

The thing is, the YAML (and the SQL, and the HCL) already describes the system. The picture is just a different view of the same source of truth. That is the idea behind LetDraw: a hand-drawn whiteboard that can read the files engineers already have and draw them for you, as real, editable shapes.

This post is a practical tour. No marketing slides, just six things I actually use it for:

• Kubernetes YAML to diagram
• Docker Compose to diagram
• SQL to ER diagram
• Terraform diagram, online
• Postgres EXPLAIN visualizer
• Hand-drawn ER diagrams

The one feature everything else builds on: Generate from Code
All of the conversions below go through a single dialog called Generate from Code. You paste text (or load a file) and it:

• auto-detects the format, so you never pick "Kubernetes" or "SQL" from a dropdown,
• shows a live preview before anything touches your canvas,
• inserts normal shapes, not an image. Every box, label and arrow is editable afterwards.

That last point is the whole difference between a diagram generator and a diagram renderer. A rendered image is read-only; you either accept the layout or you go back and fight the source. Here, auto-layout gets you most of the way, and then you nudge a box, add a sticky note, or highlight the risky path like you would on any whiteboard.

A few other options show up across all formats:

• Add icons stamps recognisable product icons (Postgres, Redis, Kubernetes, AWS, Azure, GCP and more) onto the boxes.
• Drift vs last compares the current import with your previous one: added resources in green, removed ones in red. Great for change reviews.
• Layout direction (top-down or left-right) and which relationship types to show.

Honest note up front: drawing by hand, templates, shape libraries and PNG/SVG/PDF export are free. Generate from Code is part of the Pro plan ($5/month). I will point out where that matters.

1. Kubernetes YAML to diagram

Here is a trimmed version of a typical service:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: shop
spec:
  selector:
    app: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: shop/web:1.4
          envFrom:
            - configMapRef:
                name: web-config

Paste that (multi-document YAML is fine, or load the whole file) and you get a cluster diagram where:

• resources are grouped by namespace, so the layout mirrors how you think about the cluster instead of one flat soup of nodes,
• Services are linked to the workloads they select, based on the actual label selectors,
• workloads are linked to the ConfigMaps, Secrets and PersistentVolumeClaims they mount.

It understands Deployments, StatefulSets, Services, Ingress, ConfigMaps, Secrets, volume claims and RBAC objects, so a permissions review can start from a picture of which service accounts are bound to which roles.

Helm users: paste the output of helm template to see the rendered resources, or paste a Chart.yaml to see the chart and its subchart dependencies.

Where this has saved me the most time:

• Manifest reviews. Import the manifests from a PR, then turn on Drift vs last to see exactly which resources were added or removed.
• Onboarding. New engineers get the platform as one picture before they open forty YAML files.
• Incidents. The cluster diagram sits next to the runbook, with comments pinned on the parts that broke.

More detail: Kubernetes diagram tool.

2. Docker Compose to diagram

Compose files are even simpler, which makes them a perfect first try:

services:
  web:
    image: nginx
    depends_on: [api]
  api:
    image: app:latest
    depends_on: [db, redis]
  db:
    image: postgres:16
  redis:
    image: redis:7

Paste it and four services appear, laid out and connected. With Add icons on, the Postgres service becomes a database cylinder, Redis gets its own icon, and the depends_on edges become arrows that route around boxes instead of through them (LetDraw has an obstacle-avoiding "smart" connector, which is a small detail until you have tried to read a diagram where every arrow crosses three boxes).

Same dialog, same auto-detection as Kubernetes, so you do not need to tell it which one you pasted.

The workflow I recommend: keep the generated diagram next to the compose file, and when the stack changes, re-import and check Drift vs last rather than editing the drawing by hand. The picture stays right by construction, not by discipline.

There is a longer walkthrough on the blog: Docker Compose diagram, from docker-compose.yml to clean architecture.

3. SQL to ER diagram

This is the one my backend friends ask about most. Take your migrations or a schema-only dump:

CREATE TABLE users (
  id    uuid PRIMARY KEY,
  email text UNIQUE NOT NULL,
  name  text
);

CREATE TABLE orders (
  id         uuid PRIMARY KEY,
  user_id    uuid NOT NULL REFERENCES users(id),
  total      numeric(10,2),
  created_at timestamptz DEFAULT now()
);

CREATE TABLE order_items (
  order_id uuid NOT NULL REFERENCES orders(id),
  qty      int
);

Paste it and you get:

• every table as a grid with a header and one row per column, type next to name,
• PK and FK markers, with long types shortened (timestamptz, varchar) so tables stay compact,
• relationships drawn between tables, and you choose the style: plain line, arrow, smart routed connector, or crow's foot notation.

The crow's foot cardinality is not a guess. It is inferred from the foreign key column itself: a NOT NULL FK means "exactly one" on the parent side, a nullable one means "zero or one", and a UNIQUE FK turns one-to-many into one-to-one.

It handles Postgres, MySQL and standard SQL, including quoted names, schema prefixes (public.users), IF NOT EXISTS, inline REFERENCES and separate FOREIGN KEY constraints. Comments are ignored, so you can paste a migration file as-is.

Two details I like:

• While the generated ERD is unchanged, Diagram to Code gives it back as Mermaid erDiagram code. Handy if your docs live in Markdown.
• Everything is normal shapes, so you can sketch the proposed tables for a new feature right next to the current schema and argue about it with comments on the relationships.

More: SQL to ER diagram.

4. Terraform diagram, online

No CLI to install, no graph tooling, no cloud credentials. Paste HCL into the browser:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_security_group" "web" {
  vpc_id = aws_vpc.main.id
}

resource "aws_instance" "web" {
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.app.id
  vpc_security_group_ids = [aws_security_group.web.id]
}

LetDraw reads resource, data, module, variable and output blocks and turns references into arrows: aws_vpc.main.id, var.region, depends_on. Each arrow is labelled with the attribute that created the link (vpc_id, subnet_id), which is exactly the information you want during a review.

Each resource becomes a card with its type, its name and a couple of key settings (CIDR block, instance type). Resources are grouped by provider, so a multi-cloud estate keeps AWS, Azure and GCP in separate frames, and modules, variables and outputs get their own frames too.

Use cases where it pays off:

• Architecture reviews: show reviewers what the code actually builds instead of walking them through file after file.
• Change reviews: paste the new version, turn on Drift vs last, and see added and removed resources and links.
• Dependency checks: before renaming a variable or a module output, see who reads it.

More: Terraform diagram generator.

5. Postgres EXPLAIN visualizer

This one is not an architecture diagram at all, and it is the feature that surprised people the most when I showed it around.

Run your query with a JSON plan:

EXPLAIN (ANALYZE, FORMAT JSON)
SELECT *
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at > now() - interval '7 days'
ORDER BY o.created_at DESC;

Paste the JSON output and you get a tree, one box per plan node, showing the node type, the table, index or function it touches, cost, rows and, with ANALYZE, the time in milliseconds across all loops.

The important part is the heat map. Postgres reports cost and time cumulatively, which is why the root node of every plan looks like the most expensive one. The visualizer subtracts each node's children and colours by self time, from green through amber to red. So the node that actually hurts (that sequential scan on orders, say) lights up red, instead of the Sort at the top that merely inherits its children's time.

It also takes MySQL EXPLAIN FORMAT=JSON, showing each table with its access type, cost and rows.

And it runs in your browser, so the plan, your table names and your query text stay on your machine. That matters when the query touches production schemas you would rather not paste into a random website.

Things I now do with it:

• Before and after an index: both plans on one canvas, and you can see which node turned from red to green.
• Code review: attach the plan of a new query to the PR so reviewers see its cost, not just its SQL.
• Post-mortems: export the heat-mapped tree as SVG and put the culprit right in the write-up.

More: EXPLAIN plan visualizer.

6. Hand-drawn ER diagrams (and why the sketchy look is a feature)

Everything above is generated, but LetDraw is first and foremost a whiteboard, and the default style is hand-drawn.

I used to think that was purely aesthetic. It is not. A sketchy diagram signals "this is a draft, please argue with it." People comment on a hand-drawn ERD in a design review far more freely than on a polished one that looks final. That is exactly the conversation you want before the first migration is written.

What makes it usable for real data modelling rather than doodling:

• Crow's foot cardinality as native arrowheads: one, zero or one, zero or many, one or many. You pick them on the arrow ends, no hand-drawn markers to keep aligned.
• A Database Schema template to start from, plus SQL import when you want the real thing.
• A Sketchiness setting (Clean, Sketch, Scribble), so the same ERD can go from whiteboard draft to clean documentation without redrawing it.
• Mermaid ER import and export, and AI drafts from a plain-language description.

Drawing ER diagrams by hand, with all of the above, is free.

More: ER diagram tool.

What sets it apart (from a developer's point of view)

I have used a lot of diagram tools. Most fall into one of two camps: pretty whiteboards that know nothing about your stack, or diagrams-as-code renderers that know your stack but give you a read-only image. LetDraw sits in the middle, and that is the point:

• Code in, editable shapes out. Kubernetes, Helm, Compose, Terraform, SQL, EXPLAIN plans, Graphviz DOT, PlantUML, OpenAPI, git log, Mermaid and D2 all become real shapes you can move and annotate.
• And back to code. Diagram to Code exports Mermaid or D2, so a diagram can live in your repo and be reviewed like code.
• Local-first and private. No install, works offline, drawings stay in your browser, no third-party tracking. Live collaboration and shared snapshots are end-to-end encrypted in the browser with AES-GCM.
• Real-time collaboration with live cursors, roles, and comments you can pin to any point on the canvas, not just to a shape.
• Embeds that do not go stale. Drop a snippet into a README or wiki for a live, read-only view, instead of a PNG someone must remember to re-export.
• Automation. There is a REST API and an MCP server, so CI jobs and AI agents can create and update diagrams, too.
• AI that is not a paywall trap. Every plan gets a few free AI requests; after that you can bring your own provider key (BYOK) for unlimited use.
• Self-hosting is available on the Enterprise plan, for teams that need diagrams to stay inside their own network.

Why DevOps and software teams should care

Diagrams are not documentation for documentation's sake. They are how we:

• onboard people faster than any wiki page,
• review infrastructure and schema changes without reading every file,
• explain incidents to people who were not on the call,
• argue productively about trade-offs before code exists. The reason teams skip them is cost: drawing is slow, and keeping drawings current is slower. If the diagram can be regenerated from the same YAML, HCL or SQL that runs in production, that cost mostly disappears, and the diagram stops being fiction.

Try it in two minutes

1. Open letdraw.com. No sign-up needed to start drawing.
2. Grab a docker-compose.yml, a Kubernetes manifest, some CREATE TABLE statements or an EXPLAIN (FORMAT JSON) output from your own project.
3. Open Generate from Code, paste, and look at the preview.
4. Insert it, move a few boxes, and share the link with a teammate. If you try it on a real project, I would love to hear what broke, what surprised you, and which format you want next. Drop a comment below.