SQL EXPLAIN Visualizer
Render a Postgres / MySQL / SQL Server query plan as a collapsible tree with cost highlights.
Overview
Paste a Postgres, MySQL, or SQL Server query plan (the output of EXPLAIN or EXPLAIN ANALYZE) and the visualiser renders it as a collapsible tree with cost highlights. Operators with disproportionate cost stand out so you can see at a glance where the query is spending its time.
It's for DBAs, backend developers, and performance engineers chasing slow queries. Reach for it when a query's runtime has spiked, when investigating why an index isn't being used, or when teaching a junior dev to read plans.
How it works
Each DBMS has its own plan format - Postgres uses indented text or JSON (EXPLAIN (FORMAT JSON)), MySQL produces tabular or JSON output, SQL Server emits XML showplans. The visualiser detects the format from the input and parses to a unified tree of operators (Sequential Scan, Index Scan, Hash Join, Nested Loop, Sort, etc.).
Cost is displayed both absolutely and as a percentage of total - operators above a threshold are highlighted. The tree is collapsible so you can fold subtrees and focus on the hot path. EXPLAIN ANALYZE plans (with actual runtimes) show alongside estimated costs to spot estimator mismatches.
Examples
- Postgres plan (text):
Seq Scan on users (cost=0.00..18.50 rows=850 width=68) Filter: (active = true) - Postgres plan (JSON, snippet):
{"Plan": {"Node Type": "Seq Scan", "Total Cost": 18.50, "Plans": [...]}} - Highlight a slow node:
Sort (cost=12000 width=120) [WARN: 78% of total cost] -> Hash Join - EXPLAIN ANALYZE difference:
Estimated rows: 100 Actual rows: 50000 [estimator off by 500x]
FAQ
Should I use EXPLAIN or EXPLAIN ANALYZE?
EXPLAIN shows the plan without running the query (cheap). EXPLAIN ANALYZE actually runs it and reports actual times - more accurate, but the query executes (be careful with INSERT/UPDATE/DELETE).
Why is a Seq Scan sometimes faster than an Index Scan?
For small tables or high-cardinality predicates, scanning sequentially is cheaper than walking an index and fetching rows. The planner makes this choice based on statistics - run ANALYZE if your statistics are stale.
What does "buffers shared hit" mean in Postgres plans?
Pages read from cache. Use EXPLAIN (ANALYZE, BUFFERS) to see cache hits vs disk reads - a key signal for whether more memory would help.
Can it diff two plans?
The visualiser shows one plan at a time. Paste each plan into a separate session to compare visually.