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.

Phase 1: Read

Before any environment is touched.

`UPDATING.md`. The Superset repository keeps a running file of breaking changes by version. Next, read every entry between your current version and your target. Then copy each one into a checklist with a column for “affects us” and “action”. For 3.x to 4.0 the entries most deployments hit:

  • Filter box removed. The legacy filter box chart type is gone. Dashboards that used it need native filters. Superset provides a migration, but it is a data change, so it is rehearsed like everything else.
  • Legacy chart migrations completed. Several older chart types (the legacy area, bar, line and others) were migrated to their ECharts replacements and the originals removed. Saved charts of those types must be migrated with the superset viz-migrations command.
  • Talisman on by default. Flask-Talisman and its content security policy are enabled. Anything that loads external resources (map tiles, fonts, scripts) or embeds Superset in an iframe needs TALISMAN_CONFIG entries. If you use embedded dashboards, frame-ancestors is now mandatory.
  • Python version. 4.x requires Python 3.9 or later (3.10 or 3.11 recommended at the time of 4.0). A custom image on an older base needs a new base.
  • Feature flag defaults. Several flags flipped, notably around generic chart axes, cross-filters and native filters becoming default-on. Diff superset/config.py between the two tags for the DEFAULT_FEATURE_FLAGS dictionary and note every change.
  • Removed configuration keys. Deprecated settings are removed at major versions. Superset logs a warning for unknown keys at startup; your rehearsal will surface them.

What your own environment adds

Next, your own inventory. From the metadata database: count of charts by viz_type, dashboards using filter boxes, custom plugins and their peer dependency pins, custom security manager or other Python extensions, CSS templates (they target internal class names), and alerts and reports (the report worker’s browser dependency may change).

Finally, dependencies. Database drivers pinned in your image, the Celery and Redis versions, the reverse proxy configuration for websocket support if you use it.

At the end of Phase 1 you have a checklist of actions and an estimate. Therefore, if the checklist has surprises, this is the cheap moment to find them.

Phase 2: Rehearse

Never run the first upgrade against production. Instead, rehearse against a copy of the production metadata database, because the metadata is where the risk is.

  • Snapshot production metadata. pg_dump the metadata database (or your provider’s snapshot). Restore it into a staging database.
  • Stand up staging on the current version against that copy, with the same superset_config.py and the same Redis topology (a fresh Redis is fine). Confirm it works: log in, open the top ten dashboards.
  • Build the target image. Same Dockerfile, new base tag, plugins rebuilt against the new @superset-ui versions (see the plugin compatibility guide), updated superset_config.py with the Phase 1 actions applied.
  • Run the schema migration against the staging copy:
bash
superset db upgrade
superset init

Timing the rehearsal

Next, time it. On a metadata database with years of logs the logs table can make migrations slow; if it is over a few minutes, plan to prune old logs (reports.prune_log in Celery, or a direct delete of logs rows older than your retention period) before the production run.

  • Run the visualisation migrations for the chart types listed in Phase 1:
bash
superset viz-migrations upgrade --viz_type area
superset viz-migrations upgrade --viz_type bar
# repeat per type named in UPDATING.md for your versions

Each rewrites saved charts’ form data to the new chart type and keeps a record so it can be downgraded with the matching downgrade command if needed before cutover.

  • Migrate filter boxes to native filters using the provided migration, then open every affected dashboard and check the filters do what they did.
  • Start the target image against the migrated staging database. Read the startup log for unknown configuration keys and deprecation warnings. Fix them.
  • Verify using the checklist in Phase 4. Fix what fails, rebuild, and repeat from step 1 with a fresh copy until the rehearsal is clean end to end.

The rehearsal produces the exact command sequence and timing for production, and a list of dashboards and charts that needed attention. So, keep both.

Rehearsed it — now who signs off on cutover?

The rehearsal catches most breakage; the cutover window is where custom plugins and RBAC config quietly slip through. A Superset Architecture Review reviews your specific instance before that window opens.

Book a Superset Architecture Review

Phase 3: Cut over

The migration constraint means true zero-downtime blue-green, where old and new run side by side against the same database, is not safe across a major version: the old version may fail or corrupt data on the new schema. What is achievable is a short read-only window measured in minutes, with a tested rollback.

The night before

  • Announce the window. Ten to twenty minutes is realistic for a rehearsed upgrade.
  • Confirm backups are running and a restore has been tested recently.
  • Pre-pull the target image on every node so the deploy is a restart, not a download.
  • Prune old logs rows if the rehearsal showed the migration was slow.

The sequence

  • Freeze writes. Put the web tier into maintenance (a static page at the load balancer, or scale web replicas to zero). Stop Celery beat so no scheduled reports or warm-ups run mid-migration. Let in-flight Celery tasks finish, then stop workers.
  • Snapshot the metadata database. This is the rollback point. Do not skip it because you have nightly backups; you want the state from thirty seconds ago.
  • Run the migration with the rehearsed commands from a one-off container on the target image: superset db upgrade, superset init, the viz-migrations commands, the filter box migration. Compare the timing to rehearsal.
  • Flush the caches you configured: metadata cache certainly, data cache preferably. Cached metadata from the old version can render incorrectly on the new one.
  • Deploy the target image to workers first, then beat, then web. Health check /health on each web replica.
  • Smoke test while still in maintenance: log in, open two dashboards, run one SQL Lab query, load one embedded dashboard if you have them.
  • Open traffic.

Overall, elapsed time for a rehearsed upgrade on a moderate metadata database: five to fifteen minutes, dominated by the migration.

Rollback

However, if the smoke test fails and the cause is not obvious within a few minutes:

  • Stop the target web, beat and workers.
  • Restore the metadata database from the step 2 snapshot.
  • Redeploy the previous image to workers, beat and web.
  • Flush caches, smoke test, open traffic.

Also, rehearse the rollback at least once in staging. A rollback you have never run is a plan, not a procedure.

Phase 4: Verify

Do this in staging during rehearsal and again in production after cutover. Also, automate as much as you can, because you will do it again next year.

  • Authentication. SSO login, role assignment, an admin action, a viewer’s restricted view. Custom security managers are a common casualty.
  • Top dashboards. Every dashboard in the top twenty by views over the last month, opened and visually checked. A script that requests each dashboard’s chart data endpoints and asserts 200 with rows catches most breakage without eyes.
  • Migrated charts. Every chart touched by viz-migrations, opened in Explore. Colours, stacking and axis formatting are what typically drift.
  • Filters. Every dashboard that had a filter box, with each filter exercised.
  • Custom plugins. Every saved chart using each plugin, plus one new chart created from scratch.
  • SQL Lab. A query on each database connection, one async.
  • Alerts and reports. Trigger one report manually and check the screenshot renders with the new Talisman policy.
  • Embedded dashboards. Load one from the embedding application; the Talisman frame-ancestors change is the number one post-upgrade embedding failure.
  • Performance. Compare the dashboard load times to the numbers you noted before. New defaults occasionally disable a cache you relied on.
  • Logs. Tail the web and worker logs for the first hour for tracebacks and deprecation warnings.

Between major versions

Minor and patch upgrades (4.0 to 4.1, 4.1.1 to 4.1.2) use the same playbook with less reading. The migration step is still one-way, so the snapshot before migration is still mandatory, but the rehearsal can be lighter and the window shorter. So, do them regularly; the longer the gap between upgrades, the more entries in UPDATING.md and the more painful the jump. Overall, quarterly is a good cadence, with security patches applied as they land.

Common failures, from experience

Symptom Cause Prevention
Migration takes an hour Huge logs table Prune before, set a retention policy after
Embedded dashboards blank after upgrade Talisman enabled, no frame-ancestors Configure TALISMAN_CONFIG in Phase 1
Maps show no tiles CSP blocks the tile server Add tile and API hosts to connect-src and img-src
Charts show “Unknown viz type” Legacy chart types removed, migration skipped Run viz-migrations for every listed type
Dashboards lost their filters Filter box removed Run the filter box migration and review each dashboard
Custom plugin missing from picker Not rebuilt against new @superset-ui versions Rebuild in Phase 2
Startup warns about unknown config keys Deprecated settings removed Fix in rehearsal; do not ignore warnings
Login page broken Custom security manager uses a changed FAB API Test auth first in rehearsal
Everything works, dashboards slow A feature flag default changed caching or async behaviour Diff DEFAULT_FEATURE_FLAGS in Phase 1; compare load times in Phase 4

Before the next one

Two habits make the next upgrade cheaper. First, keep your superset_config.py free of anything not deliberately set, so the diff against defaults stays small. Second, keep a UPGRADE.md in your deployment repository with the exact commands, timings and gotchas from this run; the person doing the next upgrade will thank you, and it is often you.

Frequently Asked Questions

What breaks when upgrading Apache Superset from 3.x to 4.x?

In short, the entries most deployments hit are the removal of the legacy filter box, the completed legacy chart migrations (older area, bar and line types must be migrated with superset viz-migrations), Flask-Talisman and its content security policy being on by default, the Python 3.9-or-later requirement, several feature-flag defaults flipping, and removed configuration keys. Read every UPDATING.md entry between your current version and your target, and turn each into a checklist row with “affects us” and “action” columns.

Can a Superset major-version upgrade really be done without downtime?

For read traffic, yes, with a rehearsal against a restored copy of production, a blue-green or rolling cut-over, and a tested rollback. However, the part that is not free is the database migration: schema changes on a large metadata database take time, which is why the rehearsal exists, to measure that time before the change window rather than during it.

What is the most common post-upgrade failure?

Embedded dashboards going blank, because Talisman is on by default in 4.x and frame-ancestors is now mandatory for any origin that frames Superset. Similarly, custom security managers are the other frequent casualty, so SSO login and role assignment are the first things on the verification list rather than the last.

What should be verified after the cut-over?

Authentication end to end, every dashboard in the top twenty by views over the last month, every chart touched by viz-migrations, every dashboard that previously used a filter box, every saved chart from each custom plugin plus one new one, a query per database connection including an async one, one manually triggered report, one embedded dashboard loaded from the embedding application, and a load-time comparison against the numbers you recorded beforehand. Then tail the web and worker logs for the first hour.

Build It With Andolasoft

Upgrade readiness is one of the six areas in our Superset Architecture Review: the version gap, the UPDATING.md entries that apply to your deployment, the plugins and extensions that need rebuilding, and the state of your metadata database. In addition, it is a fixed-scope five-day review with a written report you can run the upgrade from. Under Managed Support we run the upgrades on a schedule, including the rehearsal, so the playbook above is something you read once rather than execute. The production configuration the upgrade has to preserve is covered in Superset in production, and the plugin side in what breaks between 3.x and 4.x for plugins.

If you have an upgrade on the calendar and a deployment people depend on, talk to us. We will tell you what in your specific instance breaks, how long the migration takes on your metadata database, and what the rollback looks like.

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

If your organisation runs on Microsoft 365, Entra ID (the service formerly called Azure Active Directory) is already the source of truth for who works there and what they may access. Superset should read from it rather than keeping its own list of passwords. Flask-AppBuilder, the framework under Superset, has an Azure OAuth handler built in, so the setup is configuration rather than code.

This guide is the Entra-specific companion to our Okta SSO guide. The general mechanics of Superset authentication, the reverse-proxy settings and the break-glass advice are the same and are not repeated in full here. What differs with Entra is the app registration, the way roles reach Superset, and the errors you will see.

The configuration applies to Superset 2.1 through 4.x, written against 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.

Step 1: Register the application

In the Entra admin centre:

  • Go to Identity, Applications, App registrations and choose New registration.
  • Name it “Superset BI”. Under Supported account types choose Accounts in this organizational directory only (single tenant).
  • Under Redirect URI select Web and enter https://superset.example.com/oauth-authorized/azure. The final segment must match the provider name in superset_config.py, which is azure in this guide. Entra compares redirect URIs case-sensitively and exactly, including trailing slashes.
  • Register, then note the Application (client) ID and Directory (tenant) ID from the Overview page.
  • Under Certificates & secrets, create a client secret. Copy the value immediately; it is shown once. Set a calendar reminder for its expiry, because an expired secret is a total login outage.
  • Under Authentication, confirm ID tokens is ticked under implicit grant and hybrid flows. Superset uses the authorization-code flow, but FAB decodes the ID token for the user’s profile, so it must be issued.
  • Under Token configuration, add the optional claims email, family_name, given_name, preferred_username and upn to the ID token. This ensures FAB has a username and a display name even for guest or unusual accounts.

Define app roles

  • Under App roles, choose Create app role.
  • Create three roles with Allowed member types set to Users/Groups:
Display name Value Description
Superset Admin Superset.Admin Full administration
Superset Analyst Superset.Analyst Build charts and dashboards, run SQL
Superset Viewer Superset.Viewer View permitted dashboards

The Value is what appears in the token and what AUTH_ROLES_MAPPING matches.

Assign users and groups

  • Go to Identity, Applications, Enterprise applications, open “Superset BI”, then Users and groups.
  • Add your existing security groups, assigning each to one app role. A user can hold several roles by being in several groups.
  • Under Properties, set Assignment required to Yes. Anyone not assigned is refused by Entra before Superset is involved, which is the behaviour you want.

Step 2: Configure Superset

python
import os
from flask_appbuilder.security.manager import AUTH_OAUTH

AZURE_TENANT_ID = os.environ["AZURE_TENANT_ID"]
AZURE_AUTHORITY = f"https://login.microsoftonline.com/{AZURE_TENANT_ID}"

AUTH_TYPE = AUTH_OAUTH

OAUTH_PROVIDERS = [
    {
        "name": "azure",
        "icon": "fa-windows",
        "token_key": "access_token",
        "remote_app": {
            "client_id": os.environ["AZURE_CLIENT_ID"],
            "client_secret": os.environ["AZURE_CLIENT_SECRET"],
            "api_base_url": f"{AZURE_AUTHORITY}/oauth2",
            "client_kwargs": {
                "scope": "openid profile email User.Read",
            },
            "request_token_url": None,
            "access_token_url": f"{AZURE_AUTHORITY}/oauth2/v2.0/token",
            "authorize_url": f"{AZURE_AUTHORITY}/oauth2/v2.0/authorize",
            "jwks_uri": f"{AZURE_AUTHORITY}/discovery/v2.0/keys",
        },
    }
]

AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = "Gamma"

# Entra app role value -> Superset roles
AUTH_ROLES_MAPPING = {
    "Superset.Admin": ["Admin"],
    "Superset.Analyst": ["Alpha", "sql_lab"],
    "Superset.Viewer": ["Gamma"],
}
AUTH_ROLES_SYNC_AT_LOGIN = True

# Proxy and cookie settings (same as any OAuth deployment behind TLS termination)
ENABLE_PROXY_FIX = True
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_SAMESITE = "Lax"

What is specific to Entra here:

  • The provider name must be azure for FAB’s built-in handler to recognise it and decode the ID token correctly.
  • The URLs are the v2.0 endpoints for your tenant. Do not use the common tenant unless you intend to accept users from any Entra directory, which for an internal BI tool you almost certainly do not.
  • jwks_uri is what FAB uses to verify the ID token signature. It must be the tenant’s discovery keys endpoint.
  • The roles claim is read automatically from the ID token by FAB’s Azure handler; nothing extra to configure.

App roles chosen — RBAC design is next

Entra ID settles who can log in; a Superset Architecture Review settles what capability and data-domain roles they land in, so access control doesn’t get bolted on ad hoc later.

Book a Superset Architecture Review

Step 3: Test

Restart Superset. The login page shows a single “Sign in with azure” button.

  • Sign in as a member of the admin group. Confirm the Admin menu is visible and the user appears in Settings, List Users with the Admin role.
  • In a private window, sign in as a viewer. Confirm only permitted dashboards appear.
  • Move a user between groups in Entra, sign them out and in. Roles should change, which confirms AUTH_ROLES_SYNC_AT_LOGIN.
  • Try a user who is not assigned to the application. Entra should refuse with an “assignment required” message before reaching Superset.

Entra-specific troubleshooting

Symptom Cause Fix
AADSTS50011: The redirect URI ... does not match Redirect URI mismatch, often case or trailing slash Copy the URI exactly; enable ENABLE_PROXY_FIX so Superset sends https://
AADSTS7000215: Invalid client secret Secret value copied wrongly, or the secret ID instead of the value Create a new secret and copy the value column
AADSTS700016: Application not found in the directory Wrong tenant ID in the URLs Use the Directory (tenant) ID from the app Overview page
AADSTS50105: The signed in user is not assigned to a role Assignment required is on and the user is unassigned Assign the user or their group under Enterprise applications
Everyone gets the Gamma role App roles not defined, or user assigned to the app without a role Define app roles and assign groups to specific roles
Login works, user has no name or email Optional claims not configured Add email, given_name, family_name, preferred_username under Token configuration
mismatching_state error Session cookie not returned on callback SESSION_COOKIE_SAMESITE = "Lax", SESSION_COOKIE_SECURE matching the scheme
Logins fail on a Monday morning Client secret expired over the weekend Rotate the secret; set the expiry reminder you skipped last time

If you must use groups instead of app roles

Some organisations mandate group-based access for all applications. Two changes:

  • In the app registration under Token configuration, add a groups claim to the ID token. Choose Groups assigned to the application rather than all security groups, which sidesteps the overage problem for most tenants.
  • Override oauth_user_info in a custom security manager so that role_keys reads the groups claim. Entra emits group object IDs, not names, so the keys in AUTH_ROLES_MAPPING become GUIDs:
python
import jwt
from superset.security import SupersetSecurityManager


class EntraGroupsSecurityManager(SupersetSecurityManager):
    def oauth_user_info(self, provider, response=None):
        if provider != "azure":
            return super().oauth_user_info(provider, response)
        id_token = response["id_token"]
        claims = jwt.decode(id_token, options={"verify_signature": False})
        return {
            "username": claims.get("preferred_username") or claims.get("upn") or claims["oid"],
            "first_name": claims.get("given_name", ""),
            "last_name": claims.get("family_name", ""),
            "email": claims.get("email") or claims.get("preferred_username", ""),
            "role_keys": claims.get("groups", []),
        }


CUSTOM_SECURITY_MANAGER = EntraGroupsSecurityManager

AUTH_ROLES_MAPPING = {
    "5d2f9c1a-...-admins-group-object-id": ["Admin"],
    "8b7e4a3c-...-analysts-group-object-id": ["Alpha", "sql_lab"],
}

The signature is not re-verified here because Authlib has already validated the token during the exchange; the decode is only to read claims. Keep a comment saying so, or the next reviewer will flag it.

Operational notes

  • Secret rotation is the main recurring task. Entra client secrets expire at 6, 12 or 24 months. Put the expiry in the same calendar as your TLS certificates.
  • Conditional Access policies in Entra (MFA, compliant device, location) apply to Superset automatically, which is a strong argument for SSO in regulated environments.
  • Deactivating a user in Entra blocks new logins immediately. Existing Superset sessions last until PERMANENT_SESSION_LIFETIME; keep it to a working day or less.
  • Service accounts that used password login against the Superset API need another path once AUTH_TYPE changes. Plan for it before the cutover.

Frequently Asked Questions

Should Superset roles come from Entra ID groups or app roles?

App roles, in almost every case. Flask-AppBuilder’s Azure handler reads the roles claim, which is populated by app roles, and matches it against AUTH_ROLES_MAPPING without any custom code. App roles also avoid the groups overage problem: Entra stops emitting the groups claim entirely once a user belongs to more than a couple of hundred groups, and replaces it with an overage indicator that Superset cannot use. Groups remain possible, but they need a custom security manager and group object IDs as mapping keys.

Why do all my users land in the Gamma role after Entra ID SSO?

Either no app roles are defined on the registration, or users are assigned to the enterprise application without being assigned to a specific role. Superset is doing what it was told: no roles claim arrives, nothing matches AUTH_ROLES_MAPPING, and AUTH_USER_REGISTRATION_ROLE applies. Check the claim first, by decoding the ID token from a test login, before changing any Superset configuration.

Why does Entra return AADSTS50011 when the redirect URI looks correct?

Entra compares redirect URIs exactly, including case and trailing slashes, and the URI Superset sends is built from the request it received. Behind a TLS-terminating proxy, Superset sends http:// unless ENABLE_PROXY_FIX = True is set, so a URI registered as https://superset.example.com/oauth-authorized/azure never matches. Set the proxy fix, then copy the URI character for character.

Do Entra Conditional Access policies apply to Apache Superset?

Yes. Because the login happens at Entra rather than in Superset, MFA, compliant-device and named-location policies are enforced before a token is ever issued, and Superset inherits them without configuration. That inheritance is one of the stronger arguments for putting Superset behind SSO in a regulated environment. The limit is session lifetime: revoking access in Entra blocks new logins immediately but does not terminate an existing Superset session, so keep PERMANENT_SESSION_LIFETIME short.

Build It With Andolasoft

Entra ID settles who can log in. The role design it feeds, row-level security, the caching and async query setup and upgrade readiness are the rest of the platform, and a Superset Architecture Review checks all of them in five working days with a written report. If the platform should simply be someone else’s problem, Managed Support covers patching, monitoring and the secret-rotation reminders that prevent a Monday-morning outage. For the wider set of controls around a deployment, see governance and security best practices for Superset.

If you are putting Superset behind Entra ID and would rather settle the role model at the same time than six months later, talk to us. We will review your app registration, the claims it emits and your current Superset roles, and give you a fixed-scope plan to a deployment your security team can sign off.

Top Embedded BI Platforms for SaaS Companies

In a crowded SaaS market, integrating analytics into your product is no longer optional—it is essential. That’s where embedded BI platforms come in.

This guide explores the best embedded BI platforms for SaaS companies, how to evaluate them, and how to implement them successfully.
You will walk away with clear insights so your SaaS product becomes more data-driven, sticky, and profitable.

What Are Embedded BI Platforms?

Put simply, BI platforms allow software vendors to integrate business intelligence directly into their applications.

Instead of users leaving the product to analyze data, they get actionable dashboards, visualizations, and analytics without context switching.

These platforms deliver:

  • Real-time analytics inside your app
  • Customizable dashboards
  • Self-service reporting
  • Advanced data modeling
  • Alerts and notifications
  • Role-based access

Embedding analytics transforms standard SaaS features into data-rich experiences. That makes your product more valuable to users and increases retention.

What Embedded BI Platforms Deliver

Why SaaS Companies Need Embedded BI Platforms

Before we review the best embedded BI platforms, let’s cover why they matter for SaaS companies:

  • Retention and Stickiness: When users rely on analytics inside your app, they stay longer.
  • Upsell Opportunities: Premium analytics features can drive higher-tier subscriptions.
  • Better Decision-Making: Users make faster, smarter decisions with insights at their fingertips.
  • Competitive Differentiation: Products with integrated analytics outperform competitors.
  • Reduced Churn: Analytics help users see value faster, lowering churn.

Embedding analytics isn’t just a feature — it is a strategic advantage.

Criteria to Evaluate Embedded BI Platforms

Before choosing among BI platforms, assess them on:

  • Integration complexity
  • Scalability
  • Custom branding
  • API and SDK support
  • Security and compliance
  • Performance
  • Pricing model

Use the following evaluation checklist:

Checklist for Choosing Embedded BI Platforms

  • Offers white-labeling
  • Supports multi-tenant SaaS
  • Provides REST APIs
  • Handles high query loads
  • Role-based security
  • GDPR and SOC 2 compliance

This checklist ensures you choose the right BI platforms for your growth goals.

Top Embedded BI Platforms for SaaS Companies

Here are the best BI platforms that SaaS companies should consider. Each one is evaluated for scalability, ease of integration, and value for SaaS products.

1. Tableau Embedded Analytics

Tableau is a leader among embedded BI platforms with enterprise-grade analytics and robust visualization tools.

Pros:

  • Advanced visuals
  • Strong community and support
  • Scales for enterprise users

Cons:

  • Higher cost
  • Requires more development effort

Best for: Large SaaS companies with complex analytics needs.

2. Power BI Embedded

Microsoft’s Power BI Embedded makes Tableau-level analytics accessible at a lower entry cost.

Benefits:

  • Microsoft ecosystem integration
  • Real-time dashboards
  • Affordable pricing tiers

Considerations:

  • Less flexible than some specialized products
  • Licensing can be complex

Ideal for: SaaS companies using Azure and Microsoft tools.

3. Looker Embedded Analytics

Looker’s architecture makes it one of the most modern BI platforms available.

Highlights:

  • Centralized data modeling
  • SQL-based transformations
  • Strong API support

Challenges:

  • Learning curve for LookML
  • Pricing tailored to enterprise customers

Perfect for: Data-centric SaaS applications and analytics-minded teams.

4. Sisense for Cloud Data Teams

Sisense offers powerful embedded analytics with flexible APIs and cloud-native performance.

Key Features:

  • Elastic analytics engine
  • Fully customizable UI
  • Multi-tenant SaaS support

Points to Note:

  • Teams need technical resources
  • Pricing can scale with usage

Best fit: SaaS products requiring deep integration and customization.

5. Chartio (Now Part of Atlassian)

Although Chartio was acquired, its embedded analytics capabilities continue to influence current embedded BI platforms.

Pros:

  • Simple interface
  • Drag-and-drop analytics
  • Fast onboarding

Limitations:

  • Feature set not as deep as others
  • Transitioning under new brand

Great for: Early-stage SaaS products with basic analytics needs.

6. Metabase Embedded

Metabase is an open-source option among embedded BI platforms, ideal for budget-conscious teams.

Advantages:

  • Open-source flexibility
  • Quick deployment
  • Community support

Drawbacks:

  • Limited enterprise features
  • Requires self-management

Best choice: Small to mid-size SaaS companies.

7. Qlik Sense Embedded

Qlik Sense combines strong analytics with associative data indexing — great for complex data needs.

Benefits:

  • Smart visual associations
  • High performance
  • Strong security

Considerations:

  • Higher learning curve
  • Pricing suited for large organizations

Best for: Data-intensive SaaS platforms.

Embedded Analytics Use Cases by Industry

Understanding real use cases clarifies how embedded BI platforms deliver value in specific scenarios.

SaaS Analytics Use Cases

  • Customer Success Dashboards
  • Product Usage Insights
  • Financial Performance Metrics
  • Operational Reports
  • Executive Scorecards

Bullet points make complex benefits tangible:

  • Track customer adoption trends
  • Surface churn risk indicators
  • Deliver revenue forecasting
  • Enable self-service analytics

These use cases ensure embedded analytics adds measurable business outcomes.

Implementation Best Practices

Implementing BI platforms without a clear plan often leads to delays. Follow these steps for success:

Step-by-Step Strategy

Define Business Goals

  • What decisions will analytics drive?
  • Who are the users?

Prepare Your Data Infrastructure

Select Your Embedded BI Platform

  • Use the evaluation checklist above
  • Build proof of concept

Design Dashboards for Users

  • Keep it simple
  • Prioritize actionable insights

Measure Adoption

  • Track usage metrics
  • Iterate on feedback

Implementing embedded analytics is a project — not just a purchase.

Common Mistakes When Choosing BI Platforms

Avoid these pitfalls:

  • Choosing based on cost alone
  • Ignoring future scalability
  • Skipping user experience design
  • Underestimating data governance needs

By avoiding these mistakes, SaaS companies maximize ROI from embedded analytics.

Pricing Models for Embedded BI Platforms

Understanding pricing helps SaaS teams budget appropriately.

Common Models:

  • Per-user pricing
  • Usage-based pricing
  • API call pricing

Example bullet list:

  • Flat licensing fee
  • Tiered feature pricing
  • Consumption-based billing

Always request transparent pricing before committing.

How to Measure Success

Quantifiable success metrics help justify investment in BI platforms:

Measure these regularly to optimize value.

Integrating Embedded BI Platforms with SaaS Products

Integration approaches vary by platform:

Native SDK Integration

  • Deep customization
  • White-label analytics

iFrame Embedding

  • Fast to deploy
  • Limited customization

API-Driven Integration

  • API first
  • High control

Choose based on technical resources and product roadmap.

Conclusion

Choosing the right BI platforms can transform your SaaS product from a tool into a strategic asset. Embedded analytics drives retention, boosts revenue, and makes your product indispensable.

Evaluate these platforms based on your current needs and future goals, and implement them with a clear roadmap.

If you want growth, better user engagement, and data-driven value, embedded analytics is not optional — it is foundational.

FAQs

1. What are embedded BI platforms?

BI platforms are analytics solutions that allow SaaS companies to integrate dashboards, reports, and visual analytics directly into their applications, enabling users to access insights without leaving the product.

2. How do embedded BI platforms differ from traditional BI tools?

Traditional BI tools operate as standalone systems, whereas embedded BI platforms are integrated within SaaS products, offering contextual, in-app analytics tailored to end users.

3. Why are embedded BI platforms important for SaaS companies?

BI platforms improve product stickiness, reduce churn, enable data-driven decision-making, and create opportunities to monetize analytics as premium features.

4. Can small or early-stage SaaS companies use embedded BI platforms?

Yes. Many BI platforms offer flexible pricing, open-source options, or scalable architectures that suit startups and growing SaaS businesses.

5. What features should SaaS companies look for in embedded BI platforms?

Key features include multi-tenant support, white-labeling, API and SDK access, role-based security, scalability, performance optimization, and compliance capabilities.

6. Are embedded BI platforms secure for customer data?

Most enterprise-grade BI platforms provide strong security features such as role-based access control, encryption, audit logs, and compliance with standards like GDPR and SOC 2.

7. How long does it take to implement embedded BI platforms?

Implementation timelines vary based on complexity, data readiness, and customization needs, ranging from a few weeks to several months.

8. Can embedded BI platforms support multi-tenant SaaS architectures?

Yes. Leading BI platforms are designed to support multi-tenant environments, ensuring data isolation and secure analytics for each customer.

9. How do SaaS companies monetize embedded analytics?

SaaS companies monetize BI platforms through premium analytics tiers, add-on reporting modules, usage-based pricing, or enterprise analytics packages.

10. What are common mistakes when choosing embedded BI platforms?

Common mistakes include focusing only on cost, ignoring scalability, underestimating integration effort, neglecting user experience, and overlooking long-term data governance needs.

Must-Have Enterprise BI Features for Modern Applications

Enterprise software no longer competes on features alone. It competes on how fast decisions are made, how accurately performance is measured, and how quickly leaders can respond to change. That is exactly why enterprise BI has moved from a “nice-to-have” analytics layer to a core operating system for decision-making.

Today, every serious enterprise application — whether it is ERP, CRM, HRMS, FSM, construction management, or financial systems — must embed or integrate BI at its core.

However, not all analytics are created equal.

True enterprise BI is not about pretty dashboards. Instead, it is about governance, scale, trust, performance, security, and decision velocity. Therefore, choosing the right BI features is a strategic architecture decision, not a UI decision.

In this definitive guide, you will learn:

  • What enterprise BI really means in modern enterprises
  • Why basic reporting tools fail at scale
  • The must-have BI features for any serious enterprise application
  • How BI drives adoption, ROI, and competitive advantage
  • How to evaluate an BI platform properly

Let us begin with the fundamentals.

Must-Have-Enterprise-BI-Features-at-a-Glance

What Is Enterprise BI?

It (Enterprise Business Intelligence) is a scalable, governed, secure, and performance-driven analytics layer that supports decision-making across the entire organization—from frontline teams to executive leadership.

Unlike basic BI tools, enterprise BI:

  • Serves hundreds or thousands of users
  • Handles millions or billions of rows of data
  • Enforces data governance and security
  • Supports mission-critical business workflows
  • Integrates deeply into core enterprise applications

In other words, BI is not a reporting tool. It is a decision infrastructure.

Why Basic BI Fails in Enterprise Environments

Many organizations start with simple dashboards. However, they quickly hit limitations.

Basic BI fails because:

  • It cannot scale to large data volumes
  • It breaks under concurrent user load
  • It lacks role-based security and governance
  • It creates multiple versions of truth
  • It depends heavily on analysts instead of business users
  • It does not integrate deeply into enterprise workflows

As a result, enterprises either:

  • Lose trust in data
  • Slow down decision-making
  • Or build expensive, fragmented analytics stacks

This is exactly why enterprise BI exists.

The Strategic Role of Enterprise BI in Enterprise Applications

Modern enterprise applications are no longer transactional systems only. They are decision platforms.

Therefore, BI must:

  • Power daily operational decisions
  • Support strategic leadership decisions
  • Enable cross-department visibility
  • Drive process optimization
  • Enforce data accountability
  • Accelerate business execution

Consequently, BI becomes a core competitive advantage.

Must-Have Enterprise BI Features (Complete Enterprise Checklist)

Below is the definitive feature framework for evaluating or building a true BI system.

1. Enterprise-Grade Data Architecture

BI must handle complexity at scale.

It must support:

  • Multiple data sources (ERP, CRM, HRMS, IoT, Finance, Ops, external data)
  • Structured and semi-structured data
  • Large volumes and high refresh rates
  • Historical and real-time data together

Core capabilities include:

  • Data connectors and ingestion pipelines
  • Data modeling and semantic layers
  • Incremental refresh and caching
  • Support for cloud, on-prem, and hybrid data

Without this foundation, enterprise BI collapses under growth.

2. Single Source of Truth (Semantic Layer)

One of the biggest reasons BI fails is metric chaos.

Therefore, enterprise BI must provide:

  • Centralized metric definitions
  • Business-friendly semantic models
  • Reusable KPIs across dashboards and apps
  • Governance over calculations and logic

Benefits:

  • No conflicting numbers
  • No department-level data politics
  • No spreadsheet shadow systems
  • High trust in executive reporting

In short, BI must enforce truth at scale.

3. Enterprise Security and Access Control

Enterprise BI is useless if it is not secure.

It must support:

  • Role-based access control (RBAC)
  • Row-level and column-level security
  • SSO and enterprise authentication (SAML, OAuth, LDAP, etc.)
  • Audit logs and access tracking
  • Data masking for sensitive fields

Why this matters:

  • Finance, HR, and leadership data must not leak
  • Compliance requirements demand strict controls
  • Large organizations cannot rely on manual permissions

Therefore, security is not optional in BI. It is foundational.

4. Performance at Scale

Enterprise BI must stay fast even when:

  • Data grows 10x
  • Users grow 50x
  • Queries become complex
  • Dashboards become heavier

Critical performance features include:

  • Intelligent caching
  • Query optimization
  • In-memory acceleration
  • Pre-aggregations
  • Load balancing
  • Asynchronous query execution

Because in enterprises:

If dashboards are slow, decisions are slow. And slow decisions cost money.

5. Embedded Analytics for Enterprise Applications

Modern enterprise BI must not live in a separate portal.

Instead, it must:

  • Embed inside ERP, CRM, HRMS, FSM, or industry apps
  • Respect application user permissions
  • Adapt to application workflows
  • Feel like a native feature

Embedded BI enables:

  • Contextual decision-making
  • Higher adoption
  • Better user experience
  • Stronger product differentiation

Today, enterprise BI is a product feature, not a separate product.

6. Self-Service Analytics for Business Users

BI cannot depend entirely on analysts.

It must empower:

  • Managers
  • Operations leaders
  • Finance teams
  • Sales leaders
  • Department heads

Self-service features include:

  • Drag-and-drop reports
  • Filter and slice-and-dice
  • Drill-down and drill-through
  • Custom views and saved dashboards
  • Ad-hoc exploration without SQL

This ensures:

  • Faster answers
  • Less dependency on data teams
  • Higher data culture maturity

7. Advanced Dashboarding and Visualization

Enterprise BI dashboards must support:

  • Executive-level KPI views
  • Operational performance views
  • Departmental scorecards
  • Process monitoring screens

Core visualization capabilities:

  • Interactive charts and tables
  • Cross-filtering
  • Drill-down hierarchies
  • Conditional formatting
  • Alerts and thresholds
  • Storytelling views

However, remember:

Enterprise BI is not about visuals. It is about decisions enabled by visuals.

8. Real-Time and Near Real-Time Analytics

Many enterprise use cases require:

  • Live operations monitoring
  • SLA tracking
  • Incident detection
  • Financial risk control
  • Supply chain visibility

Therefore, BI should support:

  • Streaming or near-real-time data
  • Incremental refresh
  • Low-latency dashboards
  • Operational alerting

This transforms enterprise BI from reporting to control systems.

9. Alerts, Automation, and Decision Triggers

Modern BI must not wait for users to open dashboards.

It must:

  • Push alerts when thresholds are crossed
  • Trigger workflows
  • Send notifications to email, Slack, Teams, etc.
  • Integrate with business processes

Examples:

  • Alert when cash flow drops below limit
  • Alert when project cost overruns
  • Alert when churn risk spikes
  • When compliance metrics fail

This is how enterprise BI becomes proactive instead of reactive.

10. Data Governance and Lineage

At enterprise scale, governance is non-negotiable.

  • BI must provide:
  • Data lineage tracking
  • Impact analysis
  • Change management
  • Certification of datasets
  • Ownership and stewardship models

This ensures:

  • Audit readiness
  • Compliance confidence
  • Trust in enterprise-wide metrics
  • Controlled evolution of analytics

11. Collaboration and Sharing

Enterprise BI is a team sport.

It must support:

  • Shared dashboards
  • Commenting and annotations
  • Versioning
  • Scheduled reports
  • Role-based sharing

This transforms analytics into organizational conversation, not isolated analysis.

12. AI and Advanced Analytics (Optional but Strategic)

Modern enterprise BI increasingly includes:

  • Forecasting
  • Anomaly detection
  • Trend analysis
  • What-if simulations
  • Natural language queries

While not mandatory for every enterprise today, this is rapidly becoming a strategic differentiator.

13. Scalability and Future-Proof Architecture

Enterprise BI must scale across:

  • Users
  • Data volume
  • Use cases
  • Departments
  • Geographies

Therefore, it must support:

  • Modular architecture
  • API-first integration
  • Cloud and hybrid deployment
  • Horizontal scaling
  • Multi-tenant or multi-org setups

How Enterprise BI Drives Real Business Outcomes

When implemented correctly, BI delivers:

  • Faster decision cycles
  • Higher operational efficiency
  • Lower reporting overhead
  • Better leadership visibility
  • Stronger governance
  • Higher ROI from enterprise systems

In short:

BI turns data into organizational leverage.

How to Evaluate an Enterprise BI Platform

Use this checklist:

  • Does it scale to thousands of users?
  • Does it enforce governance and security?
  • Does it embed inside your application?
  • Does it support self-service safely?
  • Does it perform under heavy load?
  • Does it integrate with your data stack?
  • Does it reduce dependency on analysts?

If the answer is “no” to several of these, it is not true BI.

Final Thoughts: Enterprise BI Is Not Optional Anymore

In 2026 and beyond, BI is not an add-on.

It is:

  • A core layer of enterprise architecture
  • A strategic decision platform
  • A competitive advantage
  • A governance system
  • A performance engine

Organizations that treat BI as a strategic system will out-execute, out-learn, and out-scale those that do not.

And that is the real power of BI.

BI and AI Explained: Turning Business Data into Predictive Intelligence

In today’s digital-first economy, data is no longer the differentiator — predictive intelligence is. Organizations generate massive volumes of data every day, yet many still struggle to turn that data into timely, actionable insights.

Traditional dashboards explain what happened, but modern businesses need answers to what will happen next. This is exactly where BI and AI come into play.

By combining Business Intelligence (BI) with Artificial Intelligence (AI), organizations can move beyond static reporting and unlock predictive intelligence — insights that anticipate trends, forecast outcomes, and recommend actions before problems arise.

As competition intensifies and decision cycles shorten, this capability has become mission-critical.

In this guide, you will learn how BI and AI works together, why it matters across industries, and how businesses can implement it successfully.

More importantly, you will see how Andolasoft helps organizations design, build, and scale predictive intelligence in data platforms that deliver real business outcomes — not just charts and dashboards.

Business intelligence and Artificial Intelligence Capabilities

Business Need & Importance of BI and AI

Modern businesses operate in environments defined by speed, complexity, and uncertainty. Customer expectations change rapidly, markets fluctuate, and operational risks emerge without warning.

In this context, relying on historical reports alone creates blind spots.

Why BI and AI Matters Today

BI and AI matters because it converts raw data into foresight. While BI organizes and visualizes structured data, AI analyzes patterns, learns from historical behavior, and predicts future outcomes. Together, they enable smarter, faster, and more confident decision-making.

Key business drivers include:

  • Exploding data volumes: Data from apps, IoT devices, CRMs, ERPs, and customer interactions is growing exponentially. Manual analysis simply cannot keep up.
  • Demand for real-time decisions: Leaders need insights now, not at the end of the month or quarter.
  • Competitive pressure: Companies that predict customer needs and operational risks earlier gain a clear advantage.

Industry-Specific Impact of BI and AI

Across industries, BI and AI is transforming how decisions are made:

  • Healthcare: Predictive analytics helps forecast patient admissions, detect anomalies in diagnostics, and optimize resource allocation.
  • eCommerce: AI-powered BI predicts demand, personalizes recommendations, and reduces cart abandonment through behavioral insights.
  • Logistics & Supply Chain: Companies forecast delays, optimize routes, and proactively manage inventory risks.
  • Fintech: Fraud detection models and credit risk predictions enhance security and regulatory compliance.
  • SaaS & Technology: Usage analytics and churn prediction enable proactive customer retention strategies.
  • Manufacturing: Predictive maintenance reduces downtime by identifying equipment failures before they occur.

Risks of Not Adopting BI and AI

Organizations that delay adoption face serious consequences:

  • Operational inefficiencies due to reactive decision-making
  • Revenue loss from missed opportunities and late responses
  • Security and compliance risks caused by delayed anomaly detection
  • Poor customer experience driven by generic, non-personalized interactions

Therefore, companies increasingly require strategic, scalable BI and AI solutions, not fragmented tools or legacy systems that fail to evolve with business needs.

Best Practices, Frameworks & Actionable Tips for BI and AI Implementation

Successfully implementing BI and AI requires more than tools — it demands the right strategy, architecture, and execution partner.

1. Start with Business Questions, Not Data

Successful BI and AI initiatives begin with clear business objectives. Instead of asking what data is available, define what decisions need improvement.

  • Identify high-impact use cases such as demand forecasting, churn prediction, or operational risk analysis.
  • Align analytics outputs directly with KPIs that leadership cares about.
  • Avoid building dashboards without a clear decision-making purpose.

2. Build a Strong Data Foundation

AI is only as good as the data it learns from. Data quality, consistency, and governance are non-negotiable.

  • Consolidate data from multiple sources into a centralized data warehouse or lake.
  • Standardize data definitions to eliminate reporting inconsistencies.
  • Implement strong data governance and access controls from day one.

3. Use the Right Architecture

A modern BI and AI architecture typically includes:

  • Data ingestion pipelines for real-time and batch data
  • Cloud-based data storage for scalability and performance
  • BI visualization layers for descriptive and diagnostic analytics
  • AI/ML models for predictive and prescriptive insights

This modular approach ensures flexibility as business needs evolve.

4. Combine Descriptive, Predictive, and Prescriptive Analytics

BI and AI works best when analytics maturity progresses in stages:

  • Descriptive analytics explains what happened.
  • Predictive analytics forecasts what will happen.
  • Prescriptive analytics recommends what actions to take next.

Skipping stages often leads to low adoption and mistrust in AI outputs.

5. Focus on Explainability and Trust

Business users must trust AI-generated insights.

  • Use explainable AI models where possible.
  • Clearly show which factors influenced predictions.
  • Provide confidence scores and scenario comparisons within dashboards.

6. Avoid Common BI and AI Mistakes

Common pitfalls include:

  • Treating AI as a plug-and-play feature rather than a continuous learning system.
  • Overengineering solutions before validating business value.
  • Ignoring change management and user adoption.

7. Quick Wins to Build Momentum

Low-effort, high-impact improvements include:

  • Automating anomaly detection in existing BI dashboards.
  • Adding predictive forecasts to sales and demand reports.
  • Using AI to prioritize leads or support tickets.

For the descriptive layer of this stack, Andolasoft built DashboardGPT, managed Apache Superset 6.0 hosting with an AI layer. Business users ask questions in plain English and get a chart plus a written insight with the supporting numbers, and a follow-up on a selected chart carries its filters and time range into the next question. It answers questions about your data; the predictive models described above are a separate build.

From the Andolasoft team: DashboardGPT

Start with business questions, in plain English

DashboardGPT turns plain-English questions into charts and written insights on managed Apache Superset 6.0. Upload a CSV and try it on the free Explore plan.

How Andolasoft Helps Implement BI and AI

Andolasoft delivers end-to-end BI and AI solutions tailored to business goals, not generic templates. Their expertise spans:

  • Custom Web Development for analytics platforms
  • SaaS Product Engineering with embedded BI and AI capabilities
  • BI, AI & Machine Learning Solutions for predictive intelligence
  • Data Analytics & Visualization for executive decision-making
  • Application Modernization to upgrade legacy BI systems
  • DevOps, Cloud & Automation for scalable, secure deployments

Choosing the right technology partner ensures long-term scalability, security, and ROI from BI and AI investments.

Customer Success Example: BI and AI in Action

For example, a mid-sized eCommerce company partnered with Andolasoft to modernize its analytics and forecasting capabilities. The company struggled with inventory overstocking, frequent stockouts, and delayed reporting that limited proactive decisions.

Andolasoft designed a BI and AI-driven predictive analytics platform that unified sales, customer behavior, and supply chain data into a single predictive intelligence layer. AI models were implemented to forecast product demand, identify high-risk SKUs, and recommend replenishment actions.

Within six months, the results were measurable:

  • 30% improvement in demand forecast accuracy
  • 25% reduction in inventory holding costs
  • 40% faster reporting cycles
  • Significantly improved executive visibility into future trends

Most importantly, decision-making shifted from reactive firefighting to predictive, data-driven planning.

Key Takeaways & Closing

To summarize, BI and AI represents a fundamental shift in how organizations use data:

  • BI provides clarity, while AI delivers foresight
  • Together, they enable predictive intelligence, not just reporting
  • Businesses across industries gain faster decisions, lower risk, and higher efficiency
  • Success depends on strategy, data quality, architecture, and execution

Adopting BI and AI now positions organizations to compete in a future where speed and predictive intelligence define winners. With the right approach and an experienced partner like Andolasoft, businesses can confidently turn data into a strategic asset — not an operational burden.

FAQs

1. What is BI and AI in simple terms?

BI and AI combine business intelligence reporting with artificial predictive intelligence to analyze data, predict outcomes, and recommend actions automatically.

2. How is BI and AI different from traditional BI?

Traditional BI focuses on historical data, while BI and AI adds predictive and prescriptive insights using machine learning models.

3. Which industries benefit most from BI and AI?

Healthcare, eCommerce, fintech, logistics, SaaS, manufacturing, and education see significant value from BI and AI adoption.

4. Is BI and AI only for large enterprises?

No. With cloud and modular architectures, BI and AI is now accessible and scalable for startups and mid-sized businesses.

5. How long does it take to implement BI and AI?

Initial use cases can go live in weeks, while full-scale implementations typically take a few months depending on complexity.

6. What data is required for BI and AI?

Structured and semi-structured data from CRMs, ERPs, applications, and operational systems form the foundation for BI and AI.

7. Why choose Andolasoft for BI and AI projects?

Andolasoft combines deep technical expertise, real-world delivery experience, and business-first thinking to deliver measurable BI and AI outcomes.