Back to Projects
TalkToData - AI-powered SQL query interface converting natural language to SQL, supporting PostgreSQL, MySQL, SQLite, SQL Server, and MongoDB by Rutwik Patel
Live

TalkToData - Natural Language SQL

Next.js
TypeScript
Groq AI
Tailwind
View Live Project

The Challenge

Non-technical users need database insights but SQL is a barrier. Existing solutions are expensive (Text-to-SQL SaaS tools) or require complex setup. The goal was a lightweight, self-service tool that handles the 5 most common database dialects with zero configuration.

The Solution

Built a Next.js app with a Next.js API route that sends a carefully engineered prompt to Groq's llama-3.1 model. The prompt includes the user's schema context, target dialect, and few-shot SQL examples to constrain output to valid queries. A second AI call generates a plain-English explanation of the query. A third call handles error recovery — if the SQL fails syntax validation, it feeds the error back to the model for correction.

Architecture

Next.js 14 frontend → /api/sql route → Groq API (llama-3.1-8b-instant) with a 3-call pipeline: (1) NL→SQL generation with schema context, (2) SQL explanation, (3) error recovery if validation fails. Dialect-specific prompt templates for PostgreSQL, MySQL, SQLite, SQL Server, MongoDB.

Impact

  • Supports 5 database dialects — users switch between them with one click
  • Sub-200ms SQL generation via Groq's inference speed (fastest LLM API for this use case)
  • Error recovery loop fixes invalid SQL automatically — users rarely see raw errors
  • Deployed on Vercel with zero cold-start latency for the frontend
  • Schema-aware prompting means column names and table relationships are respected in output

What I Learned

  • Few-shot examples in the prompt reduced SQL syntax errors by ~70% vs. zero-shot — the model needs to see the dialect in action
  • Groq's llama-3.1-8b-instant was 3–5× faster than GPT-3.5 for this task and free-tier friendly, making it the right choice for a public demo
  • Streaming the AI response character-by-character felt much faster to users than waiting for the full SQL, even though total latency was the same