Apache Super Set
You set up apache super set by linking a web server to your data stores. This open source tool lets your team build charts and run SQL queries in a browser. Most teams start by adding one shared database role for the whole app. That broad role makes setup fast for the first few users. Yet a shared role soon gives every chart builder read rights to every table. How apache super set permissions and roles work The app manages user rights through built-in roles and permission sets. Admins assign
Super Set: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up apache super set by linking a web server to your data stores. This open source tool lets your team build charts and run SQL queries in a browser. Most teams start by adding one shared database role for the whole app. That broad role makes setup fast for the first few users. Yet a shared role soon gives every chart builder read rights to every table.
How apache super set permissions and roles work
The app manages user rights through built-in roles and permission sets. Admins assign users to standard roles like admin, alpha, or gamma. Admin users can change app settings and manage all database links. Alpha users can read all added data sources and build new dashboards. Gamma users can only view the specific charts and tables tied to their custom roles.
Each role holds small permission tags for views, menus, and data sources. When a user opens a dashboard, the app checks these tags first. If the user has the right tag, the app sends a query to the database. The app uses the saved database key from the data source setup. You can also add row-level filters to limit what specific roles see in charts.
Row-level filters add a condition to the query before it runs. For example, a sales team role might only see rows for one region. This filter works well for standard charts built in the visual editor. Still, things change when users get rights to the built-in SQL editor.
Where native database roles leave gaps in flight
Native roles in apache super set decide which screens and datasets a user can open. They solve basic dashboard sharing for business teams very well. Yet the app still talks to the database through one shared service account. From the database view, every query comes from that single app user.
When analysts use the SQL editor, row-level chart filters do not always apply. A user with SQL rights can write direct queries against any table in that schema. If those tables hold emails, phone numbers, or card numbers, the query returns them raw. Native app roles decide who logs in, not what each statement returns in flight.
Super Set: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This setup also makes database audit logs hard to read during a review. Your database log shows thousands of queries from one shared app account. You must dig through separate app logs to match a query to a real person. Plus, you cannot pause a risky query for peer review before it runs. And you cannot rewrite sensitive fields like national IDs in query results on the fly.
Managing SQL editor risks for analytics teams
Teams often try to fix this gap by creating many database links. They make one database link per team and assign separate roles to each link. This approach cuts down broad table rights at the start. Still, role sprawl grows fast as more teams join the platform.
Soon admins must maintain dozens of roles, database accounts, and chart rules. When a schema changes, admins must update rules across many places by hand. Even with split accounts, a valid user can still pull full tables of customer data. If a table mixes metrics with emails or card numbers, the user gets both. Keeping raw keys inside the app also creates a risk if an admin role leaks.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between alpha and gamma roles in apache super set?
Alpha users can view all data sources and add or edit their own charts. Gamma users can only view specific datasets and dashboards assigned to them by an admin.
Do row-level security filters stop direct queries in the SQL editor?
Row-level filters apply to visual charts and linked datasets inside the dashboard view. Users with direct SQL editor rights can often query raw tables outside those dataset filters.
Why do database logs show one user for all dashboard queries?
The app connects to your database using the single login saved in the data source setup. Unless you map user identities down to the query level, the database sees one shared account.