PEV2 — Postgres Explain Visualizer 2

A Vue 3 component that renders a PostgreSQL execution plan as a readable diagram, from Dalibo, the French Postgres consultancy. TypeScript, 3,562 stars, 194 forks, released under the PostgreSQL licence rather than MIT — the tool takes its subject's licence. Started 2019-08-05 and still moving: v1.23.0 shipped 2026-07-20, last commit 2026-08-11.

Read from the repository and its source (T1). The README is a usage document, so the substance below comes from the code — src/enums.ts in particular, which is where the tool's opinion about what matters in a plan is written down.

Three ways to run it, and the middle one is the interesting one

• Hosted: explain.dalibo.com, which Dalibo recommends and which also lets you share a plan with colleagues or customers.
• One file, offline: download pev2.html from the releases page and open it in a browser. The README's phrasing is "no installation, no network."
• Embedded: npm install pev2, or a UMD build from a CDN with Vue and Bootstrap CSS. It is a component, so a database tool can host it rather than reimplement plan rendering.

The offline single-file build matters more than a packaging note usually would. A Postgres plan carries the query text, table and column names, row counts and often literal values from the predicates — pasting one into a hosted service discloses schema and shape to a third party. Dalibo ships the local build without arguing this case, and the reason for it is my reading rather than their claim; but the option existing is what lets the tool be used on work that cannot leave the building.

What it decides is worth showing

Metric is a six-item enum, and it is a compact statement of what a plan reader should look at: time, rows, cost, buffers, estimate_factor, io.

The one that is not in Postgres's own output is estimate_factor, paired with an EstimateDirection of over or under. This is the planner's estimated row count measured against the actual, in both directions, and it is the diagnostic that usually explains a bad plan: the planner chose a nested loop because it expected 12 rows and got 400,000. EXPLAIN ANALYZE prints both numbers and leaves the arithmetic and the search to you. PEV2 computes the ratio, ranks nodes by it, and colours the worst ones — the tool's contribution is triage, not new information.

The same move shows up in the derived I/O metrics, which the code marks with a leading * to flag that Postgres did not report them: *I/O Read Speed, *I/O Write Speed, and per-scope variants for shared, local and temp buffers. Speeds are computed from bytes and timings the plan does report. A tool that adds its own columns on top of the engine's output is making a claim about what the engine should have told you.

Buffer accounting is broken out by location (Shared / Temp / Local) and by kind (Hit / Read / Written / Dirtied), which is the vocabulary for asking whether a query was served from cache or went to disk. Sort nodes report whether they ran in memory or on disk — the work_mem question, made visible. There are dedicated views for parallel workers, JIT compilation, and per-node I/O timings.

Highlighting is user-selectable across duration, rows and cost, so the same plan can be read three ways depending on whether you are chasing wall-clock, cardinality error, or planner cost.

Where it came from

The README is explicit that PEV2 is a rewrite of Alex Tatiyants' pev (2016), which it credits warmly and describes as abandoned: "no activity at all for more than 3 years and counting though there are several issues open and relevant pull requests pending." A consultancy adopting an orphaned community tool and maintaining it for seven years is a different sustainability model from either a vendor product or a volunteer project, and it is the reason this one is still shipping releases.

Why it belongs in this spoke

It is the second database-tooling source here, after awesome-db-tools — which is the condition synthesis.md's first open question set for reconsidering whether tooling deserves its own corner. It also narrows the tooling member's coherence problem rather than widening it: awesome-db-tools is a broad directory spanning OLTP, OLAP and NoSQL, while this is a single deep tool for one engine that this spoke already pages.

The closest relative in the corpus is not a Postgres thing at all. cross-shard-queries records Vitess's VEXPLAIN TRACE, which reports ShardsQueried per operator, and VEXPLAIN KEYS, which names the columns that would stop a query scattering. Same genre — an instrument that makes the planner's decisions legible — at a different scope. Vitess's question is which machines answered; PEV2's is which node in one process was wrong about how much data it would see. Between them the spoke now has plan-reading instruments at both ends of its embedded↔distributed axis, and neither one is a benchmark.

Related

postgresql · query-execution-plan · awesome-db-tools · cross-shard-queries · online-transaction-processing