Apache Superset for Executive Reporting in SaaS

Table of Contents

1. Why Apache Superset for Executive Reporting
2. Data Modelling Foundations
3. Building the Semantic Layer
4. Dashboard Design Principles
5. Performance Tuning and Optimisation
6. Rollout Patterns and Governance
7. Integration with SaaS Platforms
8. Troubleshooting Common Issues
9. Next Steps and Implementation

---

Why Apache Superset for Executive Reporting {#why-apache-superset}

Executive reporting in SaaS organisations has historically relied on expensive per-seat BI tools—Tableau, Looker, Power BI—that scale licensing costs with headcount. Apache Superset flips that model. It’s open-source, self-hosted, and purpose-built for modern data stacks. You pay for infrastructure, not per user. For seed-to-Series-B startups and scaling operators, that’s a material cost advantage.

But cost alone doesn’t justify adoption. Superset works because it sits at the intersection of accessibility and power. Non-technical founders can explore data without writing SQL. Data engineers can build sophisticated semantic layers. Executives get self-service dashboards that refresh in seconds, not hours.

The real win is speed to insight. A SaaS CEO needs to know: MRR, churn, CAC, LTV, runway, and cohort health—weekly, sometimes daily. Superset dashboards can be built and iterated in days, not weeks. That matters when your Series A depends on demonstrating unit economics or when your board meeting is Thursday.

PADISO’s platform engineering teams have embedded Superset into multi-tenant SaaS architectures across Australia, North America, and beyond. We’ve seen it replace legacy per-seat BI, cut reporting infrastructure costs by 60–70%, and compress iteration cycles from weeks to days. This guide captures that operational experience.

When Superset Is the Right Choice

Superset excels when:

• Headcount is growing fast. Per-seat licensing becomes prohibitive at 50+ users.
• Your data stack is modern. PostgreSQL, ClickHouse, Snowflake, BigQuery, Redshift—Superset has native connectors.
• You need self-service dashboarding. Executives and operators should explore data without filing tickets to analytics.
• Iteration speed matters. You’re building unit economics, cohort analysis, or product metrics that change weekly.
• You want to own your data story. Self-hosted means your dashboards, your data, your schema—no vendor lock-in.

Superset is not the right choice if:

• Your team is non-technical and needs hand-holding on every dashboard.
• You require advanced predictive analytics or AI-driven insights (though AI & Agents Automation can extend Superset with agentic reporting).
• Your organisation is heavily invested in a single BI vendor’s ecosystem (Salesforce + Tableau, for example).

The Superset Advantage for SaaS Metrics

SaaS metrics are time-sensitive. MRR, churn, CAC, and LTV need to be current, trustworthy, and accessible to non-analysts. Superset’s strength is that it makes this possible at scale.

A typical SaaS executive dashboard in Superset might include:

• Real-time revenue metrics: MRR, ARR, net revenue retention, gross margin.
• Customer health: Active accounts, churn rate, NPS, CSAT.
• Sales funnel: Pipeline, win rate, average deal size, sales cycle length.
• Product metrics: Feature adoption, user engagement, retention cohorts.
• Financial runway: Burn rate, months of runway, cash flow forecast.

Each of these can be built as a Superset dataset and visualised in a dashboard that updates every 15 minutes. Non-technical users can drill into cohorts, filter by region or segment, and export data for board prep—all without touching SQL.

---

Data Modelling Foundations {#data-modelling}

Superset dashboards are only as good as the data underneath them. Before you design a single chart, you need a clean, well-modelled data layer. This is where most Superset projects stumble.

The Three Layers of Data Architecture

Think of your data stack as three layers:

Layer 1: Raw Data (Operational Database)

Your SaaS application writes to PostgreSQL, MySQL, or a similar operational store. This is your source of truth for transactions, user behaviour, and state. It’s optimised for writes and point lookups, not analytical queries. You should never query this directly for reporting—it’ll slow down your application.

Layer 2: Data Warehouse (Analytical Database)

Data flows from your operational database into a warehouse via ETL or ELT pipelines. This might be Snowflake, BigQuery, Redshift, or ClickHouse. The warehouse is optimised for analytical queries: full scans, aggregations, joins across large tables. This is where Superset lives.

Layer 3: Semantic Layer (Superset Datasets)

Within Superset, you define “datasets”—curated views of your warehouse data that executives can explore. Datasets include calculated fields, aggregations, and business logic. This is where “MRR” gets defined, where “churn” is calculated, where “active user” is codified.

Getting this architecture right is non-negotiable. A common mistake is trying to query your operational database directly from Superset. This breaks your application, generates lock contention, and produces slow dashboards. Instead, replicate your operational data to a warehouse, and query the warehouse from Superset.

Designing Datasets for Self-Service

A Superset dataset is a SQL query (or a table) that you expose to dashboard builders. The goal is to make common analytical queries easy without requiring SQL knowledge.

Here’s a worked example. Suppose you’re building a SaaS metrics dashboard. You need to expose:

• Monthly recurring revenue (MRR) by month and segment.
• Customer churn by cohort.
• Feature adoption by user segment.

Instead of having dashboard builders write three separate SQL queries, you create a single “SaaS Metrics” dataset that includes all three calculations. The dataset might look like:

SELECT
  DATE_TRUNC('month', subscription_start_date) AS month,
  customer_segment,
  SUM(monthly_amount) AS mrr,
  COUNT(DISTINCT customer_id) AS active_customers,
  COUNT(CASE WHEN churn_date IS NOT NULL THEN 1 END) AS churned_customers,
  COUNT(CASE WHEN feature_x_used_this_month THEN 1 END) AS feature_x_users
FROM fact_subscriptions
LEFT JOIN dim_customers USING (customer_id)
WHERE subscription_start_date >= DATE_TRUNC('year', NOW() - INTERVAL '3 years')
GROUP BY 1, 2
ORDER BY 1 DESC, 2;

Now a non-technical founder can build a dashboard by dragging this dataset into Superset and creating visualisations. No SQL required.

Dimensional Modelling Best Practices

For SaaS metrics, adopt a dimensional model with fact and dimension tables:

Fact Tables

Fact tables record transactions or events:

• fact_subscriptions: One row per subscription per month (or per day). Includes MRR, churn flag, renewal date.
• fact_events: One row per user event. Includes user ID, event type, timestamp, properties.
• fact_transactions: One row per payment. Includes amount, date, customer, payment method.

Dimension Tables

Dimension tables describe entities:

• dim_customers: One row per customer. Includes name, segment, cohort, geography, plan type.
• dim_products: One row per product or feature. Includes name, category, launch date.
• dim_dates: One row per date. Includes month, quarter, year, day of week (useful for time-based filtering).

This structure makes it easy to build Superset datasets that combine metrics with business context. You can slice MRR by customer segment, churn by cohort, adoption by geography—all without writing complex SQL.

Handling Late-Arriving Data

In SaaS, data often arrives late. A customer might churn on the 5th of the month, but the churn flag doesn’t appear in your warehouse until the 10th. Payment data can lag by days. Superset dashboards need to account for this.

Best practice: always include a data_as_of_date column in your fact tables. This tells you when the row was last updated. When building dashboards, filter to data that’s at least 24–48 hours old. This avoids showing incomplete metrics.

For example:

SELECT *
FROM fact_subscriptions
WHERE data_as_of_date <= NOW() - INTERVAL '2 days'

This simple rule prevents executives from seeing incomplete churn numbers or missing revenue.

---

Building the Semantic Layer {#semantic-layer}

Once your data is modelled, the next step is building Superset datasets—the semantic layer that sits between raw data and dashboards.

Creating Datasets in Superset

In Superset, a dataset is either:

1. A table: You point Superset at a table in your warehouse, and Superset exposes all columns.
2. A SQL query: You write a SQL query, and Superset treats the result as a virtual table.

For executive reporting, SQL queries are almost always better. They let you:

• Pre-calculate metrics (MRR, churn, CAC).
• Join multiple tables without dashboard builders needing to know the schema.
• Apply business logic (e.g., “only count active subscriptions”).
• Optimise performance by pre-filtering and aggregating.

Here’s a practical example. Suppose you want a dataset called “Customer Metrics” that includes:

• Monthly active customers.
• Churn rate.
• Average customer lifetime value (LTV).
• Net revenue retention (NRR).

You’d create a SQL dataset:

WITH monthly_subscriptions AS (
  SELECT
    DATE_TRUNC('month', subscription_date) AS month,
    customer_id,
    customer_segment,
    SUM(monthly_amount) AS mrr,
    MAX(CASE WHEN churn_date IS NOT NULL THEN 1 ELSE 0 END) AS churned
  FROM fact_subscriptions
  GROUP BY 1, 2, 3
),
churn_cohorts AS (
  SELECT
    month,
    customer_segment,
    COUNT(DISTINCT customer_id) AS active_customers,
    SUM(CASE WHEN churned = 1 THEN 1 ELSE 0 END) AS churned_customers,
    ROUND(100.0 * SUM(CASE WHEN churned = 1 THEN 1 ELSE 0 END) / COUNT(DISTINCT customer_id), 2) AS churn_rate
  FROM monthly_subscriptions
  GROUP BY 1, 2
)
SELECT
  month,
  customer_segment,
  active_customers,
  churned_customers,
  churn_rate,
  ROUND(active_customers * 24 * mrr_avg, 0) AS estimated_ltv
FROM churn_cohorts
LEFT JOIN (
  SELECT customer_segment, AVG(mrr) AS mrr_avg FROM monthly_subscriptions GROUP BY 1
) USING (customer_segment)
ORDER BY month DESC, customer_segment;

Once this dataset is created in Superset, a dashboard builder can:

• Drag “month” to the x-axis and “active_customers” to the y-axis to see growth.
• Create a table showing churn_rate by segment.
• Filter by customer_segment to focus on enterprise vs. SMB.
• All without writing SQL.

Calculated Fields and Virtual Metrics

Superset allows you to define calculated fields directly in the dataset UI. This is useful for simple transformations that don’t require a full SQL rewrite.

For example, you might add a calculated field for “Churn Rate (%)”:

churned_customers / active_customers * 100

Or “MRR Growth (%)”:

(current_mrr - previous_mrr) / previous_mrr * 100

Calculated fields are useful for dashboard builders who need to tweak metrics without touching SQL. But for complex logic (like cohort retention or unit economics), stick with SQL datasets.

Caching and Refresh Strategies

Superset can cache query results. For executive dashboards, this is critical—you don’t want every dashboard load to hit your data warehouse.

Set cache expiry based on how fresh the data needs to be:

• Real-time metrics (revenue, active users): 5–15 minutes.
• Daily metrics (churn, adoption): 1 hour.
• Weekly metrics (cohort analysis, LTV): 24 hours.

In Superset, you set cache expiry at the dataset level. Go to Dataset → Edit → Advanced → Cache Timeout.

For SaaS dashboards, a 15-minute refresh is usually the sweet spot. It keeps data fresh without hammering your warehouse.

Documenting Datasets

As your Superset instance grows, dataset documentation becomes critical. Other teams need to know:

• What does this dataset measure?
• What’s the grain (daily, monthly, per-customer)?
• When was it last updated?
• What’s the SLA (how fresh is the data)?

In Superset, use the Description field to document each dataset. Example:

Customer Metrics Dataset

Grain: Monthly per customer segment
Source: fact_subscriptions, dim_customers
Refresh: Every hour
SLA: Data is 24–48 hours old (accounts for late-arriving churn data)

Key Metrics:
- active_customers: Count of customers with an active subscription
- mrr: Monthly recurring revenue
- churn_rate: Percentage of customers who churned
- estimated_ltv: 24-month LTV based on historical churn

Limitations:
- Does not include one-time purchases
- Churn is based on subscription cancellation, not usage

This takes 10 minutes and saves your team hours of confusion later.

---

Dashboard Design Principles {#dashboard-design}

A well-designed executive dashboard answers specific questions in seconds. A poorly designed one is a wall of charts that nobody understands.

The Executive Dashboard Hierarchy

Think of executive dashboards as a pyramid:

Top Tier: The One-Page Dashboard

This is the dashboard the CEO checks every morning. It fits on a single screen (no scrolling) and answers the five most critical questions:

1. How much revenue did we make last month? (MRR, ARR)
2. How many customers do we have? (Active accounts, net adds)
3. Are customers staying? (Churn rate, NRR)
4. How much runway do we have? (Burn rate, months of runway)
5. Are we growing? (MoM growth, YoY growth)

For a SaaS startup, this might be:

┌─────────────────────────────────────────────────┐
│ MRR: $150K (+12% MoM)  │  Active Customers: 250  │
│ ARR: $1.8M (+15% YoY)  │  Net Add (MoM): +15     │
├─────────────────────────────────────────────────┤
│ Churn Rate: 3.2%  │  NRR: 108%  │  Runway: 18mo  │
├─────────────────────────────────────────────────┤
│ MRR Trend (Last 12 Months) [Line Chart]         │
│ Customer Cohort Retention [Cohort Table]        │
└─────────────────────────────────────────────────┘

This dashboard takes 30 seconds to read. The CEO knows the business health at a glance.

Second Tier: Functional Dashboards

These dive deeper into specific functions:

• Sales dashboard: Pipeline, win rate, sales cycle, CAC by source.
• Product dashboard: Feature adoption, user engagement, retention by cohort.
• Finance dashboard: Burn rate, cash flow, customer concentration, unit economics.
• Operations dashboard: Support volume, CSAT, feature requests, roadmap velocity.

Each functional dashboard should have 6–12 visualisations. More than that, and it becomes overwhelming.

Third Tier: Drill-Down Dashboards

These are for analysts and operators who need to debug specific issues. Why did churn spike? Which customer segment is underperforming? These dashboards can be dense and SQL-heavy.

Design Rules for Clarity

Rule 1: One Question Per Chart

Each visualisation should answer a single question. If a chart requires explanation, it’s too complex.

Rule 2: Use the Right Visualisation Type

• Trend over time: Line chart.
• Comparison across categories: Bar chart.
• Part-to-whole (e.g., revenue by segment): Pie or donut (sparingly).
• Distribution: Histogram or box plot.
• Correlation: Scatter plot.
• Detailed data: Table.

Superset has excellent guidance on building dashboards that actually get used. The key is matching the visualisation to the insight.

Rule 3: Highlight What Matters

Use colour to draw attention:

• Green for good news (growth, retention).
• Red for warnings (churn spike, runway below 12 months).
• Neutral grey for context.

In Superset, use conditional formatting to highlight cells that cross thresholds. Example: if churn rate > 5%, highlight in red.

Rule 4: Provide Context

Every metric needs context. Not just the number, but the trend:

• MRR: $150K (+12% MoM, +18% YoY)
• Churn: 3.2% (was 3.5% last month, 2.8% last year)

In Superset, add a second row or column showing the comparison period. Or use a combo chart with the metric and a trend line.

Rule 5: Make Filtering Easy

Executives want to slice data by:

• Time period (last month, last quarter, last year).
• Customer segment (enterprise, SMB, startup).
• Geography (US, EU, APAC).
• Product line or feature.

Add a filter at the top of the dashboard for each of these. In Superset, use the Filter widget. Link it to the relevant dataset columns. This lets non-technical users drill into the data without writing SQL.

Rule 6: Avoid Chart Junk

Remove unnecessary elements:

• 3D effects.
• Excessive gridlines.
• Decorative backgrounds.
• Legends that duplicate axis labels.

Every pixel should serve a purpose. Superset dashboards are often viewed on small screens (phones, tablets). Clutter makes them unusable.

Layout and Responsiveness

Superset dashboards are responsive by default, but you need to design for mobile. Here’s the pattern:

• Desktop (1920px): 3–4 columns, 4–6 rows. About 12–15 visualisations per dashboard.
• Tablet (768px): 2 columns, 8–10 rows.
• Mobile (375px): 1 column, 15–20 rows.

In Superset’s dashboard editor, you can preview responsive layouts. Test on mobile before publishing.

Drill-Down and Cross-Filtering

Superset supports cross-filtering: clicking on one chart filters others on the same dashboard. This is powerful for exploration.

Example: A dashboard with a bar chart showing MRR by segment and a line chart showing churn by segment. Click on “Enterprise” in the bar chart, and the line chart updates to show only Enterprise churn. This lets executives explore without jumping between dashboards.

To enable cross-filtering in Superset:

1. Create two charts on the same dashboard.
2. In the second chart, go to Chart → Edit → Interactions.
3. Select Cross Filter and choose the column to filter on (e.g., customer_segment).
4. Link it to the first chart.

---

Performance Tuning and Optimisation {#performance-tuning}

A slow dashboard is a useless dashboard. Executives won’t wait 30 seconds for a chart to load. Performance is non-negotiable.

Query Optimisation

Before you blame Superset, optimise your SQL. Here are the common culprits:

Culprit 1: Selecting Too Many Columns

Bad:

SELECT * FROM fact_subscriptions

Good:

SELECT customer_id, month, mrr, churn_flag FROM fact_subscriptions

Selecting only the columns you need reduces data transfer and speeds up aggregations.

Culprit 2: Joining Without Indexes

If you’re joining fact_subscriptions to dim_customers on customer_id, ensure customer_id is indexed in both tables.

CREATE INDEX idx_fact_subscriptions_customer_id ON fact_subscriptions(customer_id);
CREATE INDEX idx_dim_customers_customer_id ON dim_customers(customer_id);

Culprit 3: Filtering Too Late

Bad:

SELECT * FROM fact_subscriptions
WHERE YEAR(subscription_date) = 2024

Good:

SELECT * FROM fact_subscriptions
WHERE subscription_date >= '2024-01-01' AND subscription_date < '2025-01-01'

Date filters using functions like YEAR() prevent index usage. Use range comparisons instead.

Culprit 4: Aggregating Too Much Data

If your fact_subscriptions table has 10 million rows, and you’re aggregating all of them, that’s slow. Instead, pre-aggregate in your warehouse.

Create a table called fact_subscriptions_monthly:

SELECT
  DATE_TRUNC('month', subscription_date) AS month,
  customer_segment,
  SUM(mrr) AS total_mrr,
  COUNT(DISTINCT customer_id) AS customer_count
FROM fact_subscriptions
GROUP BY 1, 2;

Then query this pre-aggregated table in Superset. It’s 1000x faster.

Superset-Specific Optimisations

Caching Strategy

As mentioned earlier, set appropriate cache timeouts:

• Real-time dashboards: 5–15 minutes.
• Operational dashboards: 1 hour.
• Strategic dashboards: 24 hours.

In Superset, you can also cache individual charts. Go to Chart → Edit → Advanced → Cache Timeout.

Database Connection Pooling

If Superset is making hundreds of queries per minute, your database connection pool might be exhausted. Increase the pool size in your Superset config:

SQLALCHEMY_ENGINE_OPTIONS = {
    'pool_size': 10,
    'pool_recycle': 3600,
    'pool_pre_ping': True,
}

Asynchronous Query Execution

For long-running queries, enable async execution. In Superset, go to Settings → Feature Flags and enable ENABLE_SUPERSET_METRICS_LAYER. This allows queries to run in the background while the user waits.

Monitoring Query Performance

Use Superset’s built-in query monitoring to identify slow queries:

1. Go to Settings → Query History.
2. Sort by Execution Time.
3. Identify queries taking > 10 seconds.
4. Optimise or pre-aggregate those queries.

Also monitor your data warehouse directly. Most warehouses (Snowflake, BigQuery, Redshift) have query monitoring tools. Use them to understand where time is being spent.

---

Rollout Patterns and Governance {#rollout-patterns}

You’ve built a beautiful Superset instance with clean data and optimised queries. Now you need to roll it out without chaos.

The Phased Rollout Pattern

Phase 1: Pilot (Weeks 1–2)

Start with a small group: the CEO, CFO, and head of product. They use the executive dashboard daily and give feedback. This is where you’ll find issues:

• “I need to see churn by product, not just by segment.”
• “This number doesn’t match our accounting system.”
• “Can we add a forecast?”

Iterate quickly. The goal is to get buy-in from leadership.

Phase 2: Functional Rollout (Weeks 3–6)

Once leadership is happy, roll out functional dashboards to teams:

• Sales team gets the pipeline and CAC dashboard.
• Product team gets the adoption and retention dashboard.
• Finance team gets the unit economics dashboard.

For each team, run a 30-minute training session:

• How to access Superset.
• How to use filters and drill-down.
• How to export data for presentations.
• Who to contact if something’s wrong.

Phase 3: Self-Service (Weeks 7+)

Once teams are comfortable, teach them to build their own dashboards. Start with a template:

• Here are the available datasets.
• Here’s how to create a simple bar chart.
• Here’s how to add a filter.

Provide a Slack channel for questions. Assign a “Superset champion” in each team to help peers.

Governance and Access Control

As your Superset instance grows, you need governance:

Who can create datasets?

Answer: Only data engineers and analysts. Datasets are the foundation of your semantic layer. Poorly designed datasets will break dashboards downstream. Restrict dataset creation to trusted people.

In Superset, go to Settings → Roles and create a “Dataset Creator” role. Assign it only to data engineers.

Who can create dashboards?

Answer: Anyone. Dashboards are the interface to data. Encourage teams to build dashboards for their own use cases. Just make sure they’re using approved datasets.

Who can see what data?

Answer: Depends on your data sensitivity. If you have customer PII or financial data, restrict access:

• Finance dashboards: Finance team only.
• Customer health dashboards: Sales and success teams only.
• Product metrics: Product and engineering teams.

In Superset, use Row-Level Security (RLS) to restrict data based on user attributes. Example:

IF {user_id} = 'john@company.com', {customer_segment} = 'Enterprise'

This means John only sees Enterprise customer data, even though the underlying dataset has all segments.

Naming and Organisation

As you accumulate dashboards, naming becomes critical. Use a naming convention:

[Team] [Function] - [Metric]

Examples:
- Sales - Pipeline - By Stage
- Product - Adoption - Feature X
- Finance - Unit Economics - By Cohort

Also use folders to organise dashboards:

Executive
├── Daily Dashboard
├── Weekly Board Prep
├── Monthly Forecast

Sales
├── Pipeline
├── Customer Health
├── Compensation

Product
├── Feature Adoption
├── Retention Cohorts
├── User Segmentation

This makes it easy for teams to find what they need.

Monitoring and Maintenance

Once Superset is live, you need to monitor it:

Weekly Health Check

• Are all dashboards loading in < 10 seconds?
• Are there any data quality issues (missing data, anomalies)?
• Are users asking for new dashboards or datasets?

Monthly Review

• Which dashboards are being used most? (Use Superset’s analytics.)
• Which dashboards are never opened? (Consider archiving.)
• Are there performance issues?
• Do datasets need updating?

Quarterly Audit

• Are metrics still correct? (Reconcile with accounting, sales tools, etc.)
• Are access controls still appropriate?
• Are there new data sources to integrate?

Assign someone (data engineer, analyst, or operations manager) to own Superset. It’s not a set-it-and-forget-it tool.

---

Integration with SaaS Platforms {#saas-integration}

Superset doesn’t exist in a vacuum. It needs to integrate with your SaaS stack: your operational database, your data warehouse, your BI tools, and your communication platforms.

Data Pipeline Integration

Your data needs to flow from source to Superset. Here’s the typical pattern:

Operational DB (PostgreSQL) → Data Warehouse (Snowflake) → Superset

The pipeline is usually:

1. Extract: Tools like Fivetran, Stitch, or Airbyte pull data from your operational database.
2. Load: Data lands in your warehouse (Snowflake, BigQuery, Redshift).
3. Transform: dbt (data build tool) transforms raw data into clean datasets.
4. Expose: Superset queries the warehouse.

For SaaS organisations, this pipeline typically runs on a schedule:

• Operational data: Every 1–4 hours.
• Aggregated metrics: Every 1 hour.
• Historical data: Once daily.

If you’re using PADISO’s platform engineering services, we design and operate these pipelines to ensure data freshness and reliability.

Connecting Superset to Your Warehouse

Superset supports most modern data warehouses. Here’s how to connect:

PostgreSQL / MySQL

Go to Settings → Database → Add Database. Select PostgreSQL. Enter:

• Host: your-db-host.com
• Port: 5432
• Username: superset_user
• Password: [secure password]
• Database: analytics

Snowflake

Select Snowflake. Enter:

• Account: xy12345.us-east-1
• Warehouse: COMPUTE_WH
• Database: ANALYTICS
• Schema: PUBLIC
• Username / Password: [Snowflake credentials]

BigQuery

Select Google BigQuery. Upload a service account JSON key. Superset will authenticate using the key.

ClickHouse

Select ClickHouse. Enter host, port, username, password, and database.

Once connected, Superset auto-discovers tables and columns. You can immediately start building datasets.

Embedding Superset in Your SaaS Product

If you want to embed Superset dashboards in your SaaS application (so customers see their own metrics), Superset supports embedding via iframes or the Superset API.

Iframe Embedding

Generate a guest token:

from superset import api

token = api.get_guest_token(
    dashboard_id=1,
    user_email='customer@example.com'
)

Then embed in your SaaS app:

<iframe src="https://superset.example.com/dashboard/1?token={token}"></iframe>

This is useful for showing customers their own data (usage, performance, etc.) within your product.

Alerting and Notifications

Superset has limited native alerting, but you can integrate with external tools:

Superset Alerts

Superset supports alerts on chart thresholds. Go to Chart → Edit → Alerts. Set a condition:

If MRR < $100K, send email to cfo@company.com

Alerts run on a schedule (hourly, daily, etc.) and trigger notifications.

Third-Party Integrations

For more sophisticated alerting, integrate Superset with:

• Slack: Use the Superset Slack integration to post dashboards to channels.
• Email: Schedule dashboard exports and email them to stakeholders.
• Webhooks: Trigger custom logic when thresholds are crossed.

PADISO’s AI & Agents Automation service can extend Superset with agentic reporting—automated dashboards that send alerts, run analyses, and answer questions via Slack or email.

Multi-Tenant Superset for SaaS

If you’re building a multi-tenant SaaS product and want to offer Superset as a feature, you need to:

1. Isolate data: Each tenant sees only their own data (using RLS).
2. Isolate dashboards: Each tenant has their own dashboard folder.
3. Isolate users: Each tenant’s users can only access their tenant’s data.

Superset’s RLS feature handles this. Define a rule:

IF {tenant_id} = 'customer-123', {customer_id} IN (SELECT customer_id FROM customers WHERE tenant_id = 'customer-123')

Now each tenant only sees their own customers, even though they’re querying the same warehouse.

For a full multi-tenant SaaS setup with embedded Superset, PADISO’s platform engineering teams can design and build the architecture. We’ve done this for financial services, retail, and media companies across Australia, North America, and beyond.

---

Troubleshooting Common Issues {#troubleshooting}

Even with careful planning, things go wrong. Here are the most common issues and how to fix them.

Dashboard Loads Slowly

Symptom: A dashboard takes > 10 seconds to load.

Diagnosis:

1. Check the query execution time. Go to Settings → Query History. Which chart is slow?
2. Run the underlying SQL directly against your warehouse. How long does it take?
3. Is the issue the query or Superset rendering?

Fix:

• If the query is slow: Optimise the SQL (add indexes, pre-aggregate, filter early).
• If Superset rendering is slow: Reduce the number of visualisations on the dashboard. Move some to a separate dashboard.
• If caching is the issue: Reduce the cache timeout so data refreshes more frequently.

Data Doesn’t Match Our System of Record

Symptom: “The MRR in Superset is $150K, but our accounting system shows $155K.”

Diagnosis:

1. Check the definition of MRR in Superset. Is it including all subscription types?
2. Check the data pipeline. When was the data last refreshed?
3. Reconcile manually. Pull data from both systems and compare.

Fix:

• If the definition is wrong: Update the dataset SQL.
• If the pipeline is stale: Increase refresh frequency.
• If there’s a systematic difference: Document it and update the dashboard description.

Always have a single source of truth for key metrics. If accounting says MRR is $155K, that’s the number. Superset should match it (or document why it doesn’t).

Users Can’t See Their Data

Symptom: “I can see the sales dashboard, but it’s showing all segments, not just Enterprise.”

Diagnosis:

1. Check the user’s role. Do they have RLS rules applied?
2. Check the RLS rule. Is it correctly filtering the data?
3. Check the dataset. Does it have the right column for filtering?

Fix:

• If RLS isn’t applied: Go to Settings → Roles → [User Role] → Row-Level Security. Add a rule.
• If the rule is wrong: Update it. Test with the user to ensure it works.

Superset Instance Keeps Crashing

Symptom: Superset becomes unresponsive or crashes under load.

Diagnosis:

1. Check memory usage. Is Superset running out of RAM?
2. Check database connections. Is the connection pool exhausted?
3. Check query queue. Are there too many queries running simultaneously?

Fix:

• If memory is the issue: Increase the container memory or reduce the number of users.
• If connections are exhausted: Increase the connection pool size.
• If queries are queued: Enable async execution or reduce dashboard refresh frequency.

For production Superset instances, monitor these metrics continuously. Use tools like Prometheus and Grafana to track CPU, memory, and query latency.

New Data Isn’t Appearing

Symptom: “I updated a customer’s segment this morning, but it’s not showing in Superset.”

Diagnosis:

1. Check the data pipeline. When does it run? Has it run since the update?
2. Check the cache. Is the dashboard showing cached data?
3. Check the source system. Is the data actually updated there?

Fix:

• If the pipeline hasn’t run: Wait for it to run, or trigger it manually.
• If the cache is stale: Clear the cache. In Superset, go to Settings → Query History → Clear Cache.
• If the source data is wrong: Fix the source system first.

For time-sensitive data, reduce cache timeouts. For data that changes frequently, consider real-time pipelines (using tools like Kafka or Dataflow).

---

Next Steps and Implementation {#next-steps}

You now have a comprehensive guide to building executive reporting in Superset. Here’s how to get started:

Week 1–2: Foundation

1. Assess your data stack. Do you have a data warehouse? If not, set up Snowflake or BigQuery.
2. Design your semantic layer. What are the 5–10 key metrics your executives need? Define them in SQL.
3. Set up Superset. Deploy it (self-hosted or Preset Cloud). Connect it to your warehouse.
4. Build the executive dashboard. Start with MRR, customers, churn, and runway.

Week 3–4: Expansion

1. Build functional dashboards. Sales, product, finance, operations.
2. Set up access control. Who sees what? Implement RLS if needed.
3. Optimise performance. Identify slow queries and fix them.
4. Document everything. Datasets, dashboards, definitions.

Week 5+: Rollout and Iteration

1. Pilot with leadership. Get buy-in and iterate.
2. Roll out to teams. Train and support.
3. Monitor and maintain. Track usage, fix issues, add new dashboards.
4. Iterate. Superset is not a one-time project. It evolves with your business.

Getting Help

If you’re building Superset dashboards at scale, you’ll likely need help:

• Data pipeline design: PADISO’s platform engineering teams design and operate data warehouses, ETL pipelines, and semantic layers across Australia, North America, and beyond.
• Superset deployment and optimisation: We’ve embedded Superset into multi-tenant SaaS architectures, replacing per-seat BI and cutting costs by 60–70%.
• Security and compliance: If your dashboards contain sensitive data, PADISO’s Security Audit service ensures your Superset instance is audit-ready for SOC 2 and ISO 27001.

For SaaS organisations in Sydney, Melbourne, or across Australia, PADISO’s platform engineering can help you design, build, and operate Superset alongside your data stack. For North American teams, we have offices in San Francisco, Seattle, Austin, Dallas, Chicago, New York, Washington DC, and Toronto.

Key Takeaways

1. Superset is a cost-effective, open-source alternative to per-seat BI tools. For SaaS organisations scaling fast, it’s a game-changer.

2. Data modelling is everything. Invest time in clean datasets and a well-designed semantic layer. Dashboards are only as good as the data underneath.

3. Design for clarity. One question per chart. Use the right visualisation. Provide context. Make filtering easy.

4. Performance matters. Optimise queries, set appropriate cache timeouts, and monitor your instance continuously.

5. Governance scales. As Superset grows, restrict dataset creation, implement RLS, and use naming conventions.

6. Rollout in phases. Pilot with leadership, expand to teams, then enable self-service.

7. Monitor and iterate. Superset is not a one-time project. It evolves with your business.

Executive reporting in Superset is achievable in weeks, not months. The teams we’ve worked with have gone from manual spreadsheets to automated dashboards in 4–6 weeks. The result: executives who understand their business, teams that make data-driven decisions, and a cost structure that scales with your data, not your headcount.

If you’re ready to build, PADISO’s platform engineering teams can help. We design and operate Superset instances for SaaS organisations, startups, and enterprises across the world. Book a call to discuss your use case.