Air-Gapped AI Analytics: Apache Superset with Local LLMs (Ollama and vLLM)

 

Somebody senior has seen a demo. A business user types “which branches had the worst collection efficiency last quarter” and a chart appears. Now they want it in your bank, your ministry or your hospital. The demo used a public model API. Your network does not allow that. Your regulator would not accept it, and your security team stopped reading at the word “OpenAI”.The blocker is narrower than it looks. AI analytics is not impossible in a closed network; one specific payload, the prompt, has to stay inside. This post describes how we design for that. Apache Superset does what it already does well, with a text-to-SQL service in front of it. In addition, a model server you run yourself exposes the same API shape the public providers use.

Why the prompt is the blocker ??

A text-to-SQL request is not just the user’s question. To write SQL that runs, the model needs to know what exists. For example, the model needs table and column names, types, and which columns are measures or dimensions.

It often also needs metric definitions and the conversation so far. For a regulated organisation every part of that is sensitive:

• The question. “Show NPA movement for accounts linked to customer group X” names a customer group. Questions leak intent, investigations and names.
• The schema. Column names such as aadhaar_hash or diagnosis_code describe what you hold and how you process it. Outsourcing and data-protection reviews treat that as information about personal data processing, not harmless metadata.
• Sample values. If the AI layer sends distinct values so the model can match “Bhubaneswar” to a branch code, it is sending data.
• Results. Some designs send query results back to the model to write a narrative. If those are row-level, that is a data transfer.

Good design shrinks the payload: send aggregates rather than rows, never send samplevalues from sensitive columns. It does not take it to zero. The question and aschema description always have to reach the model. As a result, for many regulated teams, that means a model inside the perimeter and no path to any public AI endpoint.

Read the complete technical guide

TextToSQL, AIAnalytics, DataPrivacy, ApacheSuperset, DataSecurity

 

The first question a security reviewer asks about an AI analytics feature is not about accuracy.

It is: “What leaves our network, and where does it go?” If the honest answer is “a few thousand rows of the orders table, to a third-party model provider, on every question”, the review is over.It does not have to be. 

A model does not need to see the data to write SQL, any more thanan analyst reads every row before writing a GROUP BY. This post describes an architecture where the model writes the query, the analytics layer runs it, androw-level data never enters a prompt, with specifics on what crosses each boundary and what stops a bad query.

There are four steps, and only one of them involves the model provider:

• Describe. The application builds a description of the datasets the user may query: tables, columns, types, and what each column means.
• Generate. The question and that description go to the model, which returns SQL. This is the only call that leaves your trust boundary (unless the model is local, covered below).
• Validate and execute. The SQL is parsed, checked against policy, and run by the analytics layer under a restricted database role. The warehouse returns a result set to your application, not to the model.
• Present. The result is rendered as a chart or table for a user who is already authorised to see it.

A written explanation of the result is a second model call. Send it the aggregated result only, never the underlying rows. “EMEA revenue fell 12% quarter-on-quarter” needs a dozen numbers, not a million records.

Read the complete technical guide

Superset Upgrade Playbook: Moving a Production Instance from 3.x to 4.x Without Downtime

 

A Superset upgrade has one property that shapes everything else: the metadata database migration runs

forward and there is no supported migration backward. 

Once the schema is at 4.x, a 3.x image cannot start against it.

Every other risk in an upgrade is recoverable by redeploying the old image. This one is recoverable only by restoring the database. 

The playbook below is built around that fact.It is written for the 3.x to 4.x jump on a self-hosted deployment (Docker, Kubernetes or VMs) and applies with small changes to any major version. 

The specifics of what changed in 4.0 are from the release’s UPDATING.md; read it for your exact source and target versions rather than relying on this summary. 

Read the complete upgrade playbook

Natural-Language Querying on Apache Superset: Build Text-to-SQL Yourself or Use a Managed AI Layer

 

The question usually arrives in a steering meeting, phrased as if it were small: now that everyone has used a chatbot, can people not just ask Superset a question and get the chart? The honest answer is yes, but the Friday demo is not what you can give four hundred people on Monday.

Turning “revenue by region last quarter” into SQL is an afternoon’s work. A layer that picks the right dataset, respects every permission you have built, refuses what it cannot answer, and stays accurate after someone renames a column is a small product with an owner.

This post breaks the layer into its parts, describes what building each on Apache Superset involves, and explains where a managed option fits.

We build Superset platforms and also a managed AI product on Superset, so we state that product’s limits as plainly as its strengths.

Read the full guide

Building a Custom Filter or Control-Panel Component for Apache Superset

 

Not all Apache Superset filters work the same way. Chart controls, native dashboard filters, and cross-filtering serve different purposes—and each requires a different implementation approach.

This guide explains how to build all three, from configuring chart-specific controls in controlPanel.ts to implementing dashboard-wide native filters and interactive cross-filtering. Discover where each component belongs, how they differ, and which approach best fits your requirements.

Start with the simplest solution and build smarter Superset filtering experiences without unnecessary frontend modifications.

Build Interactive Filters → 

Superset Plugin Performance: Rendering 100k-Row Datasets Without Freezing the Dashboard

 

The complaint arrives as “the dashboard is slow”, and the first instinct is to look at the database. 

Check the query time in Superset’s chart data response and it is often under a second.

The other nine seconds are in the browser: parsing the response, transforming it, and drawing a hundred thousand DOM nodes.

Custom plugins are especially prone to this because they are written against a sample dataset and shipped before anyone tries them on the real one. (If you have not built one yet, start with how to build a custom chart plugin for Apache Superset; this post assumes that structure.) 

This post is about finding where the time goes and fixing it, in the order that gives the most improvement for the least rework. 

Read More

Superset Plugin Performance: Rendering 100k-Row Datasets Without Freezing the Dashboard

Is your Apache Superset dashboard slow even when database queries finish in under a second? The

bottleneck might be your browser—not your database. Parsing large responses, transforming data, and

rendering thousands of DOM nodes can turn a fast query into a sluggish dashboard.

Custom chart plugins are especially vulnerable when tested only with sample datasets. This guide shows you how to identify and fix performance bottlenecks in the right order, using three essential tools: Superset's query timing, Chrome Performance panel, and React Profiler.

Discover how to pinpoint expensive transformations, reduce unnecessary renders, and optimize rendering performance. Measure first, optimize smarter, and make your dashboards faster.

Already building custom charts? Start with our guide to building a custom chart plugin for Apache Superset.

Find Your Dashboard's Bottleneck →