What a text-to-SQL layer actually needs
Nine parts, each of which a demo can skip and production cannot.
1. Schema and semantic context
The model can only pick the right column if names mean something; amt_2 means nothing to it. The layer needs, per dataset: business names for columns, which are measures, dimensions and dates, how metrics are defined (is revenue gross or net), and the values a filter is likely to need (“EMEA”, not “Europe”).
In Superset much of this lives on the dataset already (column labels, descriptions, temporal flags, saved metrics), and in most deployments it is half filled in. Expect the first real cost to be curating the semantic layer you thought you had.
2. Dataset selection
Three hundred datasets will not fit in every prompt, so the layer must choose candidates first, through retrieval over descriptions, a curated allow-list of “askable” datasets, or both. A wrong choice produces valid SQL against the wrong table, which is the hardest error to spot. A short allow-list of well-described, certified datasets beats retrieval over everything.
3. SQL or query generation
There are two designs, and the choice shapes everything downstream.
- Generate raw SQL. Most expressive: joins, window functions, anything the dialect supports. Also the hardest to govern, because the output is arbitrary text that you must check before it runs.
- Generate a structured query. The model fills in a constrained object (dataset, metrics, group-by columns, filters, time range, row limit) and your code turns it into a query. Less expressive, far easier to validate, and it maps directly onto how Superset charts already query datasets.
4. Validation and guardrails
Before execution: parse the SQL, reject anything but a single read-only statement, check every referenced table is in the selected set, and enforce a row limit and timeout. After execution: catch empty or implausible results, and know when to answer “I can’t answer that from this data” instead of drawing a confident chart. Treat user text and column values as untrusted input that cannot change what the layer may do.
5. Execution through Superset’s datasets and permissions
If generated SQL runs on a service account with broad warehouse access, it bypasses every role, dataset grant and row-level security rule you have built. The query has to run as the asking user, through Superset, so its permission checks and RLS predicates apply.
6. Chart-type selection
A correct number in the wrong chart still reads as a wrong answer: trends want lines, single values want a big-number tile, wide results want a table. Use rules on the result’s shape, or a model choice constrained to the Superset visualization types you support, so you can save the answer as a real chart.
7. Follow-up context
Questions come in threads: “revenue by region last quarter”, then “just EMEA”, then “compare with last year”. Passing the whole chat history to the model is expensive and unreliable; keeping an explicit query state (dataset, filters, measures, time range) and letting the model edit it works.
8. Cost and latency
One question can mean several model calls (selection, generation, a repair after a failed validation, a summary) plus warehouse time. Cache repeated questions, keep schema context short, use a smaller model for routing, and decide who pays the model bill.
9. Evaluation
The part internal projects skip. Keep a test set of real questions with known-correct answers and run it on every prompt, model and schema change, or you will learn that last week’s column rename broke the finance questions when someone presents a wrong number. Log real questions from day one.
What building it in-house on Superset involves
Superset gives you the execution and permission half of the problem. The language half is yours.
The REST API path
Superset’s REST API (documented at /swagger/v1 on your own instance and in the official API reference) has the endpoints an in-house layer needs:
| Need | Endpoint | Notes |
|---|---|---|
| Read dataset context | GET /api/v1/dataset/ and GET /api/v1/dataset/{id_or_uuid} |
Columns, metrics and descriptions to build the schema prompt |
| Run a structured query on a dataset | POST /api/v1/chart/data |
Takes a query context (dataset, metrics, columns, filters, time range); runs through the dataset with RLS applied |
| Run raw SQL | POST /api/v1/sqllab/execute/ |
Requires SQL Lab permission; RLS applies here only when the RLS_IN_SQLLAB feature flag is on |
| Save the answer as a chart | POST /api/v1/chart/ |
Creates a chart with a viz_type and params users can open in Explore |
The design consequences follow directly from that table:
- The structured path is the safer default.
POST /api/v1/chart/dataexecutes against a dataset the way a chart does, so dataset permissions and row-level security rules apply without extra work. The dataset limits what you can ask, which is exactly the constraint you want for business users. - The raw SQL path needs more care. SQL Lab execution means the user (or the account the layer calls with) needs SQL Lab access, and per the Superset security docs Superset enforces RLS in SQL Lab only when you enable
RLS_IN_SQLLAB. Keep the database’s Allow DML setting off for any connection the layer can reach, and still validate SQL yourself. - Call as the user, not as a service account. Whatever authenticates your layer to Superset decides whose permissions apply. If it is one powerful account, you have rebuilt the bypass described above. Your role model and, for embedded or multi-tenant setups, your row-level security design are only as good as this choice.
The MCP server path
Superset 6.1 added a built-in Model Context Protocol server. Per the official MCP server docs, it runs as a separate process (superset mcp run --host 127.0.0.1 --port 5008), exposes tools such as list_datasets, get_dataset_info, query_dataset, execute_sql, generate_chart and get_chart_data, and respects Superset’s role-based access control, so each authenticated user reaches only what their roles allow. Those docs cover the next Superset version, so check what the release you run ships before designing around it.
It is a real shortcut for the plumbing, but dataset curation, guardrails beyond RBAC, follow-up state, chart choice, model cost and evaluation are still yours. Treat it as a well-governed tool interface, not a finished natural-language feature.
The front end and the operating work
Business users will not live in a developer’s MCP client. Someone builds the question box, the answer view, the “show me the SQL” toggle analysts insist on, and the feedback button that feeds the test set. Then someone runs it: prompt and model changes, provider outages, the eval suite, the cost report. Plan for a small team over a few months for the first version and part of one person’s time to keep it accurate.
Where a managed AI layer fits
A managed option trades control for time: someone else has built the profiling, generation, guardrails, chart selection, follow-ups and front end, and keeps them working. DashboardGPT, built by Andolasoft, is one such option.
What DashboardGPT does
What it is. DashboardGPT is Apache Superset 6.0 hosting that we manage, with an AI layer on top. Business users ask questions in plain English and get charts, with the visual type matched to the answer and a written insight explaining the result and the numbers behind it. Query execution and chart rendering run on Superset 6.0. The platform profiles columns automatically into dimensions, measures and time grains, so a dataset is askable without writing a semantic model first. Selecting an answer on the canvas and asking a follow-up carries its filters, measures and time range into the next question. Answers sit on an infinite canvas as movable nodes rather than grid tiles.
How data gets in. CSV and Excel upload with no schema definition, and warehouse connections on paid tiers.
Data privacy and deployment
What goes to the model. Per the DashboardGPT security page, the question and a description of the relevant schema go to the configured AI provider. DashboardGPT does not send row-level data to the model: the query runs in the analytics layer, which returns only aggregates. You can bring your own AI provider key, held encrypted and scoped to the workspace. We use TLS for traffic and encrypt stored data at rest.
Deployment. Managed cloud by default, on-premise through Docker Compose or Kubernetes, and air-gapped installs that point at local models through OpenAI-compatible APIs such as Ollama or vLLM.
Limits to weigh before you choose
The limits, stated plainly.
- It does not connect to your existing Superset instance. It is a separate managed Superset 6.0 workspace. Your current dashboards, datasets, roles and RLS rules do not carry over automatically, and it is not a plugin for the Superset you already run.
- It does not inherit your governance. Access runs through its own workspaces and workspace roles, so questions that depend on your existing row-level rules argue for building.
- It is an early-stage product. It describes the controls it has today and holds no formal certifications. If your procurement requires SOC 2 or ISO 27001 from day one, that rules it out for now.
For a team already on Superset, two patterns make sense: keep your Superset for governed dashboards and use DashboardGPT for the ad-hoc questions that now become analyst tickets, or, if you were already weighing whether to keep self-hosting, move to managed hosting and get the AI layer with it.
From the Andolasoft team: DashboardGPT
Test plain-English questions before committing to a build
DashboardGPT is a managed Apache Superset 6.0 workspace with an AI layer. Upload a CSV on the free Explore plan, ask your users’ real questions, and see how far a managed layer gets before you staff a project.
Build vs buy: the decision table
| Factor | Build on your Superset | Managed AI layer (e.g. DashboardGPT) |
|---|---|---|
| Time to first useful answer | Weeks for a pilot, months for production | Same day on uploaded data |
| Uses your existing datasets, roles and RLS | Yes, if queries run as the user through Superset | No; separate workspace with its own roles |
| Semantic context | Your dataset metadata, which you curate | Automatic profiling of columns |
| Guardrails, follow-ups, chart choice, UI | You design, build and maintain them | Included |
| Evaluation and accuracy upkeep | Your test set, your team | Vendor’s product work, plus your own spot checks |
| Data sent to the model | Whatever your design sends | Question plus schema description; aggregates only, no row-level data |
| Model choice and cost | Fully yours | Bring your own key; local models on on-premise installs |
| Deployment | Wherever your Superset runs | Managed cloud, on-premise, or air-gapped |
| Compliance evidence | Inherits your platform’s | No formal certifications yet |
| Ongoing ownership | A product with a part-time owner | A subscription and a workspace admin |
A short way to read it:
- Build if the answers must respect governance that only exists in your current Superset, if the questions span a complex model, or if you have a team that wants to own an AI feature for years.
- Buy if the main demand is ad-hoc questions on a bounded set of data, if speed matters more than reusing existing rules, or if no one on the team should become the owner of an LLM pipeline.
- Pilot both cheaply if unsure: run fifty real questions on a managed workspace with an extract, and prototype the structured-query path on two or three of your best datasets. The test set is useful either way.
Frequently Asked Questions
Does Apache Superset have built-in natural-language querying?
Not as a finished end-user feature. Superset 6.1 adds a built-in MCP server that lets AI assistants query datasets and create charts within the user’s permissions. Curation, guardrails, follow-ups, a business-user interface and evaluation are still yours to build or buy.
Is it safe to let an LLM write SQL against our warehouse?
Only with the right execution path. Run generated queries through Superset as the asking user so dataset permissions and RLS apply, prefer structured queries against datasets over raw SQL, keep DML disabled on reachable connections, enforce row limits and timeouts, and validate statements before execution. Never give the layer a service account with broader access than the person asking.
Can DashboardGPT add AI to our existing Superset deployment?
No. DashboardGPT is its own managed Apache Superset 6.0 workspace and does not connect to an existing Superset instance. Teams already on Superset typically keep their deployment for governed dashboards and use DashboardGPT for ad-hoc questions, or move to managed hosting altogether.
How do we measure whether text-to-SQL answers are accurate?
Keep a test set of real questions with verified answers, run it on every prompt, model and schema change, and track the pass rate. Add failed production questions to the set as users flag them.
Build It With Andolasoft
We help teams decide this and then do whichever half they choose. Through Superset Consulting we curate the datasets and metadata a natural-language layer depends on, design the execution path so it runs inside your roles and RLS, and build the generation, guardrail and evaluation pieces on Superset’s API or MCP server. Our AI services team handles model selection and self-hosted model setups, and an architecture review is the quickest way to find out whether your permissions are ready to sit under an AI layer. If you would rather not own any of it, DashboardGPT is the managed route, and Managed Support keeps your existing Superset running alongside it.
If someone has asked whether users can just ask questions and need an answer you can defend, talk to us. We will look at your datasets, your permission model and the questions people actually ask, and tell you which route fits.