When self-hosting Superset or buying Preset fits your team
Choose Preset if you want a managed service and accept a per-user bill. Choose self-hosted Apache Superset if your data, infrastructure or identity controls must stay inside your own environment and you have people to operate the stack. Superset itself has no paid edition: the Apache License 2.0 covers the software, so the cost of self-hosting is infrastructure and staff time, not a license fee.
Data location and identity are usually the first triggers. Preset Cloud is a fully managed, cloud-hosted service, so if your policy requires dashboards and metadata to run in your own cloud account or data center, the managed plan is unlikely to pass review without the custom-priced Enterprise plan, which lists Managed Private Cloud deployment. Confirm with Preset which regions and hosting options that plan covers. If you need SSO with SCIM or audit logs, check whether your identity provider can meet your needs through Superset's own OAuth2 or LDAP settings, which map groups to roles through AUTH_ROLES_MAPPING, before you accept the Enterprise tier as the only path.
Budget and staffing decide the rest. Preset's published Professional price is per user, so the bill grows with headcount, and embedded dashboards and viewer licenses are priced separately. Self-hosting shifts cost to a metadata database (PostgreSQL or MySQL, not the SQLite default), a cache, Celery workers and beat processes, plus upgrades that require a backup, superset db upgrade, staging tests and a review of UPDATING.md. Ask your team who will own that work on call. If nobody can, the managed option is the better fit even at a higher recurring cost.
Preset Cloud and self-hosted Superset side by side
This table compares Preset Cloud with a self-hosted Apache Superset deployment on license, published prices, Enterprise-only features, hosting and the components you run. Read the Preset rows for what you pay as a subscription and the self-hosted rows for what you must staff and provision yourself. The main takeaway is that self-hosting removes the per-user subscription but replaces it with infrastructure and labor you have to estimate.
| Factor | Preset Cloud | Self-hosted Apache Superset |
|---|---|---|
| License and cost structure | Subscription from Preset, with Starter free for up to 5 users in one workspace | Apache License 2.0 with no paid edition, so there is no license fee to pay |
| Published price for a small team | Professional at $20 per user per month billed annually or $25 per user per month billed monthly (Preset pricing page) | No license line item; cost is infrastructure, metadata database and staff time, which you must estimate |
| Embedded dashboards | Add-on on Professional and Enterprise, with viewer licenses at $500 per month for 50 viewers (Preset pricing page) | No viewer license; embedding and its access model must be built and secured by your team |
| Enterprise-only features | SSO with SCIM, audit logs, Managed Private Cloud, SSH tunnel database connections and an enterprise SLA on the custom-priced Enterprise plan | SSO, audit logging and tunneling are configured and maintained by you using the platform's own options |
| Where data and the app are hosted | Preset runs the managed service in its cloud, or in your private cloud on the Enterprise plan | Your cloud account, data center or air-gapped network, under your control |
| Components you operate | Preset operates the application, metadata store, caching and workers as part of the service | Web application, metadata database (PostgreSQL or MySQL), optional caching layer and Celery worker and beat processes |
| Upgrades and breaking changes | Handled by Preset as part of the subscription | You back up the metadata database, run superset db upgrade and superset init, test in staging and review UPDATING.md |
| Cost drivers to ask about | User count, workspace count, viewer count for embedding and whether you need Enterprise features | Hosting size, database and cache operations, on-call coverage and DeployOpen-style implementation scope if you buy help; confirm each in your own environment |
How data location and access change under each model
Buying Preset or running Superset yourself moves five decisions: where the metadata database and query traffic run, who patches it, how people sign in and receive roles, and what evidence you can hand an assessor. The cards below cover each one, with the checks to make before you choose.
Where metadata and query traffic run
Self-hosted Superset keeps the metadata database, cache and Celery workers in your own cloud account or data center, alongside the warehouses it queries. With Preset Cloud, Superset's application and metadata live in Preset's hosting, and your database connections must reach it. Map every data path, including which database connections Preset must open and whether SSH tunnels are needed, and ask Preset which regions host your workspaces.
Who patches and upgrades
On self-hosted Superset your team runs the upgrade path: back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md for breaking changes. On Preset, the vendor operates the platform, but you still need to confirm release timing, maintenance windows and how urgent security fixes reach your workspaces. Write down who approves each upgrade in either model.
SSO and group-to-role mapping
Self-hosted Superset supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP, and it maps groups to roles with AUTH_ROLES_MAPPING. Preset lists single sign-on with SCIM only on its custom-priced Enterprise plan. Confirm which identity provider you use, how deprovisioning works in each model, and who owns the mapping file or SCIM configuration.
Secrets and configuration ownership
Self-hosted Superset requires a user-specified SECRET_KEY to start, and it supports rotation through PREVIOUS_SECRET_KEY. Your team stores, rotates and restricts access to that key and to database credentials. On Preset, confirm how workspace secrets are stored, who can view connection details and how rotation is handled, since you will not hold the underlying configuration.
Compliance evidence you hold
DeployOpen prepares controls, configuration records and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors do. Self-hosting gives you direct logs, config files and backup records to show an assessor. Preset's audit logs and certifications sit with the vendor and are gated by plan, so ask Preset for its current certification reports and hosting region commitments in writing.
What the metadata database, cache and Celery workers add to your workload
Self-hosting Superset means running four kinds of component: the Flask and React application, a metadata database that stores Superset's own configuration, dashboards and users, an optional caching layer, and optional Celery worker and beat processes. Preset Cloud operates all of these for you, so this is the workload line item that the subscription replaces. The application is the only piece every installation needs, but the architecture documentation makes clear that the rest is not decoration: alerts and reports, async queries and dashboard thumbnails all depend on the caching layer and the workers, and most installations run Redis and Celery to supply them.
For the metadata database, the supported choices are PostgreSQL 10 to 17 or MySQL 5.7 and 8.x, according to the configuration documentation. Superset is tested against PostgreSQL and MySQL, and the architecture documentation says the SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container in Docker Compose, are not recommended for production. Confirm which of these your DBA team will back up, patch and restore, since upgrades start with a metadata database backup followed by superset db upgrade and superset init. Also confirm where Redis and the Celery workers run, who monitors them, and how a queue backlog would be detected before a scheduled report is missed.
Two settings need decisions before the first production deploy. Superset will not start without a user-specified SECRET_KEY, a requirement added in version 2.1.0, so store it in your secrets manager rather than in a file checked into source control. When you rotate it, set PREVIOUS_SECRET_KEY to the old value so existing sessions and encrypted data remain readable during the change, as the configuration documentation describes. Ask your team to write the rotation into its runbook and to test it in staging first, because a botched rotation affects every component that shares the key.
What your team runs in each hosting model
This table lists the recurring tasks each hosting model leaves with your team, row by row, so you can compare the operating load directly. Read the Preset column for what the vendor operates and the self-hosted column for what your staff must run, patch and test themselves. The main takeaway is that self-hosting moves the platform, data services and upgrade risk onto your team, while Preset keeps dashboards, users and database connections in your hands.
| Recurring task | Preset Cloud | Self-hosted Apache Superset |
|---|---|---|
| Infrastructure sizing | Preset operates the hosting; confirm workspace and user limits against your plan | Your team sizes web, metadata database, cache and Celery worker and beat hosts for query and report load |
| Metadata database backups | Confirm backup and restore terms with Preset in writing | Your team backs up the metadata database before every upgrade and on a schedule you set |
| Redis and Celery monitoring | Preset operates these components; ask how incidents are reported | Your team monitors Redis and Celery workers, since alerts, reports, async queries and thumbnails depend on them |
| Version upgrades | Preset applies platform upgrades; test your dashboards against changes you are told about | Back up, run superset db upgrade and superset init, test in staging and check UPDATING.md for breaking changes |
| Kubernetes deployment | Not applicable to the customer | Deploy with the Apache Superset Kubernetes Operator, since the Helm chart is marked deprecated for new deployments |
| Security patching | Preset patches the managed service; confirm patch timing in your agreement | Your team patches the OS, Python dependencies, Superset images and supporting services |
| User management and access | Your team manages users, roles and permissions in the workspace | Your team manages users, roles and permissions, plus sign-in configuration such as OAuth2 or LDAP |
| Dashboards and database connections | Your team builds dashboards and manages database connections | Your team builds dashboards and manages database connections and their credentials |
How to move between self-hosted Superset and Preset
This sequence gives you a tested path in either direction, from inventory through cutover, so that dashboards, data connections, access rules and scheduled delivery all work on the target before users switch. It also shows where Preset-only features will need a replacement or will not carry over.
Inventory dashboards, datasets and semantic definitions
Before any export, list every dashboard, chart, dataset, saved query, virtual dataset and metric or calculated column, along with the owner of each. Note which ones depend on the SQL Lab, Jinja templating or row level security rules. Confirm with Preset which export formats and asset types its current export tooling supports, since you should not assume that everything can be exported as files. The step is done when you have a spreadsheet or document that maps each asset to an owner, a source database and a target method (export, import or rebuild).
Export or recreate assets on the target
Move assets with the export and import options that both sides support. Where a file export is not available or does not carry semantic definitions, recreate datasets and metrics by hand from your inventory. Your team performs this work, or your implementation partner does under a written scope. Check the Superset version on the self-hosted side against the version your Preset workspace runs, and use the upgrade guidance to confirm compatibility before importing. The step is done when every inventoried dashboard renders on the target with the same row counts on a sample query.
Reconnect databases and configure SSH tunnels
Recreate each database connection on the target using the same driver, host and credentials scheme, and store secrets in your own secret store rather than in exported files. If Preset connects through an SSH tunnel, that feature is listed on Preset's Enterprise plan, so confirm how you will provide the equivalent network path from your own infrastructure before you cut over. The step is done when each connection passes a test query from the Superset instance and the network path is documented.
Remap roles, groups and row level rules
Map identity provider groups to Superset roles on the target. On self-hosted Superset, this is configured through the authentication settings, including group-to-role mapping with AUTH_ROLES_MAPPING for OAuth or LDAP groups. On Preset, SCIM provisioning and audit logs are listed only on the custom-priced Enterprise plan, so if you rely on them, document what replaces them in your environment. Test each role with a sample user and confirm that row level rules return the same subset of data. The step is done when a test account from each role sees exactly the expected dashboards and rows.
Validate scheduled reports and alerts
On self-hosted Superset, alerts, reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, so confirm those services are running and monitored before you test. Recreate each schedule on the target, send a test delivery to each recipient list, and compare the output with the source. Also confirm recipient delivery paths, since your SMTP or messaging settings will differ from Preset's. The step is done when every schedule has produced at least one verified delivery and its owner has signed off on the output.
Test embedded dashboards and secrets
If you embed dashboards, check where the embedding lives on each side. Preset sells embedded dashboards as an add-on on Professional and Enterprise, with viewer licenses priced per 50 viewers, so compare that cost against the self-hosted effort to run the embedding service yourself. Rotate any secret that was shared between environments, including the SECRET_KEY on the self-hosted side, which must be set explicitly. The step is done when embedded views load for test tenants and no secret from the source environment remains in use.
Cut over users and retire the source
Announce a cutover window, freeze changes on the source, run a final incremental copy of assets that changed after the first pass, and point user bookmarks and links to the target. Keep the source read-only until the owners confirm their dashboards on the target. Note the lock-in points you have not replaced, such as any Preset-only feature you used, so the decision record shows what was left behind. The step is done when every owner signs off, the source is archived with a backup, and the link list is updated.
Confirm export options and version compatibility
Before you start any of the steps above, ask Preset in writing which export options apply to your plan and which version of Superset your workspace runs. For the self-hosted target, check the release notes and UPDATING.md for the version you plan to deploy, and test the import in staging first. Because Superset releases change between versions, do not assume a file from one version imports cleanly into another without a test. The step is done when you have written answers from Preset and a staging import has passed the same checks used for production.
Questions buyers ask before choosing Preset or self-hosting
What drives the cost of self-hosting Apache Superset compared with Preset?
Self-hosting cost is mostly staff time and infrastructure, while Preset's published prices cover the managed service itself. Preset's pricing page lists Professional at $20 per user per month billed annually or $25 per user per month billed monthly, with unlimited users and 3 workspaces. Self-hosting has no license fee, but you pay for the hosting, the metadata database (PostgreSQL 10 to 17 or MySQL 5.7 and 8.x are the supported versions), Redis and Celery workers if you use alerts, reports or async queries, backups, and the people who upgrade and monitor it. Ask any quote to separate one-time setup from recurring hosting, staff and upgrade work.
Can a small team run self-hosted Superset without outside help?
A small team with Python, Linux and database administration skills can run a single-host Superset, but production use needs more than the default install. The Superset architecture documentation says the SQLite default of Quickstart and PyPI installs and the Docker Compose PostgreSQL container are not recommended for production. A production setup needs a supported metadata database, a user-specified SECRET_KEY, backups, and caching and workers if you rely on alerts or reports. Confirm internally whether one or two people can own upgrades, which the upgrade documentation says require a metadata database backup, superset db upgrade, superset init, a staging test and a review of UPDATING.md.
How long does a migration from Preset to self-hosted Superset take?
No supplied fact gives a migration duration, so treat any figure you hear as unverified until a scoped plan confirms it. The time depends on the number of dashboards, datasets, database connections, roles and row level security rules to recreate, the identity integration you need, and how many users must be retained through cutover. Ask for a written scope that lists each of these items, the environments to be built, the test and rollback steps, and who signs off. Most engagements of this kind are fixed-scope, so the scope and timeline are agreed in writing before work starts.
What skills does a self-hosted Superset deployment require from the team?
Plan for Python for configuration and custom code, Docker or Kubernetes for deployment, database administration for the metadata store, and identity configuration for sign-in. The configuration documentation covers Flask-AppBuilder, OAuth2 providers such as Google and Azure, LDAP, and mapping groups to roles with AUTH_ROLES_MAPPING. For Kubernetes, the Superset 6.1.0 documentation describes the official Helm chart, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator, so confirm which path your team will standardize on. Check these skills against your own staff before comparing costs.
When do Preset's Enterprise features justify the higher plan?
Enterprise is worth evaluating when you need SSO with SCIM, audit logs, Managed Private Cloud deployment, or an enterprise SLA, because Preset lists these only on its custom-priced Enterprise plan. If your identity provider already handles group sync through OAuth or LDAP and you can keep audit evidence in your own logging stack, self-hosting may cover those needs without the plan. Ask Preset for a written quote and confirm which controls it provides, including how SCIM provisioning and audit log retention work, before deciding. Compliance readiness work can prepare evidence, but independent auditors issue any attestation.
Does an embedded product need Preset viewer licenses?
Preset's pricing page lists embedded dashboards as an add-on on Professional and Enterprise, with viewer licenses at $500 per month for 50 viewers. If you embed dashboards in a customer-facing product, price the viewer count you expect at your peak, not only your internal user count. Self-hosted Superset has no viewer license fee, but you must design tenant isolation, guest tokens and row level security yourself and budget for the engineering and testing that requires. Confirm the viewer tier against Preset's current page before you commit.
What does Preset's managed service remove from the team's workload?
Preset Cloud is a fully managed, cloud-hosted service for Apache Superset, so the provider runs the hosted application. You still own the data sources you connect, the users and roles you define, and the dashboards your analysts build. Self-hosting moves the hosting, patching, backups, scaling, and the Celery and caching layers onto your team or an implementation partner. Ask Preset which operational tasks its plan covers and which remain your responsibility under your data residency and network rules.
Choosing by scenario: regulated data, embedded analytics and small teams
For a regulated team that must keep query data in its own accounts, self-hosted Apache Superset leans ahead. Illustrative example: a bank's analytics group that must keep query results, cached data and metadata inside its own cloud accounts. Preset Cloud is a fully managed, cloud-hosted service, so the first check is where Preset stores query results and metadata, and whether that meets your residency rules. The closest Preset option to private hosting, Managed Private Cloud, appears only on the custom-priced Enterprise plan, so it needs a written quote and a review by your compliance lead. Self-hosting keeps those stores in your accounts, but you then own the metadata database (PostgreSQL 10 to 17 or MySQL 5.7 and 8.x, since the SQLite default is not suitable for production), the SECRET_KEY, backups and upgrades. The answer changes if Preset confirms in writing that Managed Private Cloud meets your residency and access requirements.
For a SaaS company embedding dashboards for its customers, Preset leans ahead only while viewer volumes stay modest. Illustrative example: a product team adding customer-facing dashboards to a multi-tenant application. Preset sells embedded dashboards as an add-on on Professional and Enterprise, with viewer licenses at $500 per month for 50 viewers, so cost rises in blocks as viewers grow. Self-hosting removes that license line but moves the work to your team: a metadata database, Redis and Celery workers for async queries and dashboard thumbnails, and upgrades that follow the documented sequence of backing up the metadata database, running superset db upgrade and superset init, testing in staging and checking UPDATING.md. Model your expected viewer count against the block price, and ask Preset how its SSO and SCIM terms apply to your customers' identities.
For a small analytics team with no platform engineers, Preset leans ahead, provided the team stays inside its plan limits. Illustrative example: five analysts who need dashboards and scheduled reports, with nobody responsible for infrastructure. Preset's Starter plan is free for up to 5 users with one workspace, and Professional, at $20 per user per month billed annually or $25 billed monthly, adds unlimited users, three workspaces, role-based access control and scheduled reports. Self-hosting means someone owns the web application, the metadata database and the caching and Celery worker and beat processes that alerts, reports and async queries depend on. The answer flips if the team needs SSO with SCIM, audit logs or Managed Private Cloud, which sit only on the custom-priced Enterprise plan. Confirm those requirements before comparing totals.
How DeployOpen scopes, delivers and supports self-hosted Superset
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Preset vs self-hosted Apache Superset decision, we start by agreeing in writing what you actually need from a BI platform before anyone touches a server.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which users, data sources and embedded dashboards you need, and which of them Preset's plans would cover.
- The written scope names the metadata database, cache and Celery worker components you would operate if you self-host.
How we build
- We deploy Superset into your cloud account, data center or air-gapped network, with the metadata database and caching layer you specify.
- We configure identity integration, such as OAuth2 or LDAP group mapping to roles, against your own directory.
- We test upgrades in staging first, following the Superset upgrade documentation, before anything reaches production.
How we hand over
- Handover includes documentation of the deployment, configuration keys, secret rotation steps and backup procedures.
- We document the upgrade runbook, including metadata database backups and the checks to run against UPDATING.md.
- You receive a written record of what runs where, so your team can operate the platform or compare it against Preset later.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- We can monitor the worker and beat processes that alerts, reports and async queries depend on, if included in scope.
- Ask any provider to confirm response expectations and upgrade cadence in the quote, since these vary by scope.
