Superset License
Apache Superset uses the Apache 2.0 open-source license, so any team can run it free. The superset license lets you modify the app, host it yourself, or sell it commercially. Teams often deploy the platform fast and share one broad database account across all dashboards. When roles are too broad, any dashboard creator can query raw tables with sensitive data. How the superset license and native role model work Because the Apache 2.0 terms are permissive, you do not buy per-seat software keys.
License: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Apache Superset uses the Apache 2.0 open-source license, so any team can run it free. The superset license lets you modify the app, host it yourself, or sell it commercially. Teams often deploy the platform fast and share one broad database account across all dashboards. When roles are too broad, any dashboard creator can query raw tables with sensitive data.
How the superset license and native role model work
Because the Apache 2.0 terms are permissive, you do not buy per-seat software keys. You can download the source code and run it on your own servers right away. The license gives you full control over how you set up users and roles inside. You must build your own security rules using the native role system in the app.
Superset checks permissions through built-in roles like Admin, Alpha, and Gamma for each user. Admin users can change system settings and manage all database credentials in the app. Alpha users can read all data sources they hold permissions for and build new charts. Gamma users can only view specific dashboards that an admin assigns to their group.
To read data, an admin enters a database account credential into the analytics app. Every chart and query in that workspace then runs through that single shared database account. If a user has permission to run SQL queries, they use that same shared login. The database sees only the app account, not the specific person running the report.
What native roles solve and where gaps remain
Native roles do a good job of sorting dashboard viewers from chart builders. You can hide whole dashboards from certain teams with basic role rules in the app. You can also turn off the SQL editor for basic viewers so they only click charts. For simple internal metrics, these built-in boundaries help keep workspace folders neat and tidy.
The main gap appears when analysts need the SQL editor to explore raw data tables. Once a user has permission to query a data source, they can read every column by default. Native roles check who logs into the app, not what each query pulls in flight. If a table holds emails, phone numbers, or card numbers, the query returns them all.
License: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Sharing one database login across the whole app also breaks user-level audit logs. Your database logs show thousands of queries coming from one service user every single day. When a bad query slows down the database, you must match timestamps across two systems. You also have no built-in way to mask national IDs in results before they render.
Why database permissions need query-level controls
Relying only on app roles forces teams to maintain many duplicate views inside the database. Data engineers end up building custom views just to strip out emails and card numbers. Each time a new team joins, engineers must write more database rules and grant roles. This manual work grows fast as you add more databases and more analytics users.
A safer approach applies rules directly to the database traffic as queries run in flight. Instead of trusting the shared app login, you check the identity of the real user. You can then rewrite matched fields like phone numbers or card numbers in the results. This keeps raw data safe while letting analysts build the charts they need for work.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Is the Apache Superset license free for commercial use?
Yes, the Apache 2.0 license lets companies use the software for free in commercial products. You can host it internally or offer it to clients as long as you keep notices.
Do I need to open-source my own code under the superset license?
No, the Apache 2.0 terms do not force you to share your custom code changes. You can add private features or custom plugins without releasing your private source code.
Does the open-source license include row-level security and data masking?
The free software includes basic row filters that admins can set up on specific datasets. Still, it does not mask sensitive columns like emails or card numbers inside raw SQL queries.