Your query is slow. Here's how to see why.

You ship the feature, it works on your laptop, and then one endpoint takes three seconds in production. You already know the culprit is a query. What you do not know is which part of it, and the tool that is supposed to tell you hands back a wall of indented text with numbers you have to squint at.

That wall of text is an EXPLAIN plan, and it holds the whole answer. The database is telling you exactly how it will run your query, node by node, with a cost on each one. The trouble is the format. A raw plan is dense, deeply nested, and optimized for a parser, not for a person reading it at 4pm on a Friday. So most of us scan for the word "Seq Scan," feel a vague dread, and move on.

The plan is a tree pretending to be text

Every EXPLAIN plan is really a tree. The root is the final result, its children are the steps that feed it, and each step carries an estimated cost. When you dump it as text, that structure gets flattened into indentation, and the one thing you actually care about (where the time goes) gets buried among rows, widths, and loop counts.

The fix is to stop reading the tree as text and start seeing it as a tree. Ask for the machine-friendly shape first:

-- Postgres: ask for JSON so the plan keeps its structure
EXPLAIN (ANALYZE, FORMAT JSON)
SELECT u.name, count(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at > '2026-01-01'
GROUP BY u.name;

Postgres (and MySQL, with its own FORMAT=JSON) will answer with a JSON document instead of the usual text. It looks like this, and it is honestly not much friendlier to read by hand:

[{ "Plan": {
  "Node Type": "Hash Join",
  "Total Cost": 18422.6,
  "Plans": [
    { "Node Type": "Seq Scan",
      "Relation Name": "orders",
      "Total Cost": 15903.0 },
    { "Node Type": "Index Scan",
      "Relation Name": "users",
      "Total Cost": 211.4 }
  ] } }]

Paste it, and the slow part lights up

Copy that JSON, open LetDraw's Generate from Code dialog, and paste. You do not have to tell it what it is looking at. LetDraw auto-detects a Postgres or MySQL EXPLAIN plan and renders it as a heat-mapped plan tree: the real tree, drawn out, with each node colored by its cost.

The most expensive node is the reddest one. That is the whole review, in one glance.

Hot nodes glow red and orange; cheap ones stay green. So instead of parsing costs by eye, you look at the picture and your attention goes straight to the bottleneck.

Now the diagnosis is obvious. The orders side is a Seq Scan, a full read of the table, while users is already served by an Index Scan. The expensive hash join at the top is expensive because it is fed by that full scan. The missing index on orders(created_at) is not something you deduced from a cost column; it is the one red box on the page.

Your query never leaves the browser

This is the part database people tend to ask about first. An EXPLAIN plan can reveal table names, column names, and row estimates you would rather not hand to a random web tool. LetDraw runs the whole thing client-side. The parsing and the layout happen in your browser, on your machine. Nothing about your query or your schema is uploaded to a server to make the picture.

• Paste a plan from a production database without it leaving your laptop
• No account or upload required to render a plan into a tree
• The same privacy applies whether you use the hosted app or self-host it

It is a diagram, so you can act on it

The plan tree is not a static image. It is made of the same editable shapes as everything else in LetDraw, which means the moment you spot the problem you can turn it into something a teammate will understand.

• Circle the hot path and drop a note explaining the missing index
• Paste the before and after plans side by side to show the fix landed
• Export to PNG, SVG or PDF and attach it to the pull request or the incident write-up

A raw plan is a thing one engineer deciphers alone. A heat-mapped tree with a note on the red box is a thing the whole review understands in a few seconds. That is the difference between "the query is slow" and "here is the slow part, and here is the one-line fix." Paste your next EXPLAIN plan and let the bottleneck introduce itself.