Superset Architecture
You build a superset architecture by pairing a web server with a metadata database. You also add background workers and a cache to run heavy analytics queries. Data teams often set up this stack using containers and shared database credentials. When database roles are too broad, any chart or user can read private tables. A single shared login also makes it hard to track who ran a query. How the core superset architecture works The app runs as a stateless Python web server that handles user r
Zero Trust Architecture: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a superset architecture by pairing a web server with a metadata database. You also add background workers and a cache to run heavy analytics queries.
Data teams often set up this stack using containers and shared database credentials. When database roles are too broad, any chart or user can read private tables. A single shared login also makes it hard to track who ran a query.
How the core superset architecture works
The app runs as a stateless Python web server that handles user requests. When a user opens a dashboard, the web server reads the chart setup. It stores all dashboards, slices, and user roles inside its own metadata database. Teams usually pick PostgreSQL or MySQL to hold this internal state.
The platform does not store your business data inside its own system. Instead, it sends SQL queries straight to your external data warehouses. For quick charts, the web server runs the query and waits for results.
Long queries can block the web server and slow down other users. To fix this, teams add background workers and a message queue. The web server puts heavy SQL jobs into the queue and returns right away. Workers pick up the job, run the query, and save results to a cache. The user interface then reads the finished data from that cache layer.
How roles and database permissions work
Inside the app, admins assign users to built-in or custom security roles. A role controls which dashboards, datasets, and menus a person can see. Admins can also set row-level rules to filter data for specific groups. These filters add conditions to the SQL query before the app sends it.
To talk to a data warehouse, an admin adds a database entry. Most teams enter one service account login for each external data source. Every chart and SQL Lab query then uses that same database account. The warehouse only sees the shared service account, not the person logged in.
Zero Trust Architecture: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native controls solve and what they miss
Native roles work well when users only view fixed charts and dashboards. Admins can lock down specific datasets and keep business users out of raw tables. Row filters also help teams share one dashboard across many departments safely.
The gap appears when analysts use the built-in SQL editor for custom queries. Once a role grants access to the SQL editor, the user writes raw statements. Because the app uses a shared database login, the warehouse trusts every query. Native settings decide who logs in, not what individual statements do in flight.
If that shared database role can read sensitive tables, analysts can query them. Native chart rules cannot stop a raw query from pulling emails or phone numbers. They also cannot mask card numbers or national IDs inside query results. Masking rewrites matched fields in results before the client displays the table. Finally, database audit logs only show the shared app account, hiding user identity.
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
Does Apache Superset store my warehouse data?
No, the platform only stores dashboard layouts, user roles, and cached query results. It queries your external databases directly and renders the returned rows as charts.
Why do I need background workers in my setup?
Web requests time out when a database takes too long to answer. Background workers run heavy queries outside the web process so dashboards do not freeze.
How can we stop SQL Lab users from seeing private columns?
Database roles apply to the whole account, so raw queries bypass chart rules. You need an inline control that rewrites matched fields like emails in results.