Superset Connectors
You set up superset connectors by adding a Python driver and a database string. These settings let your reporting app talk to your SQL data stores. Most teams use one shared service account for all dashboard users. That broad role lets anyone query private tables if they have SQL Lab permissions. How superset connectors work under the hood Apache Superset relies on SQLAlchemy to talk to your data stores. When you add a new database, you must install the right Python driver first. Each databas
Connectors: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up superset connectors by adding a Python driver and a database string. These settings let your reporting app talk to your SQL data stores. Most teams use one shared service account for all dashboard users. That broad role lets anyone query private tables if they have SQL Lab permissions.
How superset connectors work under the hood
Apache Superset relies on SQLAlchemy to talk to your data stores. When you add a new database, you must install the right Python driver first. Each database type needs its own driver package inside the host container.
Once the driver is in place, an admin enters the database string. This string holds the host address, port number, database name, and login key. The reporting app tests this link and saves the secret in its metadata store.
When a user opens a dashboard, the app builds a SQL query. It sends that query through the saved link using the shared service role. The database runs the statement and sends the rows back for the chart.
Teams also use this same link for the built-in SQL editor. Analysts write custom queries to explore tables before they build new charts. Every query from every analyst runs under that single database role.
What native database links solve and what they miss
Native database links make it fast to hook up many SQL engines. You can pull charts from Postgres, MySQL, and cloud warehouses in one place. Built-in role rules also let you pick which dashboards a team can view.
Still, the native setup only checks who logs into the reporting tool. It does not check what individual SQL statements do while in flight. Once a query leaves the app, the database only sees the shared role.
Connectors: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This gap creates big risks when analysts use the ad-hoc SQL editor. An analyst can query raw tables that hold emails, phone numbers, or card numbers. The database cannot tell which human user actually ran that wide query.
Audit logs inside the database only show the shared app account name. Security teams have to match timestamps across two systems to find the real user. Also, native links do not rewrite sensitive fields in query results on the fly.
Managing permissions across multiple data sources
To reduce risk, teams often create separate database roles for each group. You might make one link for finance and another link for support. Each link uses a database role with limited table read rules.
This approach works at first, but it grows hard to manage over time. Every new team needs a new database user, password, and saved link. Admins must update roles in two places whenever a table changes.
Password rotation also becomes a slow manual chore across dozens of saved links. If you update a key in the database, dashboards break until you update the app. Teams need a simpler way to inspect queries and mask fields like national IDs.
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 do I need to add a new database to Apache Superset?
You need a compatible SQLAlchemy driver installed in the app host. You also need the database host address, port, and a valid login key.
Why do database logs show one user for all dashboard queries?
Most teams set up each data source with one shared service account. The database only sees that shared role instead of the logged-in human user.
How can I protect sensitive columns when analysts run ad-hoc SQL queries?
You can restrict table read roles in the database or use data masking. Masking rewrites matched fields like emails and card numbers in query results.