Built a PostgreSQL EXPLAIN analyzer that doesn't use AI
The frustration
Last month I was debugging a slow query at work. The EXPLAIN output was 400 lines of JSON. I tried three different "AI-powered" analyzers. Two of them suggested adding an index that already existed. The third hallucinated a table name that wasn't in my database.
I just wanted to know: where did the time actually go?
The realization
Current tools fall into two camps:
AI wrappers - Send your query plan to OpenAI, get generic advice
Visualizers - Pretty graphs, but you still need to interpret them
Neither tells you "4.5 seconds were spent in triggers, 0.03ms in the actual scan."
The build
So I built PlanCheck with one rule: truth only.
No AI. No API calls. No "smart" suggestions.
100% client-side. Your query plans never leave the browser.
Hardcoded rules based on actual PostgreSQL behavior.
I spent 3 weeks creating test cases for edge cases most tools miss:
JIT compilation overhead (700ms to save 100ms)
Bitmap heap scans with 99.9% recheck discard
Recursive CTEs looping 100k times
Trigger amplification (4.5s in triggers, 0.03ms in scan)
Partition pruning failures (53M rows scanned, 1 returned)
The technical challenge
Parsing EXPLAIN output in the browser sounds easy. It's not.
PostgreSQL has 40+ node types. Each has different fields, metrics, and edge cases. I had to handle:
TEXT format (messy indentation, inconsistent fields)
JSON with null values (missing timing data)
"Never executed" nodes that shouldn't be flagged
Deep nesting (4+ levels of nested loops)
All while keeping the bundle size under 200KB so it loads fast.
What I learned
The hardest part wasn't the parsing. It was deciding what not to say.
When a tool suggests "add an index," it's guessing your intent. Maybe you want that full table scan for analytics. Maybe the index exists but PostgreSQL chose not to use it.
So PlanCheck only reports measurable facts:
"Scanned 1M rows sequentially"
"Trigger took 4.5s, scan took 0.03ms"
"Index returned 15k rows, recheck discarded all"
You decide what to fix.
The launch
It's live at https://plancheck.dev
Free. No signup. Paste your EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) output.
What I need
I'm looking for edge cases I haven't tested yet. If you have a query plan that breaks it, I want to see it.
What's the weirdest EXPLAIN output you've seen?
"The hardest part wasn't the parsing. It was deciding what not to say." — This is the insight that separates useful tools from noisy ones.
The AI hallucination examples (suggesting an index that already exists, inventing table names) perfectly illustrate why deterministic, rule-based analysis still has a place. LLMs are great at pattern matching, but terrible at precision when you need exact facts about your specific system.
The 100% client-side approach is smart for two reasons:
Curious about distribution: How are you reaching PostgreSQL DBAs? Hacker News would probably love this, but also wondering if there are specific communities (PG mailing lists, Slack groups for DB engineers) where this would resonate.
The "free, no signup" model is a strong trust signal for dev tools. Have you thought about a monetization path, or is this more of a portfolio project / lead-gen for consulting?
Thanks for the thoughtful feedback.
Distribution is really the hard part. Posted to r/SQL (removed for self-promotion), trying IH now. HN is next.
Re: monetization, not sure yet. Currently just building trust. Thinking freemium: free for basic analysis, paid for team features (saved history, sharing, CI integration). Want this to be a real product.
Any PostgreSQL communities you'd recommend? The mailing lists feel intimidating for a first post.
The r/SQL removal is frustrating but predictable — most subreddits have hair-trigger self-promotion filters. HN is definitely worth the shot; they tend to appreciate "I built X because Y was broken" stories, especially with technical depth like yours.
For PostgreSQL communities that are less intimidating than the official mailing lists:
The freemium model makes sense. CI integration is a strong paid feature — teams that care enough about query performance to integrate into CI will pay for it. Saved history + sharing is the natural "team unlock."
One thing I've seen work: offer the first N analyses free with no signup, then require an account (still free) to continue. Builds habit before asking for commitment.
Good luck with the HN post — the technical detail in your original post should resonate there.
Thanks for the detailed advice!
PostgreSQL Discord sounds like the perfect starting point - less intimidating than mailing lists.
Re: the habit-building tip - that's exactly what I was thinking. Let people try it, see value, then unlock features.
Will post to HN Monday. Fingers crossed!
Monday is a solid day for HN — good timing.
Drop the link here when you post. Would love to see how it lands. Tools that solve a real itch tend to do well there.