Superset Metrics
You set up superset metrics by defining saved SQL expressions on a shared dataset. These saved expressions calculate totals, averages, or counts across your database tables. Analytics teams build these definitions once so everyone uses the same math. Still, teams often attach datasets to shared database accounts with broad read rights. That wide access lets users query raw rows outside the saved metric definitions. How superset metrics work in the data layer Apache Superset stores metric defi
Security Metrics & KPIs: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up superset metrics by defining saved SQL expressions on a shared dataset. These saved expressions calculate totals, averages, or counts across your database tables. Analytics teams build these definitions once so everyone uses the same math. Still, teams often attach datasets to shared database accounts with broad read rights. That wide access lets users query raw rows outside the saved metric definitions.
How superset metrics work in the data layer
Apache Superset stores metric definitions inside its own internal metadata database. Each metric pairs a friendly label with a SQL aggregation formula. When a user builds a chart, the app reads that saved formula. It blends the metric expression into a larger SQL select statement. Then the app sends that query to your underlying data warehouse.
You can build two main types of metrics in the semantic layer. Simple aggregations apply standard functions like sum or count to one column. Custom SQL metrics combine multiple columns, filters, or case statements in one expression. Both types help teams keep business numbers consistent across many dashboards.
Admins can also mark key definitions as certified for the whole team. A certified badge tells chart builders to trust that specific formula. Without shared metrics, two analysts might calculate revenue in two different ways. Central metric management stops that drift inside your reporting workspace.
What native dataset permissions cover and miss
Superset uses role-based rules to control who views dashboards and datasets. You can restrict a user role to specific data sources or charts. This native setup works well for organizing workspace menus and chart folders. It stops casual business users from opening dashboards they do not need.
Still, the app usually talks to your database using one shared service account. Every chart query runs under that single database user role. The database cannot tell which human clicked the chart inside the reporting app. Audit logs in the database only show the shared service account name.
Security Metrics & KPIs: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This setup creates a big gap when analysts use the SQL editor. Anyone with SQL lab rights can bypass saved metric definitions right away. They can run raw select queries against full tables using the shared account. If those tables hold emails, phone numbers, or card numbers, raw values return.
Why shared database roles expose sensitive columns
A metric only outputs a summary number like a count or sum. Yet the underlying database role must read the raw columns to calculate it. Because the service account has broad table rights, it reads everything. Native chart roles decide who logs in, not what queries return in flight.
Teams often try to fix this by building dozens of custom database views. Maintaining separate views for every team and dashboard takes too much engineering time. When schema changes happen, broken views block analysts from reading their daily reports. Teams need a simpler way to inspect queries and mask fields in results.
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
Where do superset metrics live in the setup?
They live inside the semantic layer of each registered dataset. The reporting tool saves the SQL formula in its own metadata store. It runs that formula against your database when a chart loads.
Can users bypass saved metrics in SQL lab?
Yes, users with SQL editor access can write direct queries against raw tables. Those queries run with the permissions of the underlying database service account. Dataset metrics do not block direct table reads in the editor.
How do you protect sensitive fields during metric queries?
You should enforce column rules at the database access layer in flight. Data masking rewrites matched fields like emails or card numbers in results. This protects raw columns while summary metrics still run normal math.