Work/ Dialect AI

A SQL studio that asks the schema, not the whole database

Engineers were pasting schemas into chatbots and watching the prompt explode. We built a workbench that prunes the right tables, then writes dialect-aware SQL.

Client
Dialect AI
Year
2026
Role
Product — SQL studio + schema RAG
Result
NL2SQL that survives a real schema
A SQL studio that asks the schema, not the whole database

The problem

Naive NL2SQL dumps the whole schema into the model. On a real database that is a 413 — token limit, not a clever answer. Desktop GUIs don’t help either: they run SQL, they don’t know which twelve tables the question actually needs. Teams behind a VPN often have a Prisma file and no live connection at all.

The approach

We treated the schema as a graph, not a blob. Every dialect — Postgres, MySQL, SQLite, plus CSV via DuckDB in the browser — normalises to one contract. Before the model sees anything, a local embedder ranks tables, walks one foreign-key hop, then clamps to a token budget. Offline import (Prisma, DDL, JSON) is a first-class mode, not a demo.

The solution

A Vue 3 studio (Monaco, results grid, ERD, copilot) talking to a Fastify API. Connections are per-user. Read-only guards sit on the same path as the AI. Groq writes, explains, and fixes SQL. Embeddings stay local so we don’t pay a second vendor for vectors. Writes don’t sneak through because someone phrased the prompt aggressively.

The result

The studio runs against live databases: connect, prune, generate, explain, copy out. Large hub-and-spoke schemas no longer blow the prompt. You can import a shape with no live DB, get SQL, and take it back to the real engine. Public demo is still coming. The product already does the job.

Next

Have a similar problem?

If the brief sounds close, send it. We’ll say quickly whether we can help.