TuneQL

PostgreSQL optimization workbench
Verified optimization
Create Workspace
WebMCP agent actions
Optimization constraints
Execution plan

Why I built it

AI can suggest a SQL fix, but it can’t really prove that the fix actually made things better. I’d still have to open a database tool, check the execution plan, run some benchmarks, and manually make sure the result is still correct.

So I built TuneQL to keep all of that in one place.

What TuneQL does

TuneQL is basically a PostgreSQL query optimization workbench that runs in the browser using PGlite.

You can inspect the schema, run queries, check EXPLAIN ANALYZE, save a benchmark as a baseline, then change the query or indexes and compare the new version with the old one.

It shows what changed, how much faster or slower it got, whether the constraints still pass, and if both queries return the same result.

WebMCP

The same workspace can also be used by an agent through WebMCP.

TuneQL gives the agent tools to read schemas and indexes, explain and benchmark queries, create indexes, change SQL, save baselines, and compare the results.

And whatever the agent does also shows up in the UI, so you can actually follow what it’s doing and continue from the same state yourself.

How I built it

TuneQL uses Next.js, React, TypeScript, PGlite, Zustand, and IndexedDB. PostgreSQL runs inside a browser worker, and the workspace data stays on your device.

The UI and all 20 WebMCP tools go through the same command layer, so things like query validation, constraints, benchmarks, activity history, and revision checks behave the same in both places.

Challenges and learning

One of the harder parts was keeping the PGlite worker, saved workspace, UI, and agent actions all in sync.

I also realised pretty quickly that you can’t judge an optimization from just one timing. So TuneQL does a few warm-up runs, runs the benchmark multiple times, and checks the full result instead of just comparing the few rows shown in the preview.