I built a VS Code extension that lets you chat with your database - everything runs locally

I spent a week onboarding into a project with a SQL Server database I'd never seen before. Dozens of stored procedures, no documentation, and the previous dev had left. I kept thinking — why can't I just ask this database what it does?
I couldn't find a tool that solved that specific problem, so I built one.
SchemaSight is a VS Code extension that connects to SQL Server, PostgreSQL, or MySQL, crawls your schema, and lets you ask plain English questions about it. What does this procedure do? What tables are involved in invoicing? Is there row-level security anywhere? It answers from the indexed schema itself — no live query execution, nothing leaves your machine.

How it works under the hood

When you crawl a database, the extension walks every table, view, stored procedure, and function, summarizes each one using your local Ollama model, embeds those summaries with Transformers.js (all-MiniLM-L6-v2) running entirely in Node.js, and stores everything in LanceDB.

At query time, a QueryClassifier first decides what kind of question you're asking — broad ("what is this database about?"), semantic ("what tables relate to orders?"), or a detail request ("explain this specific procedure"). Broad queries fetch all indexed chunks. Semantic queries run hybrid search — combining vector similarity and full-text search, merged and reranked with LanceDB's built-in RRF reranker. Detail requests resolve the referenced object and inject its full definition straight into the prompt.
There's also a "How this was answered" panel that shows exactly which chunks were retrieved — no black box.

A thing I got wrong early on
I tried a two-model setup: a smaller model to handle indexing summarization (faster, cheaper), and a larger one for chat. Seemed sensible.
It wasn't. The smaller model's summaries were just weak enough that the larger chat model couldn't recover from the bad retrieval context. The answers degraded in ways that were hard to debug. I scrapped it and went back to a single model for everything — llama3.1:8b as the default — with a warning if you pick something lighter. Sometimes the boring solution is the right one.

Why local-first
A lot of databases SchemaSight is built for — legacy systems, internal tooling, anything with real business logic — you genuinely can't send to a cloud API. Stored procedures often contain sensitive logic and real data shapes. Running through Ollama on your own hardware sidesteps that entirely. No API key, no subscription, no data going anywhere.

Getting started

1. Install and start Ollama
2. Install SchemaSight from the VS Code Marketplace
3. Add a connection and follow the onboarding flow — it walks you through Ollama verification, model pull, and schema crawl in one place

One honest caveat: initial indexing summarizes every schema object using your local LLM. On my M5 MacBook Pro with ~95 objects it takes 15–20 minutes. It's a one-time cost though — you only re-index when your schema changes or you swap models.

The code is on GitHub under MIT. Happy to hear feedback or answer questions in the comments.