Super Set Data
You manage super set data by setting up database sources, user roles, and row rules. This setup lets your team build charts and run queries from a browser. Most teams start by linking their main SQL store to the business app. They often share a single database account across many builders and analysts. When those permissions are too broad, users can read raw tables they do not need. A small mistake in a role rule can expose private customer fields to every chart builder. How super set data rol
Set Data: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage super set data by setting up database sources, user roles, and row rules. This setup lets your team build charts and run queries from a browser. Most teams start by linking their main SQL store to the business app. They often share a single database account across many builders and analysts. When those permissions are too broad, users can read raw tables they do not need. A small mistake in a role rule can expose private customer fields to every chart builder.
How super set data roles and permissions work
The platform groups permissions into roles that control what users see in the app. Admins map these roles to views, menus, and specific data sources. A user with a chart role can pick a dataset and build a visual dashboard. That user cannot query other sources unless an admin grants that specific permission. You can also set row level rules to filter records for different teams. When a user loads a chart, the app adds a filter to the SQL query. This flow keeps regional teams focused on their own sales or support metrics.
For analysts who need deeper exploration, the platform includes an interactive SQL editor. Admins enable this editor per database source and assign it to trusted roles. When an analyst runs a statement, the app sends it to the database engine. The database runs the query using the credentials stored in the source setup. If you turn on user impersonation, the database checks the individual analyst identity instead. Either way, the database returns the result rows back to the browser screen.
What native roles solve and what they leave open
Native roles do a good job of sorting who can view specific dashboards. They stop casual viewers from opening the SQL editor or changing chart definitions. Row filters also help divide shared tables among different business units. Still, these app rules mostly decide who can log in and open a dataset. They do not inspect what individual SQL statements do in flight.
Once an analyst has SQL editor rights, they can query any table the database account allows. If that shared database role has broad read rights, the analyst can pull sensitive columns. Native app permissions do not rewrite results to hide emails, phone numbers, or card numbers. A valid query will return raw personal details straight to the user browser. Also, shared service accounts make database audit logs hard to trace back to one person. The database log shows the app account name rather than the individual user.
Set Data: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Best practices for safer analytics queries
Start by creating a read-only database role with strict table limits for your chart tool. Grant select permissions only on the specific views or schemas needed for reporting. Keep raw user tables with national IDs or card numbers out of that reporting schema. Separate the database account used for dashboards from the account used for ad-hoc SQL queries.
Review your role assignments each month to remove unused SQL editor permissions. Ask data owners to approve access before adding a user to an analyst group. Finally, inspect queries and mask sensitive fields in results before they reach the browser.
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
How do I limit which tables a user can query?
Assign dataset permissions to a custom role instead of giving full database source access. You should also restrict the underlying database user to read only specific reporting schemas.
Why do database logs show one user for all chart queries?
By default, the analytics app sends all queries using one stored service account credential. To see individual names in logs, you must set up user identity forwarding or per-user sessions.
Can row filters hide sensitive columns like emails or phone numbers?
No, row filters only remove whole rows based on a condition in the query. To protect specific fields like emails or card numbers, you need column limits or data masking.