AskDB
Side ProjectTalk to your database in plain English. Natural language to SQL with safety guardrails.
Try the Demo
Query a database in plain English
Problem & Context
Non-technical team members constantly ask developers for "quick queries." Product managers need user counts, support needs ticket stats, marketing needs conversion data. Each request interrupts deep work.
AskDB lets anyone query a database by asking questions in plain English. The AI generates safe, read-only SQL and returns results with explanations. No SQL knowledge required.
Constraints
- Safety: Generated SQL must never modify data or expose sensitive information
- Accuracy: Wrong queries waste time; users need to trust the results
- Schema complexity: Must handle diverse database schemas without manual configuration
- Latency: Natural conversation requires sub-2-second response times
- Explainability: Users should understand what query was run and why
Solution Overview
- 1. Question"How many users signed up this month?"
- 2. Schema IntrospectionTables, columns, relationships
- 3. AI SQL GenerationGPT-4 with few-shot examples
- 4. Read-only ExecutionSELECT-only permissions
- 5. Results + ExplanationData with plain-English summary
User asks a question → system introspects schema → OpenAI generates SQL → query runs on read-only connection → results displayed with the SQL and explanation.
Safety Architecture
- Database Level — Read-only user with SELECT-only permissions
- Query Validation — Regex patterns block dangerous keywords
- Schema Filtering — Sensitive tables excluded from introspection
Example Output
-- Generated SQL (read-only)
SELECT COUNT(*) as signups
FROM users
WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)
AND created_at < DATE_TRUNC('month', CURRENT_DATE) + INTERVAL '1 month';
-- Explanation: Counts all users created in the current
-- calendar month using PostgreSQL date functions.Key Decisions
Read-only connection enforcement
Database connections use a read-only user with SELECT-only permissions. Even if the AI generates a DROP TABLE, the database rejects it. Defense in depth.
Tradeoff: Can't support write operations even when legitimately needed, but eliminates entire category of risk.
Schema introspection + few-shot examples
Before generating SQL, the system introspects the database schema and includes relevant table/column info in the prompt. Combined with few-shot examples of good queries for the specific schema.
Tradeoff: Larger prompts = more tokens = higher cost (~$0.02/query), but dramatically better query accuracy.
Query explanation alongside results
Every response includes the generated SQL with syntax highlighting and a plain-English explanation of what it does. Users can verify before trusting the data.
Tradeoff: More verbose output, but builds trust and helps users learn SQL patterns.
What I'd Improve
- Add query history and favorites
- Implement chart/visualization generation for aggregate queries
- Support for multiple database types (MySQL, SQLite)
- Add collaborative features for team query sharing