Apache Superset for SaaS Metrics: A Reference Dashboard Set

Table of Contents

1. Why Superset for SaaS Metrics
2. Core SaaS Metrics Every Dashboard Needs
3. Data Model Architecture for Scale
4. Building Your Reference Dashboard Set
5. Drilldown Patterns and Interactivity
6. Schema Patterns That Survive Growth
7. Security, Compliance and Access Control
8. Implementation and Operations
9. Moving from Superset to Embedded Analytics
10. Next Steps

---

Why Superset for SaaS Metrics

If you’re running a SaaS business, you need to see your metrics in real time. Revenue, churn, customer acquisition cost (CAC), lifetime value (LTV), expansion revenue, net revenue retention (NRR)—these aren’t vanity numbers. They’re the heartbeat of your company. Yet most founders and operators still rely on spreadsheets, fragmented BI tools, or dashboards that take weeks to build and cost tens of thousands per seat.

Apache Superset changes that. It’s an open-source data visualisation and business intelligence platform that lets you build production-grade dashboards in hours, not months. It’s fast, flexible, and designed for teams that need to ship analytics without being locked into expensive per-seat licensing or vendor lock-in.

Unlike traditional BI tools, Superset gives you full control over your data model, your schema, and your infrastructure. You can run it on your own servers, embed it in your product, or use a managed hosting provider. You define the metrics. You own the queries. You decide who sees what.

For SaaS teams—especially founders and CEOs at seed-to-Series-B startups who need fractional CTO leadership—Superset is the fastest path from raw data to actionable insight. It integrates with PostgreSQL, MySQL, Snowflake, BigQuery, ClickHouse, and dozens of other databases. It supports SQL, Python, and pre-built visualisation components. And it’s free.

But free doesn’t mean simple. Building a reference dashboard set that actually scales—one that survives your first 10x in data volume, your first acquisition, your first SOC 2 audit—requires discipline in data modelling, metric definition, and schema design.

This guide walks you through exactly how to build that.

---

Core SaaS Metrics Every Dashboard Needs

Before you build a single chart, you need to agree on what you’re measuring. This sounds obvious. It’s not. Most SaaS teams have three different definitions of “Monthly Recurring Revenue” floating around their company, and they don’t realise it until their board meeting.

Revenue and Growth Metrics

SaaS KPIs like Monthly Recurring Revenue (MRR), Annual Recurring Revenue (ARR), and growth rate form the foundation of any SaaS dashboard. But MRR isn’t just the sum of your subscription fees. It’s:

• New MRR from new customers
• Expansion MRR from upsells and add-ons
• Churn MRR from cancellations
• Contraction MRR from downgrades

Your dashboard needs to show all four, not just the net. Why? Because a company with flat MRR but high churn and high new sales is in a very different position than a company with flat MRR and low churn. One is a leaky bucket; the other is stable.

Similarly, ARR and MRR tracking should include visibility into cohort-based growth, so you can see whether your Q1 cohort is retaining better than your Q4 cohort. That signals whether your product is improving or whether you’re just acquiring a different type of customer.

Total revenue also needs to account for one-time fees, professional services, and ancillary revenue streams. Don’t hide them in a line item. Call them out explicitly.

Retention and Churn

Retention is the metric that separates successful SaaS companies from ones that look successful until they don’t. Net Revenue Retention (NRR) and gross revenue retention (GRR) are the metrics that matter, but they’re often calculated wrong.

Gross Revenue Retention (GRR) = (Beginning MRR − Churn MRR) / Beginning MRR × 100%

Net Revenue Retention (NRR) = (Beginning MRR − Churn MRR + Expansion MRR) / Beginning MRR × 100%

An NRR above 100% means you’re growing revenue from your existing customer base, even before you acquire a single new customer. That’s the holy grail. Most investors won’t fund a SaaS company with an NRR below 90%. Above 120%, you’re in elite company.

Your dashboard needs to show both cohort-based NRR (how are customers acquired in January performing versus February?) and rolling NRR (what’s your 12-month trend?). You also need to segment by customer segment, geography, and product tier. Churn isn’t uniform. Some segments are sticky; others bleed out. You need to know which is which.

Customer Acquisition and Unit Economics

Customer Acquisition Cost (CAC), payback period, and Customer Lifetime Value (LTV) are the metrics that determine whether your go-to-market motion is sustainable. They’re also some of the most commonly miscalculated metrics in SaaS.

CAC = Total Sales & Marketing Spend / Number of New Customers Acquired

LTV = Average Revenue Per Account × Gross Margin / Monthly Churn Rate

CAC Payback Period = CAC / Monthly Profit Per Customer

Your dashboard should show CAC by channel (direct sales, self-serve, partner, etc.), CAC by cohort (are your acquisition costs rising or falling?), and CAC payback period by segment. If you’re spending $100 to acquire a customer and it takes 18 months to break even, that’s a problem. If it takes 6 months, you’re doing well.

LTV:CAC ratio is the metric most investors obsess over. A ratio of 3:1 or higher is considered healthy. Below 1:1 and you’re burning money on every customer you acquire.

Expansion and Contraction

Expansion revenue—upsells, add-ons, increased usage—is often the biggest lever for SaaS growth, especially once you’ve optimised acquisition. Yet most dashboards don’t track it.

Your reference dashboard should show:

• Net expansion revenue (MRR increase from existing customers)
• Expansion rate (percentage of customers that expanded in the period)
• Average expansion value per expanding customer
• Contraction rate and contraction MRR
• Downgrades versus cancellations

Downgrades often signal product-market fit problems. A customer who downgrades is still a customer—they’re just using less. A customer who churns is gone. Your dashboard needs to flag both, because they require different interventions.

Operational Metrics

Sales cycle length, win rate, pipeline coverage, and forecast accuracy aren’t glamorous, but they predict revenue better than almost any other metric. If your sales cycle is lengthening, your win rate is falling, or your forecast accuracy is in the gutter, your revenue metrics will follow.

Your dashboard should also track:

• Time to first value (how long before a new customer gets value from your product?)
• Onboarding completion rate (what percentage of customers complete onboarding?)
• Feature adoption rate (which features are actually being used?)
• Support ticket volume and resolution time
• Product-qualified leads (PQLs) and their conversion rate

These metrics are leading indicators. Revenue metrics are lagging indicators. Track both.

---

Data Model Architecture for Scale

Now that you know what you’re measuring, you need to design a data model that can support it without melting down when you hit 100M rows of data.

Fact and Dimension Tables

The most scalable approach is a star schema: fact tables surrounded by dimension tables. This isn’t new—it’s been the standard in data warehousing for 30 years—but it’s still the right approach.

A fact table contains the events: subscriptions created, payments processed, cancellations, upsells. Each row is a discrete event with a timestamp and a reference to relevant dimensions.

Dimension tables contain the attributes: customer information, product information, plan information, geography. They’re typically much smaller than fact tables and change infrequently.

For a SaaS metrics dashboard, you might have:

• fct_subscriptions: subscription creation, plan, price, currency, customer_id, created_date
• fct_payments: payment_id, subscription_id, amount, currency, payment_date, payment_status
• fct_churn_events: subscription_id, churn_date, reason, mrr_lost, customer_id
• fct_expansion_events: subscription_id, expansion_date, mrr_increase, customer_id
• dim_customers: customer_id, company_name, industry, geography, cohort_date, customer_segment
• dim_products: product_id, product_name, product_tier, feature_set
• dim_plans: plan_id, plan_name, price, currency, billing_frequency

This structure lets you query MRR, churn, expansion, and cohort retention in a single join, without materialising 10 different aggregation tables.

Incremental Loads and Slowly Changing Dimensions

As your data grows, full refreshes of your fact tables become expensive. You need incremental loads: only fetch the new or changed data since the last run.

For subscriptions, this means:

• Load all subscriptions created since the last run
• Load all subscriptions updated since the last run (status changes, plan changes, etc.)
• Deduplicate by subscription_id and keep the most recent record

For dimensions like customers, you need to handle slowly changing dimensions (SCDs). A customer’s company name might change. Their industry might be recategorised. Their segment might be reassigned. You have a few options:

• Type 1: Overwrite the old value. Simple, but you lose history.
• Type 2: Add a new row with a new effective date range. You keep history, but queries get complex.
• Type 3: Keep the old and new values in separate columns. A compromise, but limited to a few attributes.

For SaaS metrics, Type 2 is usually best. You want to know what segment a customer was in when they churned, not what segment they’re in now.

Aggregate Tables and Materialized Views

Once your fact tables get large (100M+ rows), even simple queries can slow down. That’s when you need aggregate tables: pre-computed summaries of your data.

Common aggregates for SaaS:

• agg_mrr_by_month_customer: MRR by month and customer
• agg_mrr_by_month_segment: MRR by month and customer segment
• agg_cohort_retention: retention rates by cohort
• agg_daily_metrics: daily snapshots of MRR, churn, expansion

These can be materialised views (computed once a day and stored) or tables (computed and stored explicitly). Either way, they’re much faster to query than the underlying facts.

Superset can query either facts or aggregates. The key is having both available so you can choose the right level of granularity for each dashboard.

---

Building Your Reference Dashboard Set

A reference dashboard set isn’t a single dashboard. It’s a collection of dashboards, each designed for a specific audience and purpose.

Executive Dashboard

The executive dashboard is for your board, your investors, and your CEO. It should fit on a single screen (or scroll minimally) and answer one question: “How is the business?” in 30 seconds.

Key charts:

1. MRR and MRR Growth: A line chart showing MRR over time with a trend line. Include month-over-month growth rate as a KPI card.
2. MRR Waterfall: A waterfall chart showing beginning MRR, new MRR, expansion MRR, churn MRR, contraction MRR, and ending MRR. This shows where your growth is coming from.
3. NRR: A gauge or scorecard showing your current NRR. Colour-coded: green above 100%, yellow 80-100%, red below 80%.
4. CAC and LTV: Two KPI cards showing CAC and LTV, with a third card showing LTV:CAC ratio.
5. Churn Rate: A line chart showing monthly churn rate over time. Include both gross and net churn.
6. Customer Count: A line chart showing total customers, new customers, and churned customers by month.

All charts should have a date filter (last 12 months, last quarter, etc.) and segment filters (by product, by geography, by customer segment).

Operations Dashboard

The operations dashboard is for your head of sales, your head of product, and your CFO. It dives deeper into the leading indicators that predict revenue.

Key charts:

1. Sales Pipeline: A funnel chart showing leads, opportunities, proposals, and closed deals. Include conversion rates between each stage.
2. Sales Cycle Length: A histogram showing the distribution of sales cycle lengths by month. Overlay a trend line.
3. Win Rate by Month: A line chart showing win rate over time, segmented by sales team or sales rep.
4. Forecast Accuracy: A scatter plot showing forecasted revenue versus actual revenue by month. Include a trend line.
5. Time to First Value: A histogram showing the distribution of days from sign-up to first login, first feature use, etc.
6. Onboarding Completion: A funnel chart showing the percentage of new customers completing each onboarding step.
7. Feature Adoption: A bar chart showing the percentage of customers using each feature, segmented by customer segment or plan tier.

Retention and Cohort Dashboard

The retention dashboard is for your product team and your growth team. It shows how well you’re keeping customers and whether your product is improving.

Key charts:

1. Cohort Retention Matrix: A heatmap showing retention rates for each cohort (rows) by month since acquisition (columns). This is the gold standard for retention analysis.
2. Cohort NRR: A line chart showing NRR for each cohort over time. Are recent cohorts more or less sticky than older cohorts?
3. Churn by Reason: A bar chart showing the number of churned customers by churn reason. What’s killing your retention?
4. Churn by Segment: A bar chart showing churn rate by customer segment. Which segments are leaking?
5. Expansion by Segment: A bar chart showing expansion rate by customer segment. Which segments are buying more?
6. Days to Churn: A histogram showing the distribution of days from sign-up to churn. Are you losing customers quickly or slowly?

Unit Economics Dashboard

The unit economics dashboard is for your CFO and your board. It shows whether your business model is sustainable.

Key charts:

1. CAC by Channel: A bar chart showing CAC for each acquisition channel (direct sales, self-serve, partner, etc.). Include month-over-month trends.
2. CAC Payback Period: A line chart showing CAC payback period over time. Is it getting better or worse?
3. LTV:CAC Ratio: A line chart showing LTV:CAC ratio over time. Is it above 3:1?
4. Gross Margin by Customer Segment: A bar chart showing gross margin (revenue minus COGS) by customer segment. Are some segments more profitable than others?
5. Contribution Margin by Customer: A scatter plot showing contribution margin (revenue minus CAC) versus customer age. Are older customers more profitable?
6. Breakeven Analysis: A line chart showing cumulative profit/loss per cohort over time. When does each cohort break even?

Customer Health Dashboard

The customer health dashboard is for your customer success team. It shows which customers are at risk and which are expanding.

Key charts:

1. At-Risk Customers: A table showing customers with high churn risk, low usage, or declining MRR. Include a risk score.
2. Expansion Opportunities: A table showing customers with high expansion potential based on usage, tenure, and segment.
3. Customer Segment: A scatter plot showing customer LTV versus CAC, coloured by segment. Which segments are most valuable?
4. Usage Trends: A line chart showing total usage (API calls, features used, etc.) over time, segmented by customer or segment.
5. Support Metrics: A bar chart showing average resolution time, ticket volume, and customer satisfaction by segment.

---

Drilldown Patterns and Interactivity

A static dashboard is better than a spreadsheet, but an interactive dashboard is infinitely better than a static one. Superset supports several drilldown patterns that let users explore data without requiring a new query.

Cross-Filtering

When a user clicks on a bar in a bar chart, that filter should propagate to every other chart on the dashboard. Click on “Enterprise” in the segment filter, and every chart should show only Enterprise customers.

Superset does this with native filters and cross-filtering. Set up a filter for segment, connect it to your charts, and clicks automatically filter the data.

Drilldown Links

A drilldown link lets a user click on a value in one chart and navigate to a more detailed dashboard. Click on a customer name in the at-risk customers table, and navigate to a customer detail dashboard showing that customer’s subscription history, usage, support tickets, and NRR.

Superset supports custom links and URL parameters. You can pass the customer_id in the URL and use it to filter the destination dashboard.

Tooltips and Hover Details

When a user hovers over a data point, show additional context. Hover over a bar in the MRR chart, and show the exact MRR, MRR growth rate, and number of customers in that month.

Superset lets you customise tooltips with additional fields from your data model.

Cohort Drilldown

For cohort retention matrices, let users click on a cell to see the detailed customers in that cohort at that month. What’s the average usage for customers who churned in month 3 versus month 6?

This requires linking from the cohort matrix to a detailed customer list, filtered by cohort and month.

Time Series Brushing

When a user selects a time range in a time series chart, that should filter all other charts to that range. This is useful for investigating anomalies. “Why did churn spike in March? Let me look at what happened in March across all metrics.”

Superset’s native filters support this with date range filters.

---

Schema Patterns That Survive Growth

As your company grows, your data grows exponentially. A schema that works for 1M rows will grind to a halt at 100M rows. Here are the patterns that scale.

Partitioning by Time

Partition your fact tables by month or day. This lets the database skip entire partitions when you query a specific time range.

CREATE TABLE fct_subscriptions (
  subscription_id BIGINT,
  customer_id BIGINT,
  plan_id INT,
  price DECIMAL(10,2),
  created_date DATE,
  status VARCHAR(50)
)
PARTITION BY RANGE (YEAR(created_date), MONTH(created_date));

When you query “MRR in the last 3 months”, the database only scans the last 3 month partitions, not the entire table.

Denormalisation for Speed

Normalisation is great for data integrity. Denormalisation is great for query speed. As you grow, you’ll denormalise more.

Instead of joining fct_subscriptions to dim_customers to get the customer segment, store the segment in the fact table. Yes, you’ll have some redundancy. But you’ll eliminate a join, and joins are expensive at scale.

CREATE TABLE fct_subscriptions (
  subscription_id BIGINT,
  customer_id BIGINT,
  customer_segment VARCHAR(50),  -- Denormalised from dim_customers
  plan_id INT,
  price DECIMAL(10,2),
  created_date DATE,
  status VARCHAR(50)
);

Use a Type 2 slowly changing dimension to track when the segment changed, and update the fact table accordingly.

Surrogate Keys

Use surrogate keys (auto-incrementing integers) instead of natural keys (customer IDs, subscription IDs). Surrogate keys are smaller, faster to join, and less likely to collide if you merge data from multiple systems.

CREATE TABLE dim_customers (
  customer_key BIGINT PRIMARY KEY AUTO_INCREMENT,  -- Surrogate key
  customer_id VARCHAR(50),  -- Natural key
  company_name VARCHAR(255),
  industry VARCHAR(100),
  geography VARCHAR(100)
);

In your fact table, reference the surrogate key, not the natural key.

Conformed Dimensions

If you have multiple fact tables (subscriptions, payments, support tickets), they should all reference the same dimension tables. A “customer” in the subscriptions table should be the same “customer” in the payments table.

This is called a conformed dimension. It lets you join facts across different tables without ambiguity.

Aggregate Tables with Proper Grain

When you create aggregate tables, be explicit about the grain: what is the level of detail?

CREATE TABLE agg_mrr_by_month_segment (
  year_month DATE,  -- Grain: month
  customer_segment VARCHAR(50),  -- Grain: segment
  mrr DECIMAL(15,2),
  customer_count INT,
  PRIMARY KEY (year_month, customer_segment)
);

This table has a grain of (month, segment). You can’t drill down to individual customers from this table. If you need to, you need a different aggregate table with a finer grain.

Indexing Strategy

Index the columns you filter on, not every column. For a fact table, index:

• created_date (you filter by date range)
• customer_id (you filter by customer)
• customer_segment (you filter by segment)
• status (you filter by status)

Don’t index every column. Indexes speed up reads but slow down writes. As your data grows, write performance matters.

CREATE INDEX idx_fct_subscriptions_created_date ON fct_subscriptions(created_date);
CREATE INDEX idx_fct_subscriptions_customer_id ON fct_subscriptions(customer_id);
CREATE INDEX idx_fct_subscriptions_segment ON fct_subscriptions(customer_segment);

Data Warehouse Choice

If you’re building a SaaS metrics dashboard and you expect to grow beyond 10M rows, don’t use a transactional database like PostgreSQL. Use a data warehouse like Snowflake, BigQuery, or ClickHouse. These are designed for analytical queries on large datasets.

Snowflake is cloud-native and scales automatically. BigQuery is Google’s managed warehouse and integrates well with Google Cloud. ClickHouse is open-source and extremely fast for time-series data.

Superset works with all of them. Your choice should be based on your existing infrastructure, your team’s expertise, and your budget.

---

Security, Compliance and Access Control

If you’re building dashboards for internal use, security is important. If you’re embedding dashboards in your product or sharing them with customers, security is critical.

Row-Level Security

Row-level security (RLS) restricts the data a user can see based on their identity. A sales rep should only see their own customers. A customer success manager should only see their own accounts.

Superset supports RLS through database views and custom SQL. Create a view that filters data based on the logged-in user, and Superset will enforce that filter.

CREATE VIEW fct_subscriptions_rlc AS
SELECT *
FROM fct_subscriptions
WHERE owner_id = CURRENT_USER;

When a user queries this view, the database automatically filters to their data.

Column-Level Security

Column-level security restricts which columns a user can see. A finance person should see pricing and revenue. A product person shouldn’t.

Superset doesn’t have native column-level security, but you can achieve it by creating different views for different roles.

CREATE VIEW fct_subscriptions_for_product_team AS
SELECT subscription_id, customer_id, plan_id, created_date, status
FROM fct_subscriptions;

CREATE VIEW fct_subscriptions_for_finance_team AS
SELECT subscription_id, customer_id, plan_id, price, revenue, created_date, status
FROM fct_subscriptions;

Connect each role to the appropriate view in Superset.

Authentication and Authorisation

Superset supports multiple authentication methods: username/password, LDAP, OAuth, SAML. Use the one that matches your identity provider.

For authorisation, Superset has role-based access control (RBAC). Create roles (Admin, Analyst, Viewer) and assign permissions (create dashboards, edit dashboards, view dashboards). Assign users to roles.

For SOC 2 and ISO 27001 compliance, you need audit logs. Superset logs all user actions (login, dashboard view, query execution). Export these logs to your SIEM or audit system.

Secrets Management

Superset needs credentials to connect to your database. Don’t store these in plain text. Use a secrets manager like AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets.

Superset can read from these systems at runtime, so credentials are never exposed in configuration files.

Network Security

If Superset is running on your own infrastructure, restrict network access. Only allow connections from your office IP range or through a VPN.

If you’re using a managed Superset service, use IP whitelisting and VPC endpoints to restrict access.

Data Masking

For sensitive data like customer names or email addresses, consider masking them in dashboards. Show only the first letter of a name, or the domain of an email.

Superset supports custom SQL, so you can mask data in your queries:

SELECT
  CONCAT(SUBSTRING(customer_name, 1, 1), '***') AS customer_name,
  CONCAT(SUBSTRING(email, 1, 1), '***@example.com') AS email
FROM dim_customers;

---

Implementation and Operations

Building dashboards is one thing. Operating them in production is another.

Deployment Options

Apache Superset can be deployed in several ways:

1. Self-hosted on your own servers: Full control, but you manage updates, backups, and scaling.
2. Docker containers: Easier to manage than bare metal, but still your responsibility.
3. Kubernetes: Scalable and resilient, but requires Kubernetes expertise.
4. Managed services: Preset (the commercial Superset offering) or other vendors handle infrastructure, but you lose some control.

For a startup, self-hosted on Docker or Kubernetes is a good balance. You get control without managing bare metal.

Refresh Schedules

Dashboards are only useful if they’re up to date. Set up automated refresh schedules for your data.

For real-time dashboards, refresh every 5-15 minutes. For operational dashboards, refresh every hour. For executive dashboards, refresh once a day.

Use a scheduler like Airflow or Prefect to orchestrate your data pipelines. Load new data from your transactional database into your warehouse, compute aggregates, and refresh Superset caches.

Caching

Superset caches query results to speed up subsequent requests. Configure caching based on your refresh schedule.

If your data refreshes every hour, cache results for 50 minutes. If your data refreshes every day, cache for 20 hours.

CACHE_CONFIG = {
    'CACHE_TYPE': 'redis',
    'CACHE_REDIS_URL': 'redis://localhost:6379/0',
    'CACHE_DEFAULT_TIMEOUT': 3600,  # 1 hour
}

Monitoring and Alerting

Use Superset to monitor Superset. Track query performance, error rates, and user activity.

Set up alerts for slow queries (> 30 seconds), failed queries, and unusual spikes in query volume.

Monitor your database performance too. If queries are slow, it’s usually because your database is under load, not because Superset is slow.

Documentation and Training

Your dashboards are only useful if people know how to use them. Document each dashboard:

• What metrics are shown?
• How are they calculated?
• What’s the refresh frequency?
• Who should use this dashboard?
• What actions should you take based on what you see?

Train your team on the dashboards. Show them how to filter, drill down, and export data.

Metric Governance

As you grow, different teams will define metrics differently. Establish a single source of truth.

Create a metric dictionary: a document that defines each metric, how it’s calculated, and who owns it.

Metric: Monthly Recurring Revenue (MRR)
Definition: The sum of all active subscription fees in a given month
Calculation: SUM(price) WHERE status = 'active' AND DATE_TRUNC(created_date, MONTH) = CURRENT_MONTH
Owner: Finance
Refresh Frequency: Daily
Last Updated: 2024-01-15

Version control this dictionary. When you change how MRR is calculated, update the dictionary and version it.

Scaling as You Grow

As your company grows, your data grows exponentially. Monitor your database size and query performance.

When queries start to slow down (> 10 seconds), it’s time to optimise:

1. Add indexes
2. Partition tables
3. Create aggregate tables
4. Move to a larger database instance
5. Consider a different data warehouse

If you’re using platform development and engineering services, your provider can help with this scaling. But it’s useful to understand the principles yourself.

---

Moving from Superset to Embedded Analytics

Eventually, you might want to embed your dashboards in your product. Your customers see their own metrics without leaving your app.

Superset supports embedded analytics through its API and SDK. You can:

1. Create dashboards in Superset
2. Generate guest tokens with row-level security
3. Embed the dashboard in an iframe in your product
4. Your customer sees only their data

This is powerful, but it requires some engineering. Your product needs to:

1. Authenticate the user
2. Generate a guest token for that user
3. Embed the dashboard with that token
4. Handle token refresh and expiration

For SaaS teams building multi-tenant platforms, embedded analytics is a key differentiator. It gives your customers visibility into their usage and ROI, which improves retention.

---

Next Steps

You now have a blueprint for building a production-grade SaaS metrics dashboard in Superset. Here’s how to get started:

Phase 1: Foundation (Weeks 1-2)

1. Set up Superset (self-hosted or managed)
2. Connect it to your data warehouse
3. Define your core metrics (MRR, churn, CAC, LTV)
4. Build your data model (fact and dimension tables)
5. Create your executive dashboard

Phase 2: Depth (Weeks 3-4)

1. Build your operations, retention, and unit economics dashboards
2. Add cross-filtering and drilldown links
3. Set up row-level security
4. Configure refresh schedules and caching

Phase 3: Scale (Weeks 5+)

1. Monitor query performance and optimise
2. Create aggregate tables for slow queries
3. Add customer health and expansion dashboards
4. Train your team
5. Plan for embedded analytics

Getting Help

If you’re a founder or operator building a SaaS company and you need help with your data infrastructure, PADISO can partner with you. We’ve helped seed-to-Series-B startups build scalable data platforms, including Superset implementations.

We also work with mid-market and enterprise teams modernising their analytics infrastructure, moving from per-seat BI tools to open-source alternatives like Superset.

Our platform engineering services cover the full stack: data warehouse design, ETL pipeline orchestration, Superset configuration, and embedded analytics.

If you’re pursuing SOC 2 or ISO 27001 compliance, we can help you design dashboards and data pipelines that pass audit requirements.

Whether you’re in Sydney, Melbourne, Toronto, San Francisco, or anywhere else, we can help you build the dashboards that drive your business.

---

Summary

Apache Superset is a powerful, open-source tool for building SaaS metrics dashboards. But power without discipline leads to chaos. By following this guide—defining your metrics clearly, designing a scalable data model, building a reference dashboard set, and implementing proper security and operations—you’ll have dashboards that actually drive decisions.

Start with your executive dashboard and MRR waterfall. Get that right, and everything else follows. Then layer in your operational, retention, and unit economics dashboards. By week 4, you’ll have a dashboard set that rivals anything built on expensive BI tools, and you’ll own the entire stack.

The rest is discipline: keeping your metrics defined, your data fresh, and your team trained. Do that, and your dashboards will scale from $1M ARR to $100M ARR without breaking.