speeDB — grounded DB query optimiser

speeDB reads a GitHub or GitLab repository, finds every database query in it, and proposes rewrites that run faster while returning exactly the same results. The hard part is not generating suggestions — it is trusting them. An AI will happily suggest an index on a table it never saw, citing a migration file that does not exist. speeDB treats that as the central risk: EVERY SUGGESTION IS CHECKED BACK AGAINST YOUR CODE BEFORE YOU SEE IT Each cited file path, line range and quoted schema is re-verified against the bytes actually fetched from your repository. A suggestion that cites a file which does not exist is dropped, and the number dropped is shown in the report rather than hidden. Anything that half-checks out is badged "needs check", with the specific reasons listed. SAME-OUTPUT CHANGES AND BEHAVIOUR CHANGES ARE NEVER MIXED Optimisations asserted to return identical results live in their own section, each with an explicit equivalence argument covering rows, columns, ordering, NULL handling and duplicates. Real bugs and improvements that do change results are listed separately, so applying one is always a deliberate decision. WHAT IT FINDS Missing and redundant indexes, N+1 query patterns, avoidable round trips, over-fetching, unbounded result sets, plan-cache misses from concatenated SQL, implicit casts that defeat an index, in-memory sorts, missing batching, and mishandled transaction scope. WHERE IT WORKS speeDB is not SQL-only. It covers relational databases, distributed SQL, cloud warehouses, document and wide-column stores, key-value caches, and search, graph, vector and time-series engines. Each family is analysed under the rules that actually apply to it, rather than having relational assumptions applied to a store that does not share them. That distinction matters most for vector search, where results are approximate: changing a search parameter changes recall, so speeDB classifies any recall-affecting change as behaviour-changing rather than as a same-output optimisation. A faster query that returns different neighbours is a regression, not an improvement. Most database work in a real service is not a SQL string. Object-relational mappers build queries from method calls, so there is nothing for a text search to match. speeDB reads those call chains directly — counting round trips and comparing the fields each version fetches — and suggests the profiling tool that fits the stack you are using, rather than offering a SQL command you cannot run. VERIFY IT YOURSELF speeDB never executes a query and has no database connection, so it does not claim to have measured anything. Instead each finding separates what was counted from the two versions from what cannot be known without a real database, and hands you the exact command that settles it — along with what the output should show if the finding is right, and what would show it is wrong. BRING YOUR OWN AI — OR NONE AT ALL • Chrome built-in AI (Gemini Nano) — runs on device, nothing is uploaded • Anthropic, OpenAI or Google Gemini with your own API key The model list is read live from your key, so new models appear without waiting for an extension update. Permission to contact a cloud provider is requested only when you select one — choose Chrome built-in AI and speeDB never gains it. PRIVACY There is no speeDB server, no account and no analytics. API keys and access tokens are held in session memory by default and are never written to disk. Full policy is bundled with the extension. HOW IT WORKS 1. Open the side panel on any GitHub or GitLab page — the repository fills itself in 2. Pick your AI provider, or use Chrome's built-in model 3. Scan 4. Read the report, then export it as Markdown, HTML or JSON Results are cached for 60 minutes per commit, so reopening a report costs nothing. "Rescan without cache" forces a fresh analysis at any time.