Table of Contents
- Executive Summary: Why This Comparison Matters
- The Core Difference: Open Source vs Managed SaaS
- Total Cost of Ownership: The Real Numbers
- Governance, Security and Compliance
- Embedding Analytics: Superset vs Preset
- Semantic Layer and Data Modelling
- Team Experience and Operational Burden
- Scaling Considerations for 2026
- Decision Matrix and Selection Criteria
- Implementation Paths and Next Steps
Executive Summary: Why This Comparison Matters
If you’re evaluating business intelligence platforms in 2026, you’ve likely encountered both Apache Superset and Preset. They’re not competitors in the traditional sense—Preset is built on top of Superset—but they represent fundamentally different choices about how you want to operate your analytics stack.
The decision isn’t about features. Both platforms offer dashboards, charts, SQL editors, and data exploration tools. The decision is about control, cost, team capacity, and governance. Choose Superset if you have engineering bandwidth to manage infrastructure, customize deeply, and own the operational burden. Choose Preset if you want analytics delivered as a service, with Preset’s team handling upgrades, scaling, and platform reliability.
This guide cuts through the marketing and gives you the framework to decide. We’ve worked with teams across financial services, retail, and media who’ve made both choices—and we’ll share what they learned.
The Core Difference: Open Source vs Managed SaaS
What Apache Superset Actually Is
Apache Superset is an open-source data visualisation and business intelligence platform maintained by the Apache Software Foundation. It’s written in Python and React, licensed under the Apache License 2.0, and available for anyone to download, modify, and deploy.
When you choose Superset, you’re choosing to run and maintain the platform yourself. You provision the infrastructure (cloud or on-premises), manage the database, handle upgrades, patch security vulnerabilities, and troubleshoot issues. Superset provides the software; you provide everything else.
The upside: complete control. You can modify the codebase, integrate it deeply with your systems, and optimise it for your specific use case. The downside: you own the operational complexity.
What Preset Adds to That
Preset is a managed SaaS platform built on top of Apache Superset. Preset runs Superset for you—they handle infrastructure, upgrades, security patches, and scaling. You log in and build dashboards; Preset’s team ensures the platform stays up, fast, and secure.
Preset also adds features that Superset doesn’t have out of the box: managed multi-tenancy, role-based access control (RBAC) at scale, audit logging, semantic layers, and integrated alerting. These features simplify operations for teams that need enterprise-grade governance.
The trade-off is straightforward: you pay a monthly subscription and give up some customisation flexibility. But you get a team of engineers working on your platform 24/7.
Why This Distinction Matters Now
In 2024–2025, both platforms matured significantly. Superset’s community grew, the codebase stabilised, and organisations started running it in production at scale. Simultaneously, Preset refined its offering, added semantic layer capabilities, and expanded its feature set beyond what the open-source project offers.
This means the decision is no longer “open source vs SaaS” in the abstract. It’s “do you want to operate analytics infrastructure, or do you want a vendor to do it for you?” That’s a very different question.
Total Cost of Ownership: The Real Numbers
Superset TCO: What You Actually Spend
Superset is free to download, but “free software” doesn’t mean “free to operate.” Here’s what organisations typically spend:
Infrastructure costs:
- Compute (app servers, workers): $500–$2,000/month depending on scale
- Database (PostgreSQL or MySQL for metadata): $200–$500/month
- Redis (for caching and task queues): $100–$300/month
- Load balancing, monitoring, logging: $300–$800/month
Total infrastructure: $1,100–$3,600/month for a mid-sized deployment.
Labour costs (the real expense):
- Initial setup and customisation: 4–12 weeks of engineering time
- Ongoing maintenance (security patches, upgrades, troubleshooting): 1–2 FTE per 50–100 dashboard users
- Feature development and customisation: highly variable, but expect 2–4 weeks per major customisation
For a team of 50 analytics users, you’re looking at roughly 0.5–1 FTE dedicated to Superset operations, which at AU$150K–$200K per year equals $75K–$200K annually in salary cost.
Total Superset TCO for 50 users: $25K–$45K infrastructure + $75K–$200K labour = $100K–$245K per year.
If you have 200+ users, the labour cost per user drops (one person can manage more dashboards), but infrastructure scales up. Expect $200K–$400K annually for a large Superset deployment.
Preset TCO: Subscription + Minimal Ops
Preset pricing is usage-based, but typical costs are:
- Standard tier: AU$2,000–$5,000/month for 50–100 users
- Pro tier: AU$5,000–$15,000/month for 100–500 users with advanced governance
- Enterprise: Custom pricing for 500+ users, custom integrations, and SLAs
For 50 users, expect AU$24K–$60K annually. For 200 users, AU$60K–$180K annually.
The labour cost is near zero. Preset’s team handles infrastructure, upgrades, and scaling. Your team spends time building dashboards and managing data governance, not running the platform.
Total Preset TCO for 50 users: $24K–$60K (subscription only). For 200 users: $60K–$180K.
TCO Comparison: The Crossover Point
Superset looks cheaper if you have spare engineering capacity. If you have an engineer who’s already managing cloud infrastructure and can dedicate 20% of their time to Superset, the labour cost is embedded in their salary anyway—you’re not hiring someone new.
But if you need to hire someone, or if your existing engineers are at capacity, Preset becomes cost-competitive or cheaper. Here’s why:
- 50 users: Superset ($100K–$245K) vs Preset ($24K–$60K). Superset loses unless you have free labour.
- 100 users: Superset ($150K–$300K) vs Preset ($40K–$100K). Still favours Preset.
- 200 users: Superset ($200K–$400K) vs Preset ($60K–$180K). Preset wins unless Superset labour is nearly free.
- 500+ users: Superset and Preset approach parity, but Preset’s advantage in governance and multi-tenancy becomes the differentiator.
The key variable: how much engineering time does your team actually have? If you’re hiring for it, Preset is cheaper. If you have idle capacity, Superset might make sense.
Governance, Security and Compliance
Superset’s Governance Model
Superset includes basic access control: you can assign users to roles and restrict which databases they can query. But governance at scale requires customisation.
For organisations pursuing SOC 2 or ISO 27001 compliance, Superset requires manual work:
- Audit logging isn’t enabled by default; you must configure it
- Row-level security (RLS) exists but requires custom SQL rules per dataset
- User provisioning and de-provisioning must be managed manually or integrated with your identity provider (Okta, Azure AD)
- Encryption at rest and in transit must be configured separately
Many organisations we’ve worked with at PADISO have built Superset deployments that pass compliance audits, but it requires engineering effort. You’re essentially building governance on top of Superset, not buying it.
Preset’s Governance Advantage
Preset was designed for regulated industries. It includes:
- Audit logging: every action (login, dashboard view, query execution) is logged and exportable
- RBAC at scale: manage permissions per workspace, dataset, and dashboard without custom code
- Single sign-on (SSO): built-in support for Okta, Azure AD, Google Workspace
- Data lineage: track which dashboards depend on which datasets
- Encryption: TLS in transit, encrypted at rest by default
Preset’s compliance posture is stronger out of the box. If you’re preparing for a SOC 2 audit, Preset’s governance features mean less custom engineering.
Compliance and Audit Readiness
If compliance is a priority, Preset saves time. But neither platform is a compliance solution on its own—you still need to manage data access, document your processes, and maintain audit trails. The difference is that Preset gives you more of the infrastructure for free.
For teams modernising regulated monoliths or running multi-tenant SaaS platforms, PADISO’s platform development services can help you architect Superset or Preset into a compliant data layer, paired with backend systems that enforce governance at the source.
Embedding Analytics: Superset vs Preset
Why Embedding Matters
If you’re building a product that includes analytics—whether it’s a SaaS platform, a customer portal, or an internal application—you need to embed your BI tool. Embedding means your end users see dashboards inside your application, not in a separate analytics tool.
Both Superset and Preset support embedding, but they approach it differently.
Superset Embedding: Flexibility, Complexity
Superset’s embedding is flexible. You can:
- Embed dashboards and charts in your application using iframes
- Generate signed URLs that allow temporary, unauthenticated access
- Use the REST API to fetch chart data and render it in your own UI
- Customise the embedded experience by modifying Superset’s React components
The downside: you’re responsible for managing authentication, session handling, and performance. If you embed dashboards for thousands of users, you need to think about caching, database query limits, and load balancing.
Many organisations embedding Superset at scale have built custom wrappers around it—essentially building a lightweight BI layer on top of Superset. This works, but it’s engineering effort.
Preset Embedding: Managed, Simpler
Preset’s embedding is more opinionated. You embed dashboards using Preset’s API, and Preset handles authentication, performance, and scaling. You don’t manage sessions or worry about query limits—Preset does.
Preset also offers white-label embedding, where dashboards appear to come from your brand, not from Preset. This is valuable if you’re selling analytics as part of your product.
The trade-off: less customisation. You can’t modify Preset’s embedded UI the way you can with Superset. But for most use cases, Preset’s embedding is sufficient and requires less engineering.
Embedding at Scale
If you’re embedding analytics for 1,000+ external users, Preset’s managed approach is usually cheaper and faster to implement. If you need deep customisation of the embedded experience, Superset gives you more control—but you own the operational burden.
Teams at PADISO working on platform development often pair embedded Superset with ClickHouse (a columnar database) to handle high-concurrency analytics queries. This architecture works well for multi-tenant SaaS platforms where you need to embed analytics for each customer.
Semantic Layer and Data Modelling
What a Semantic Layer Does
A semantic layer sits between your data warehouse and your BI tool. It lets you define metrics, dimensions, and business logic once—in code or YAML—and reuse them across all dashboards. This prevents inconsistency (different teams calculating “revenue” differently) and speeds up dashboard development.
For example, instead of writing the same SQL to calculate “monthly recurring revenue” in 50 dashboards, you define it once in the semantic layer and reference it everywhere.
Superset’s Semantic Layer Approach
Superset doesn’t have a built-in semantic layer. Instead, it relies on:
- Datasets: you define a SQL query or table, and Superset treats it as a reusable dataset
- Columns: you can add custom SQL expressions to datasets
- Virtual datasets: you can create datasets that combine multiple tables
This works, but it’s not a true semantic layer. You’re still writing SQL in Superset, not defining metrics in a semantic framework. If you want a proper semantic layer, you need to add a separate tool like dbt (data build tool) or Cube.
Preset’s Semantic Layer
Preset includes a semantic layer (called the “Preset Semantic Layer”) that lets you define metrics and dimensions in YAML. You can then reference these in dashboards without writing SQL.
This is a significant advantage for large teams. Instead of 50 analysts writing 50 different versions of “revenue,” you have one definition that everyone uses.
Semantic Layer and Data Governance
A semantic layer also improves governance. When metrics are defined centrally, you can audit where they’re used, who modified them, and when. This is valuable for compliance and data governance.
If semantic layer capabilities are important to your organisation, Preset has a built-in advantage. If you choose Superset, you’ll need to integrate dbt or another semantic layer tool separately.
Team Experience and Operational Burden
Superset: The Operational Reality
Running Superset requires ongoing work:
Day 1–Week 2: Setup and configuration
- Provision infrastructure (Kubernetes or cloud VMs)
- Configure the metadata database
- Set up authentication (Okta, LDAP, etc.)
- Integrate data sources (data warehouse, databases)
Week 3–Month 3: Initial customisation
- Create dashboards and datasets
- Configure permissions
- Set up monitoring and alerting
- Tune performance (caching, query limits)
Ongoing: Maintenance and support
- Monitor infrastructure (CPU, memory, disk usage)
- Upgrade Superset (quarterly, with testing)
- Patch security vulnerabilities (as they’re released)
- Troubleshoot slow queries and performance issues
- Add new data sources and datasets
- Support users (training, dashboard requests)
For a team of 50 analytics users, this typically requires 0.5–1 FTE. For 200+ users, you might need a dedicated analytics engineer or platform team.
Team experience: Your team becomes operators of a BI platform, not just users. This can be a strength (you control everything) or a burden (you’re responsible for uptime).
Preset: The Managed Experience
With Preset, the operational burden shifts to Preset’s team:
Day 1–Day 3: Onboarding
- Follow Preset’s getting started guide
- Connect your data sources
- Create your first workspace
Week 1–Week 4: Initial dashboards
- Build dashboards
- Configure permissions
- Invite team members
Ongoing: Focus on analytics, not operations
- Build dashboards
- Manage data governance
- Support users
- Iterate on metrics and visualisations
Preset handles everything else: infrastructure, upgrades, scaling, security patches, monitoring.
Team experience: Your team focuses on analytics and insights, not platform operations. This is often more satisfying for data analysts and less stressful for engineering teams.
Which Model Fits Your Team?
Choose Superset if:
- You have an engineering team that enjoys infrastructure work
- You have spare capacity (someone’s already managing cloud infrastructure)
- You need deep customisation or have unusual integration requirements
- You’re in a regulated environment and want to audit every line of code
Choose Preset if:
- You want to focus on analytics, not operations
- Your team is lean and can’t spare someone for platform maintenance
- You value simplicity and want things to “just work”
- You’re growing fast and don’t want to manage scaling
Scaling Considerations for 2026
Superset at Scale: What Changes
Superset scales well technically, but operationally it becomes more complex:
Query performance: As your data warehouse grows (10TB+), queries slow down. You need to optimise:
- Database indexes
- Caching strategies (Redis, query caching)
- Query limits (prevent runaway queries)
- Asynchronous query execution (for long-running queries)
Infrastructure: At 500+ users, you need:
- Multiple app servers (load balanced)
- Dedicated metadata database with replication
- Distributed caching
- Monitoring and alerting (Prometheus, Grafana, etc.)
Team: You might need a dedicated analytics platform team (2–3 people) to manage this.
Preset at Scale: Built-in Scaling
Preset’s infrastructure scales automatically. You don’t need to think about load balancing, caching, or database replication. Preset handles it.
The trade-off: less visibility into how your queries are executed. If you need to debug a slow query, you’re relying on Preset’s support team.
Multi-Tenancy and Isolation
If you’re building a multi-tenant SaaS platform and embedding analytics for each customer, both Superset and Preset can work—but they require different architectures.
Superset multi-tenancy: You either run a separate Superset instance per customer (expensive) or build custom code to isolate data and permissions within a single instance (complex).
Preset multi-tenancy: Preset’s managed multi-tenancy is built in. You create a workspace per customer, and Preset handles isolation.
For SaaS platforms, Preset’s multi-tenancy is a significant advantage. Teams building multi-tenant platforms often choose Preset for this reason alone.
Data Warehouse Considerations
Both Superset and Preset work with any SQL-compatible data warehouse (Snowflake, BigQuery, Redshift, ClickHouse, etc.). But at scale, your choice of data warehouse matters more than your choice of BI tool.
For high-concurrency analytics (many users querying simultaneously), columnar databases like ClickHouse or Snowflake are essential. For OLTP-style queries, traditional data warehouses work fine.
Teams building data platforms often pair Superset with ClickHouse for cost-effective, high-concurrency analytics. This architecture can handle 1,000+ concurrent users at a fraction of the cost of traditional data warehouses.
Decision Matrix and Selection Criteria
Scoring Framework
Use this matrix to evaluate Superset vs Preset for your specific situation. Score each criterion 1–5 (1 = Superset, 5 = Preset), then average.
| Criterion | Weight | Superset Strength | Preset Strength | Your Score |
|---|---|---|---|---|
| Cost (assuming no free labour) | 20% | Low monthly cost, high labour | Higher monthly cost, low labour | |
| Governance & Compliance | 15% | Requires customisation | Built-in RBAC, audit logging | |
| Embedding | 10% | Highly customisable | Managed, white-label | |
| Semantic Layer | 10% | Requires external tools | Built-in | |
| Operational Burden | 20% | High (you operate it) | Low (Preset operates it) | |
| Scaling | 10% | Possible, but complex | Automatic | |
| Customisation | 10% | Unlimited | Limited | |
| Team Capacity | 5% | Requires engineering time | Minimal |
Scoring guide:
- 1–2: Strongly favours Superset
- 2–3: Slightly favours Superset
- 3–4: Slightly favours Preset
- 4–5: Strongly favours Preset
Decision Trees
Question 1: Do you have a dedicated engineer to manage analytics infrastructure?
- Yes → Consider Superset
- No → Preset is likely better
Question 2: Do you need to embed analytics in your product?
- Yes, and you need deep customisation → Superset
- Yes, but standard embedding is fine → Preset
- No → Either works
Question 3: Are you in a regulated industry (financial services, healthcare, etc.)?
- Yes → Preset (built-in governance)
- No → Either works
Question 4: Do you have 500+ analytics users?
- Yes → Preset (scaling is automatic)
- No → Either works
Question 5: What’s your budget?
- Minimal, with free labour available → Superset
- Moderate (AU$50K–$200K/year) → Preset
- Large (AU$200K+/year) → Either works
Implementation Paths and Next Steps
If You Choose Superset
Phase 1: Proof of Concept (Weeks 1–2)
- Deploy Superset on a single cloud VM or Kubernetes cluster
- Connect one data source (your data warehouse or database)
- Build 3–5 sample dashboards
- Test with a small user group
Phase 2: Production Setup (Weeks 3–8)
- Design infrastructure (HA setup, load balancing, monitoring)
- Configure authentication (SSO, LDAP, or Okta)
- Set up the metadata database with replication
- Implement caching and query optimisation
- Create documentation and runbooks
Phase 3: Rollout (Weeks 9–16)
- Migrate dashboards from legacy BI tool (if applicable)
- Train users
- Set up support processes
- Monitor performance and iterate
Team: 1–2 engineers for setup, then 0.5–1 FTE for ongoing maintenance.
Timeline: 3–4 months to production.
If You Choose Preset
Phase 1: Onboarding (Days 1–3)
- Sign up for Preset
- Follow the getting started guide
- Connect your data sources
- Create your first workspace
Phase 2: Initial Dashboards (Weeks 1–2)
- Build 10–20 dashboards
- Configure permissions and workspaces
- Invite team members
- Test embedding (if applicable)
Phase 3: Rollout (Weeks 3–4)
- Migrate dashboards from legacy BI tool
- Train users
- Set up governance policies
Team: 1 data analyst or BI engineer to manage dashboards and data governance. No infrastructure work required.
Timeline: 2–4 weeks to production.
Hybrid Approach: Superset + Preset
Some organisations run both:
- Superset for internal, highly customised dashboards where engineering is available
- Preset for customer-facing analytics and embedded use cases
This works if you have the team capacity, but it adds operational complexity. Only consider this if you have strong reasons for both (e.g., you’re embedding analytics for customers and building custom internal dashboards).
Getting External Help
If you’re evaluating Superset or Preset as part of a larger data platform initiative, external expertise can accelerate your decision and implementation.
PADISO’s platform development services help organisations architect data platforms with embedded analytics. We’ve implemented both Superset and Preset for clients across financial services, retail, and media. If you’re building a multi-tenant SaaS platform, modernising a regulated monolith, or scaling your analytics infrastructure, we can help you evaluate both platforms in the context of your broader architecture.
We also offer AI Quickstart Audits—a fixed-fee, 2-week diagnostic that tells you where you actually are, what to ship first, and what 90 days could unlock. If your data platform choice depends on broader AI and automation strategy, this audit can provide clarity.
For teams pursuing compliance, PADISO + Vanta gets you to SOC 2 and ISO 27001 audit-ready in weeks, not months. If governance is a key factor in your Superset vs Preset decision, we can help you architect compliance into whichever platform you choose.
Summary: Your 2026 Decision
Choose Apache Superset if:
- You have engineering capacity to operate a BI platform
- You need deep customisation or have unusual integration requirements
- You’re cost-sensitive and have free labour available
- You want complete control and don’t mind the operational burden
Choose Preset if:
- You want analytics delivered as a service
- You’re in a regulated industry and need built-in governance
- You’re embedding analytics in a product and want white-label capabilities
- You’re scaling fast and don’t want to manage infrastructure
- Your team is lean and can’t spare engineering time
The real decision is about trade-offs: Superset trades operational burden for control and cost. Preset trades customisation for simplicity and scale.
Neither is “better”—they’re different tools for different situations. Evaluate based on your team’s capacity, your budget (including labour), and your governance requirements.
If you’re building a data platform and want to discuss how Superset or Preset fits into your broader architecture, PADISO’s platform engineering teams can help. We work with founders, CTOs, and data leaders across Australia and North America to architect platforms that scale. Book a call to discuss your specific situation.