aisqlgen: The AI SQL Notebook That Edits, Not Just Generates

A local-first Next.js tool that narrows schemas before prompting, remembers prior query edits, and turns raw database answers into charts.

8 min read • View on GitHub • More from marblexyz

A wide desk scene shows a SQL notebook at the center, with messy database tables piled on one side and a clean query plus chart forming on the other. A small assistant machine passes cards back and forth between them, explaining that the tool behaves like an iterative notebook instead of a one-shot prompt box.
aisqlgen treats SQL as a living artifact. The value is not just generation, but revision, memory, and a path from query to chart.
Key Takeaways

Most AI SQL tools try to solve a narrow problem: turn a question into a query. aisqlgen tries to solve a broader one: make SQL feel like an iterative analysis session. It lets you generate a query, edit it conversationally, keep the earlier versions in view, and then turn the result into a chart.

Autogenerate SQL and visualization using AI - GitHub AI SQL Gen. Don't write SQL by hand. Use LLMs to link to your SQL database, then generate, edit SQL, and auto-generate visualization. Run it locally.

Project Documentation, Maintainer · marblexyz/aisqlgen README

SQL, But Treated Like a Notebook

That notebook model is the project’s real differentiator. A query is not a disposable prompt response. It is a working object that can absorb feedback, manual edits, and follow-up instructions without losing the thread of the analysis.

The repository’s own framing makes this explicit. The UI is meant to support databases that are not clean demo datasets, and it expects users to refine real queries by hand when the model gets close but not quite right.

That matters because the best SQL work is rarely one-shot. Analysts often start with an approximation, inspect the result, and then tighten the logic. aisqlgen turns that habit into the product itself.

The Trick That Makes Large Schemas Work

The key idea is not just smarter prompting. It is shrinking the schema before the query is written, which keeps the model focused when the database is large.

A close-up machine accepts a flood of table drawers on one side, filters them down to a handful of relevant drawers, and then assembles a precise SQL query from the reduced set. A thin rail carries previous edits beside the main path, showing that the system narrows context without losing history.
The sequential table-selection step is the project’s most useful technical trick. It protects the context window before SQL generation begins.

This is the part of the repo that feels less like product polish and more like systems thinking. Instead of dumping the entire schema into a single prompt, aisqlgen first asks which tables matter, then sends only the narrowed set forward. That keeps the LLM working on the right slice of the database instead of drowning in metadata.

The effect is simple but important. Smaller context means fewer distractions, fewer token costs, and better odds that the query matches the actual schema.

Why the Tool Feels Local, Not SaaS

The architecture reinforces that feeling. The frontend is a Next.js app, but the database drivers and LLM prompt logic live in local Node code. API routes bridge the UI to the database layer, and browser persistence keeps config around without a remote backend database.

That is not just a privacy story, although privacy is part of it. It is also a control story. The user is working against their own databases, with their own credentials, in a loop that does not require shipping state off to a hosted platform.

Frontend (Next.js UI)
  -> local Node API route
     -> database driver (Postgres / ClickHouse / SQLite)
     -> schema introspection
     -> LLM prompt
     -> SQL result
     -> optional Chart.js output

State such as API keys and datasource config is persisted locally in the browser.

That local-first shape makes the tool feel immediate. It behaves like a utility sitting beside the database, not a service sitting between you and it.

Visualization Is Not an Afterthought Here

The chart step is where the notebook metaphor extends beyond query writing. getChart.ts asks the model to write Chart.js code from the query results, which means the analysis can move from question to SQL to picture without leaving the workflow.

That is powerful because it collapses a lot of friction. It is also risky, because generated JavaScript needs cleanup and guardrails. The repo acknowledges that by cleaning the generated code before rendering it.

// Simplified shape of the chart workflow
const chartCode = await getChart({
  data: rows,
  canvasId: "chart"
});

// The generated code is cleaned before being injected into the page.
const safeChartCode = sanitizeChartCode(chartCode);

In other words, the chart is not a separate feature bolted onto SQL generation. It is the final move in the same analytical loop.

Where It Sits in the Text-to-SQL Landscape

The comparison is useful because it clarifies the niche. aisqlgen is not trying to be a full BI suite, and it is not just a thin wrapper around a prompt. It sits between direct generators and broader analytics platforms, with a stronger emphasis on local control and iterative editing.

ProjectWorkflow styleLocal-firstManual SQL editingVisualizationSchema handlingPrimary fit
aisqlgenIterative notebookYesYesYes, Chart.jsTwo-step narrowingHuman-in-the-loop SQL exploration
Text2SQL.AIPrompt to queryUsually noLimitedBasic or externalSingle-pass promptSimple text-to-SQL tasks
Vanna.AIFrameworkDepends on deploymentCustomizablePossible via frameworkDeveloper-definedBuilders who want to assemble a system
AI2sqlHosted generatorNoSomeSupportedPrompt-centricPolished SaaS query generation
Hex / BI toolsAnalytics workspaceOften partialYesYesWorkspace-dependentBroader analysis and collaboration

That positioning is the point. aisqlgen is not trying to replace a database analyst. It is trying to make the analyst’s real workflow faster: explore, revise, inspect, visualize, repeat.

What aisqlgen Suggests About the Future of SQL Tools

The project hints at a healthier model for AI data tools. The future is probably not a single perfect prompt that spits out the final query. It is a collaborative loop where the model helps navigate schema, drafts the SQL, remembers the edits, and hands the user something they can still trust and change.

That is a more modest promise, but also a more believable one. For real databases, the win is not magical automation. It is reducing the distance between a question, a query, and an answer.