This time, I am going to share my small experience in developing SQL AI Agent.
In today’s data-driven world, accessing databases and retrieving information efficiently is crucial.
However, not everyone is proficient in SQL.
Especially, businesses often struggle to extract insights from their data without technical help.
SQL Agent makes that barrier disappear-giving non-technical users easy, secure, and fast access to complex analytics.
That’s where SQL agents come in.
> What is a SQL Agent?
SQL agents bridge the gap between natural language and structured database queries. They allow users technical or not to ask questions in plain English and receive answers derived from complex relational data.
This post shares my experience building a SQL LLM Agent: a system that takes natural language queries, converts them into SQL, runs them on a large PostgreSQL database, and returns human-readable responses.
> Project Requirements
To meet modern enterprise demands, the system was designed with the following capabilities:
Large Database Support: Designed to handle PostgreSQL databases with 100+ relational tables and hundreds of gigabytes of data.
High Concurrency: Supports 50–100 concurrent users without slowing down.
Performance-Centric: Low latency and fast response times are key, even under heavy load.
Token Efficiency: Optimized to minimize token usage with LLMs — reducing cost and improving speed.
Caching: Implements Redis and in-memory caching to store frequently asked queries and results.
Asynchronous Processing: Handles simultaneous user queries using async I/O and task queues.
Natural Language Interface: Users can interact in plain English — no SQL knowledge required.
Smart Query Handling:
Translates natural language into optimized SQL
Executes queries on PostgreSQL
Summarizes the results in clear, readable natural language
Tech StackBackend Framework: FastAPI
Database: PostgreSQL (100+ tables, hundreds of GBs)
Caching: Redis
Task Queue: Celery
Containerization: Docker + Docker Compose
Agent Framework: LangChain + LangGraph
LLM: OpenAI (GPT-4 / GPT-4o)
System Architecture Overview
The SQL LLM Agent is an intelligent, scalable pipeline that transforms natural language queries into executable SQL and returns the results in a conversational format.
> Core Components
FastAPI Application
Hosts the /api/query endpoint
Dockerized with auto-reload (port: 8000)
SQL Agent (Main Engine)
Defined in app/agents/sql_agent.py
Powered by LangGraph’s StateGraph to control multi-step processing
Connects language models with real-time database operations
Database Layer
Uses PostgreSQL with SQLAlchemy (AsyncSession) for non-blocking queries
Caching System
Redis stores previously run queries and their results
Reduces redundant LLM and DB calls
TTL-based memory cache handles hot data
LLM Integration
OpenAI’s GPT-4 / GPT-4o is used for:
Translating NL to SQL
Summarizing SQL output in plain English
Auto-correcting faulty SQL
-Generating follow-up questions
> LangGraph Workflow
The agent follows a directed graph workflow using LangGraph, broken into these modular steps:
choose_tables - Identifies relevant tables from user query
get_ddls - Converts NL query to SQLgenerate_sql - Executes the SQL and handles errors or retries
suggest_followups - Offers relevant follow-up questions
Deployment Architecture
Deployed using Docker Compose with three primary services:
> Service Role
app - FastAPI backend (exposes port 8000)
db - PostgreSQL container with persisted volume pgdata
redis - In-memory cache for faster data access
> Key Features
High Performance: Handles large-scale databases under heavy load.
Smart Caching: Avoids repeated work using Redis and memory-based -caching.
Error Resilience: Automatically corrects broken or malformed SQL queries.
Schema Introspection: Dynamically understands and adapts to the DB structure.
Conversational Interaction: Natural language input and output, no SQL required.
Modular Workflow: Built on LangGraph for flexible, stateful processing.
> Final Thoughts
This project was a powerful learning experience that combined LLMs, database engineering, performance tuning, and API design. It’s a strong step toward democratizing data access — making it simple, fast, and intuitive for everyone.
If you’ve ever struggled with getting insights from a complex database or want to make your data more accessible to business teams — this is the direction to explore.
Let me know what you think or if you’re building something similar — I’d love to connect!