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 → 

How to Set Up Google Workspace SSO for Apache Superset

For organisations running on Google Workspace, Google SSO is the login experience users already

know. Flask-AppBuilder includes a built-in Google OAuth handler, making the initial Apache Superset

integration possible in just 15 minutes.

But there are two common pitfalls. First, Google OAuth can authenticate personal Gmail accounts unless access is explicitly restricted. Second, Google’s user info response provides names and email addresses but no group memberships by default, leaving Superset’s AUTH_ROLES_MAPPING without the information it needs. The result? Users silently fall into the default role.

This guide tackles both challenges in superset_config.py, exploring three increasingly powerful approaches to role mapping.

Already familiar with Superset OAuth? Our Okta guide covers the shared essentials, including proxy settings and break-glass access. Here, we focus on what makes Google SSO different.

Unlock Google SSO for Superset →