Superset was built for internal analytics teams.
ISV embedding is a fundamentally different problem.
Apache Superset is an excellent open-source BI tool — active community, strong visualization library, improving embedded SDK. It's designed for internal analytics: your data team exploring your data. For ISVs embedding analytics in a customer-facing product, the requirements are different: per-tenant data isolation, white-label branding per customer, an OEM license. Superset doesn't provide any of these at the platform layer. Getting them requires custom engineering — and that engineering becomes your ongoing responsibility.
Why Superset isn't designed for ISV embedding
These aren't shortcomings — Superset is excellent at what it was built for. These are the gaps that appear specifically when you try to use an internal BI tool as a customer-facing ISV embedding layer.
No platform-level multi-tenant isolation
Superset's security model is built for a single organization with role-based access control. Per-tenant data isolation — where your Customer A absolutely cannot reach Customer B's data — requires building a custom security manager, configuring row-level security rules per tenant, and writing the query-time filtering logic in your application. This is an engineering project, not a configuration task, and it becomes yours to maintain permanently. Yurbi enforces isolation architecturally: each tenant routes to their own database at the platform layer.
No OEM license — and per-tenant branding is still custom
Apache License 2.0 allows commercial use, but there is no OEM license, no vendor-supported white-label arrangement, and no official model for embedding Superset in a commercial product as an analytics layer for your customers. Superset 6.0 introduced improved system-wide theming — but per-tenant branding, where each of your customers sees their own logo and colors, still requires custom implementation and fork maintenance. Yurbi's OEM license and unlimited per-tenant branding policies are included in every plan.
Zero license cost is not zero cost
Superset's software is free. The cost of using it for ISV embedding is your engineering team's time: implementing multi-tenant isolation, maintaining the fork as upstream changes, syncing security patches, building per-tenant branding, and operating the Python/Celery/Redis production stack. A mid-level engineer runs $120,000–$180,000/year. If ISV embedding adaptation takes 3–6 months of focused engineering — and it typically does — that's $30,000–$90,000 before your first customer dashboard ships. Yurbi starts at $10,000/year with all of this included.
Python / Flask / Celery / Redis in production
Superset's production stack requires Python, Flask, Celery for async workers, Redis for caching, and a metadata database. If your team already runs this stack, that's manageable. If you don't — and most ISVs don't — you're adding a significant operational surface area specifically to host your analytics layer. Security vulnerability response is also slower: Apache's disclosure process means you may not learn of CVEs until the next official release. Yurbi deploys like a web application with no async worker queue or Python runtime dependency.
Apache Superset vs Yurbi — for ISVs
Apache Superset is an open-source project maintained by the Apache Software Foundation. Feature details based on publicly available documentation and Superset 6.0 release notes as of Q1 2026. superset.apache.org.
Superset vs Yurbi — questions answered directly
Technically yes — Apache License 2.0 allows commercial use. Superset also now has an embedded SDK with guest token authentication, row-level security hooks, and improved theming. So the plumbing for embedding exists and has improved significantly through 2025.
The gap for ISVs is what the plumbing requires you to build: a custom security manager to enforce tenant isolation, per-tenant RLS configurations, per-tenant branding implementation, and ongoing fork maintenance as upstream changes. These aren't configuration tasks — they're engineering projects. For an ISV whose analytics layer shouldn't be a core engineering focus, this recreates the problem you were trying to solve by buying instead of building.
Superset's software license is zero. The cost of using it for ISV embedding is your engineering team's time: building and testing multi-tenant isolation, implementing per-tenant branding, maintaining the fork as upstream changes, and operating the Python/Celery/Redis stack in production. A mid-level engineer runs $120,000–$180,000/year in fully-loaded compensation. If ISV embedding adaptation takes 3–6 months of dedicated engineering work — and it typically does — that's $30,000–$90,000 before you've shipped a single customer dashboard.
Yurbi's license starts at $10,000/year with multi-tenant isolation, per-tenant branding, OEM licensing, and vendor support included. The build-vs-buy math usually isn't close — and Superset for ISV embedding is a variation of the build-it-yourself problem. We have a full analysis of that on our build vs buy page.
Superset has row-level security (RLS) and a pluggable security manager that can be extended. Enforcing strict tenant isolation — where your customers absolutely cannot see each other's data — requires building a custom security manager implementation, defining RLS rules per tenant, and testing that implementation rigorously. It's documented in Superset's community forums as a multi-week engineering project, and the GitHub issue tracker has numerous threads on how to approach it.
Yurbi enforces tenant isolation at the platform layer. Each tenant routes to their own database instance at query time via dynamic data source routing. The isolation is architectural — Customer A literally cannot reach Customer B's database because they're on separate connections. For a commercial product, this is the security model you want: one you didn't have to implement and don't have to maintain.
Superset 6.0 (released early 2026) brought meaningful improvements: a complete design system overhaul with Ant Design v5, a new theme management UI for system-wide appearance, comprehensive dark mode, and embedded SDK enhancements including dynamic theme switching via the setThemeMode() API. The embedded SDK has also been getting consistent attention — better guest token support, drill features in embedded mode, and improved chart data APIs throughout 2025.
The category gap for ISVs remains unchanged by 6.0: the new theming system applies system-wide, not per-tenant. If your product serves 200 customers each expecting their own logo and brand colors, that's still a custom implementation problem. Multi-tenant data isolation is still a custom engineering project. Superset is getting better at what it's designed for — and it's still not designed for ISV embedding.
Preset.io has matured significantly — they offer managed Superset with workspaces for team isolation, an embedded SDK, SOC 2 and HIPAA certifications, dedicated support, and paid tiers for teams that need enterprise features. A free Starter tier gives 5 users access. For managing Superset without the operational burden of Python stack management, Preset is a legitimate option.
The core ISV category issue is the same: Preset's workspaces are designed for team-level isolation within an organization, not for per-customer tenant isolation in a commercial SaaS product. Multi-tenant data isolation where Customer A cannot see Customer B's data still requires the same custom security implementation as self-hosted Superset. The managed hosting reduces your operational burden — it doesn't change the product architecture question.
Superset is genuinely excellent for internal analytics — data teams and business analysts exploring your company's own data. SQL Lab is a powerful ad-hoc query tool. The chart library is broad. The connector ecosystem covers 60+ databases via SQLAlchemy. If you're building internal BI for your organization with a Python-fluent team, Superset is a strong open-source choice.
It also makes sense if zero software cost is a hard constraint and you have the engineering capacity to build what's missing for ISV embedding — and you've made an honest accounting of that engineering cost. Some ISVs do choose this path successfully. They're usually ones with large engineering teams where analytics is a primary product focus, not a feature embedded in something else. If your dev team should be focused on your core product and analytics is a capability you want to add, purpose-built ISV embedding tools cost less in total than the free option.