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 → 

How to Set Up Keycloak SSO for Apache Superset (OpenID Connect)

When organisations need full control over identity, Keycloak is a natural fit—whether for on-premise

deployments, regulated environments, multiple upstream directories, or an entirely open-source stack.

Apache Superset fits right in, with Flask-AppBuilder providing a built-in Keycloak handler that makes

integration a configuration task, not a coding project.

But there’s one silent trap to watch for. 🔍 Keycloak’s default client configuration doesn’t include the groups claim that FAB uses to map users to Superset roles. The result? Logins succeed, but everyone gets the default role. No obvious error—just incorrect access.

This guide fixes that in Step 1, before it catches you off guard.

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

Tested with Superset 4.x and Keycloak 24, with compatibility for Keycloak 17 and later—the versions that no longer use the /auth URL prefix.

Read The Complete Technical Guide

How to Set Up Microsoft Entra ID (Azure AD) SSO for Apache Superset

 

Apache Superset SSO with Microsoft Entra ID

If your organisation uses Microsoft 365, Microsoft Entra ID (formerly Azure Active Directory) already manages employee identities and access. Integrating Superset with Entra ID lets you centralise authentication instead of maintaining separate passwords. Flask-AppBuilder provides a built-in Azure OAuth handler, making configuration possible without custom code.

This guide complements our Okta SSO guide, focusing on Entra-specific app registration, role mapping, and common authentication errors. General authentication mechanics, reverse-proxy settings, and break-glass procedures remain unchanged.

The configuration covers Apache Superset 2.1 through 4.x, with examples based on version 4.x.

Groups or app roles?

Entra can put either the user’s group memberships or their app roles into the token. Flask-AppBuilder’s Azure handler reads the roles claim, which is app roles, and uses it as the list of keys to match against AUTH_ROLES_MAPPING.

App roles are also the better design for Superset:

• No overage problem. Entra stops emitting the groups claim when a user is in more than a couple of hundred groups and replaces it with an overage indicator. Large organisations hit this routinely. App roles are specific to your application and never overflow.

• Assignment lives on the application. You assign a group or a user to an app role in the Superset enterprise application. The Entra admin sees exactly who can reach Superset and as what, without decoding group names.

• Role names are yours. Superset.Admin, Superset.Analyst, Superset. Viewer are clearer than a security group created five years ago for something else.

So this guide uses app roles. If you must use groups, the section near the end explains what to change.

Curious How It Works? →

Superset RBAC Design for a 500-User Enterprise: Roles, Data Access and Dashboard Permissions

 

Apache Superset Permissions: Smarter Access Control -

Apache Superset offers flexible permissions, but default role configurations often lead to excessive

privileges and manual dataset access management.This guide explores scalable permission design for

multi-department deployments in Superset 3.x and 4.x.

Understanding Superset Permissions

Superset uses Flask-AppBuilder’s security model, built on three concepts:

Permission: Actions such as can_read, can_write, can_export, and schema_access.

View Menu: The resource being accessed, such as a Dashboard, Chart, Dataset, or SQL Lab.

Permission View: The combination of an action and a resource, grouped into roles assigned to users.

Key principles: Roles are composable, combining capabilities and data access, but there is no deny

override—any role granting dataset access makes that access available.

Dataset vs. Schema Permissions

Superset creates dataset-specific permissions automatically, expanding the permission list as the catalogue grows.

Schema-level schema_access provides a scalable alternative, covering all current and future datasets

within a schema.

Explore What’s Possible →

Multi-Tenant Row-Level Security in Embedded Superset: Three Patterns and When Each Fails

Embedding a Superset dashboard is easy. Making sure each tenant sees only its own data—across every

chart, filter, drill-down, and cached result—is where things get serious. A weak tenant boundary can turn

embedded analytics into a security incident.

Superset supports three main approaches to enforce tenant isolation: RLS clauses in guest tokens, Superset RLS rules using Jinja and token attributes, and separate schemas or databases for each tenant. Each approach works differently and has specific limitations.

This guide breaks down all three patterns, explains where each can fail, and shows how they can be combined for stronger isolation. It also includes a practical test plan to help you verify tenant isolation instead of simply assuming it works.

Your Complete Guide Starts Here →

Superset Plugin Compatibility: What Breaks Between 3.x and 4.x and How to Migrate a Plugin

 

A custom chart plugin is compiled into the Superset frontend bundle. That is what makes it fast and

first- class, but it is also why a Superset upgrade can break it: the plugin is built against specific

versions of @superset-ui/core, @superset-ui/chart-controls, and related frontend APIs.

The jump from 3.x to 4.x changed enough that some plugins need more than a simple rebuild—they

may require updates to dependencies, APIs, query handling, or TypeScript code.

This guide is the practical checklist we use when migrating a custom plugin from Superset 3.x to 4.x. It covers the key compatibility checks across index.ts, buildQuery.ts, controlPanel.ts, transformProps.ts, and the React visualization component, along with plugin registration in MainPreset.js. The goal is simple: identify what changed, update only what is necessary, rebuild cleanly, and verify the plugin in Explore and dashboards.

One caveat up front: the exact breaking changes depend on the two Superset versions you are moving between. Always check UPDATING.md and the release notes for every version between your current release and the target. This guide highlights the most important compatibility issues to check when crossing the 3.x to 4.x line.

Explore the Details →