How Apache Superset and Trino integration works for your team
Your team wants dashboards over a Trino query engine that federates several data sources, so that analysts can chart data across systems without copying it into one warehouse. In this setup Superset does not talk to those sources directly. It connects to Trino as one database connection, configured in Superset with a Trino driver and a connection string that you take from Superset's database connection documentation. Trino then decides which catalog and source each query touches, and it returns the results to Superset. Confirm the driver package name, the connection string format and the catalog and schema fields against the documentation for the Superset release you plan to run, because these details change between releases and you will need them for the image build.
Two access models sit in this path, and they must be designed together. Superset has its own roles, dataset permissions and row level security, which decide what a logged-in user can see inside Superset. Trino has its own access controls, which decide what a connected identity can read from each catalog. If Superset connects with one shared service account, Trino sees a single identity and cannot tell the analyst apart, so Trino-side controls cannot enforce per-user rules. Decide early whether Trino should see the real user through impersonation, whether a shared account with Superset-side row level security is acceptable for your data classification, and who owns each control. Your security and data governance owners should sign off on that split before build work starts.
The rest of the design follows from that choice. Connections that cross a network boundary may need SSH tunneling, and long federated queries need a plan for cancelation and timeouts, because a slow join across two sources can hold resources in both Trino and the source systems. Ask your implementation partner, in writing, to state which of these decisions they expect you to make and which they will document for you. The sections below cover each one in turn.
What you need before you connect Superset to Trino
Connecting Superset to Trino depends on five things lining up: a supported Superset release with a production metadata database, a reachable Trino coordinator, identities and certificates for both sides, a driver inside the Superset image, and a agreed list of catalogs and schemas. Confirm each one before you write the connection string, because gaps tend to surface later as login or query failures.
Supported Superset release and metadata database
Pick the Superset release you will run and confirm it against the release notes and upgrade guide for your version. The metadata database holds Superset's own users, dashboards and connection records, so it is separate from Trino. The configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported versions. The SQLite default used by quickstart and PyPI installs is not suitable for production.
Trino coordinator reachable from Superset
Superset connects to the Trino coordinator over HTTP or HTTPS, so the network path from the Superset web and worker pods or hosts to the coordinator port must be open. Check firewalls, proxies and any load balancer in front of the coordinator. Confirm the Trino version and that the coordinator accepts the authentication method you plan to use, because a reachable port alone does not prove the connection will succeed.
Service accounts and access identities
Decide whether Superset will connect with one shared service account, with per-user impersonation, or both. Impersonation requires that the service account is permitted to act for end users in Trino, so agree on that trust relationship with the Trino owners before build. Document which account owns each connection in Superset and who may rotate its credentials. This decision shapes audit logs on the Trino side.
TLS certificates and trust chain
Plan the certificates for the Trino coordinator and make sure the CA that signed them is available inside the Superset image or mounted trust store. Mismatched hostnames and missing intermediate certificates are common causes of failed connections. Record who issues and renews certificates, the expiry dates, and how a renewal reaches both Superset and Trino without an outage.
Trino driver in the Superset image
Superset does not ship every database driver by default, so the Python package for Trino must be added to the image you build or run. Confirm the driver package name and a compatible version against Superset's database connection documentation for your release, and pin it in your build. Treat a driver upgrade as a change to test in staging, since it can alter how types and errors are handled.
Catalogs and schemas to expose
Trino federates several catalogs, such as warehouse, lake and operational sources, and not every one should appear in Superset. List the catalogs and schemas that dashboards need, and the ones to keep hidden. Map each to a Trino role with read-only grants, and note which tables hold sensitive columns. This list becomes the basis for Superset role and data access rules later.
Configuration sequence for connecting Superset to Trino
This sequence takes a self-hosted Superset from a built image to a verified Trino connection, with each step closed by a check that confirms the previous work before the next begins. The order matters because impersonation and tunneling both depend on the Trino side and the Superset side agreeing on identity and network path.
Build the image with the Trino driver
The platform engineer builds a custom Superset image that includes the Python client library for Trino, because the standard image does not ship with it. Superset reaches Trino through a SQLAlchemy dialect, so the image must contain the driver package at a version compatible with your Superset release and your Trino version. Confirm the exact package name and version against the Superset database connection documentation for your release before pinning it. Done means the image starts, and a Python shell inside the running container can import the driver and list its dialect without errors. Keep the image tag in version control so every later step runs against the same build.
Set SECRET_KEY and the metadata database
The platform engineer sets a unique SECRET_KEY in the Superset configuration, since Superset will not start without a user-specified value, and points the metadata database at PostgreSQL or MySQL rather than the SQLite default. The supported metadata database versions are listed in the configuration documentation, and the SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Store the key in your secrets manager and inject it at runtime. Run the database migration and initialization commands from the upgrade documentation. Done means the web application loads the login page and the metadata database contains the Superset tables.
Create a Trino service account with least-privilege grants
The Trino administrator creates a dedicated service account for Superset and grants it read access only to the catalogs, schemas and tables that the dashboards need, using your Trino access control method. Avoid granting write or administrative privileges, and avoid reusing a personal or shared engineering account. Ask your Trino team to confirm which access control plugin or rules file governs this account, because the grant mechanism depends on how your cluster is configured. Done means the account can run a read query against one approved table and is denied a query against a table outside the approved set.
Add the database connection with catalog and schema
In Superset, an administrator adds a new database connection of the Trino type and enters the coordinator host, port, the catalog and schema the connection should default to, and the service account credentials. Store the password through Superset's secret handling rather than in plain text where your version allows it. Set the catalog explicitly so queries are not ambiguous across the federated sources Trino exposes. Done means the connection test succeeds in the Superset interface, and a test query against the approved table returns rows that match what the Trino CLI returns for the same statement.
Enable impersonation after Trino accepts it
Only after the service account connection works, the Trino team configures Trino to accept impersonation from the Superset service account for the users who should be represented, and the Superset administrator turns on user impersonation for that database connection. Enabling it first causes queries to fail or run under the wrong identity, so the Trino side must confirm acceptance before Superset changes. Confirm the exact configuration keys with the Superset and Trino documentation for your versions. Done means a test query run by a named test user appears in Trino's query history under that user's identity, not under the service account.
Configure SSH tunneling for a private coordinator
If the Trino coordinator sits on a private network that Superset cannot reach directly, the network team sets up an SSH tunnel from the Superset host through a bastion host that can reach the coordinator. In Superset, the administrator enables the SSH tunnel option on the database connection and enters the bastion details and key handling your security policy allows. Use a dedicated bastion account with access limited to the coordinator port, and rotate its key on your standard schedule. Done means the connection test passes from the Superset host through the tunnel, and the tunnel logs show only the expected coordinator port being forwarded.
Test a query and verify identity in Trino
The platform engineer opens a new chart in Superset against the Trino connection, runs a query on an approved table, and then checks Trino's query history for the same statement. Confirm that the query shows the expected user, the catalog and schema you set, and a completed state. Repeat the test with a second user whose Trino permissions differ, and confirm that the second user receives the access denial for a table the first user can read. Done means both users see the access behavior your Trino rules define, and the records match the Superset activity you ran.
How Superset roles and identities map to Trino users and catalogs
This table traces one user from the identity source in Superset through the Trino principal to the catalog grant and the owner who approves changes. Read each row as a separate control point, because a mismatch at any step lets a dashboard query see data the user should not reach. The main takeaway is that Superset roles do not decide Trino access on their own, so each mapping needs a named approver and a documented Trino access control method.
| Mapping step | What to configure | Who approves changes |
|---|---|---|
| Identity source in Superset | LDAP or OAuth group claims that Superset reads at login, mapped to Superset roles with AUTH_ROLES_MAPPING | Identity team owns the directory groups; Superset admin owns the mapping |
| Superset role | A role per data audience, such as finance analysts or operations viewers, with database access limited to the Trino connections that audience needs | Data governance lead with the Superset admin |
| Trino principal | The end user name passed through user impersonation, so Trino logs and authorizes the real user rather than the shared Superset service account | Platform engineering, after impersonation is tested end to end |
| Trino group or role | Group membership in the identity provider or Trino role assignment that Trino's access control reads for the principal | Identity team with the Trino administrator |
| Catalog grant | Read access to named Trino catalogs and schemas, with no grant on catalogs the audience does not need | Data owner of each catalog |
| Row or column restriction | Filters or column masks applied in Trino or the source system, not only in Superset dashboards | Data owner with the security team |
| Change record | Written request, reviewer, effective date and removal date for each new mapping or grant | Access review owner, checked on a schedule the organization sets |
Why user impersonation decides whether Trino sees the real user
The most consequential choice in this integration is whether Superset connects to Trino as one shared service account or passes each dashboard viewer's identity through to Trino. With a shared service account, every query arrives at Trino under the same principal. Trino's query history, event listener output and audit trail then show one user for all dashboard activity, and any row filter or column mask you define in Trino applies to that account alone. With per-user impersonation, Trino receives the identity of the person who ran the chart, so access policies, masks and audit records reflect the actual user. That choice should be made before dashboards are built, because retrofitting it later means reworking connections, grants and the logs you already collected.
Before relying on either model, confirm three behaviors in your own environment. First, check whether the impersonation setting for your Trino database connection is available in the Superset release you run, and read the release notes for any change to it. Second, confirm that Trino trusts the identity Superset forwards, including the authentication method, the service account allowed to impersonate, and which users it may impersonate under your Trino access control rules. Third, test what happens to cached results. If Superset caches a chart's results and serves them to other users, one user's row-level view may appear to another, so decide whether caching is keyed by user or disabled for restricted datasets.
Run the test with two accounts that have different Trino permissions. Query the same dataset through a dashboard, then inspect the Trino query log and confirm the recorded user, the applied filters and masked columns, and whether a cached result was returned. If the recorded user is always the service account, or the second user sees the first user's rows, do not roll the dashboards out to production. Record the results as evidence for your access review, and ask your implementation partner to include this verification in the written scope.
Security controls for a Superset to Trino connection
A Superset to Trino connection crosses several trust boundaries: the browser, the Superset application, its metadata database, the Trino coordinator and the network path between them. The cards below cover the controls that sit on each boundary, and each one should be confirmed in your own environment before you rely on it.
TLS between Superset and Trino
Traffic from Superset workers to the Trino coordinator carries SQL, result sets and the user identity used for impersonation, so it should be encrypted end to end. Confirm that the connection string or connect arguments enable TLS, that the coordinator certificate chains to a CA your Superset image trusts, and that certificate verification is not disabled to get a connection working. Ask your Trino and Superset teams to test the failure case where verification fails, because a silent fallback to an unverified connection is the most common gap.
Credentials stored outside the connection string
Passwords and tokens written into the SQLAlchemy URI are visible to anyone who can open the database connection screen or read the metadata database. Store secrets as environment variables or in a secrets manager that injects them into the Superset container, and reference them from configuration rather than typing them into the UI. Check that Superset's SECRET_KEY and the Trino credentials are not committed to images or repositories, and that rotating a Trino password does not require editing the metadata database by hand.
Service account scope
Superset needs one Trino identity to open connections, and it should hold only the catalogs, schemas and tables that dashboards use. Grant that account read access through Trino's access control rules, not broad administrative rights, and keep write and DDL privileges out of it. Confirm with the Trino team which catalogs the service account can reach, since federated queries can expose data from a source system that was never meant to be shown in a dashboard.
SSH tunnel key handling
When Trino sits behind a bastion, Superset may connect through an SSH tunnel that uses a private key. Keep the key in the secrets store, restrict it to the tunnel host, use a dedicated key for this connection, and rotate it on the same schedule as other service credentials. Ask whether the bastion logs tunnel sessions and who can read those logs, because the tunnel is an access path that bypasses the application layer.
Restricting SQL Superset may run
Superset lets users write SQL in SQL Lab, so a database user can run any statement the service account permits. Limit the Trino account to read-only queries, set query timeouts and row limits in Superset, and decide whether ad hoc SQL Lab access is granted to all dashboard viewers or only to analysts. Review the Superset feature settings that restrict SQL execution before rollout, and test that data modification statements fail with the account in use.
Blocking direct access to the metadata database
Superset stores its own metadata, including saved connection details, in a separate database. That database should accept connections only from the Superset application and its workers, never from Trino users or the analytics network. Confirm that Trino connections are not configured to point at the metadata database, that its credentials differ from every analytics credential, and that a read-only analytics role cannot reach its schema.
Logging of impersonated queries
When impersonation is enabled, Trino records queries under the end user's identity, which makes Trino's query history the authoritative audit trail. Confirm that Trino event logging is enabled and retained according to your policy, and that Superset's own logs record which user opened each dashboard. Test that a query from a named user appears in both systems with a matching identity, since a mismatch means the audit trail cannot be trusted.
SECRET_KEY rotation on the Superset side
Superset signs session data and encrypts stored connection credentials with its SECRET_KEY, which must be set explicitly before the application starts. Plan rotation with PREVIOUS_SECRET_KEY so that existing sessions and encrypted values remain readable during the change. Record the rotation procedure, test it in staging, and confirm that Trino connection secrets still decrypt after the key changes.
Performance trade-offs when Superset queries federated data through Trino
When a chart reads from one Trino catalog, Trino pushes filtering and aggregation down to the connector, and most of the latency comes from the source system and the amount of data scanned. Superset adds little overhead beyond rendering the result, so the main levers sit in the data model and the chart definition rather than in Superset itself. Teams should confirm which connector each catalog uses, since pushdown support varies by connector and that support decides how much data crosses the network.
- Pushdown behavior: Check in the Trino query plan whether filters and aggregations run in the source connector or after data is pulled into Trino.
- Partition and time filters: Dashboards that always filter by a partition column scan far less data than ones that rely on a derived date expression.
- Chart granularity: Fine time grains over long ranges return large result sets that the browser must render.
- Source capacity: The operational database or lake behind the catalog often sets the ceiling, not Trino or Superset.
- Column selection: Virtual datasets that select every column increase data transfer for no benefit.
Measure the Trino query time and the source query time for the slowest three charts, and confirm the connector pushdown behavior with the Trino and connector documentation for your versions before tuning Superset.
A join across two catalogs is executed inside Trino, which must read rows from both sources, move them into its workers and join them there. This is where federated queries become expensive: the cost grows with the rows read from each side rather than with the rows in the final result. Superset sends the SQL and waits, so any tuning happens in the query design, the Trino cluster sizing and the source systems.
- Row volume before the join: Filter each side inside a subquery or view so that Trino moves fewer rows across catalogs.
- Join keys and types: Mismatched data types or functions applied to join keys can prevent efficient execution on one side.
- Worker memory and spill: Large joins can exhaust memory on Trino workers, so check the cluster's memory limits and spill settings with your Trino administrator.
- Statistics: Trino's join planning depends on table statistics, which vary by connector and may need refreshing.
- Materialized intermediate results: Where a join runs for many dashboards, a scheduled table built outside Superset can remove repeated cross-catalog work.
Before approving a federated dashboard, run the join in the Trino CLI or web UI with EXPLAIN ANALYZE and record rows read per catalog, peak memory and elapsed time.
When many users open the same dashboard, Superset's cache can absorb most of the repeated load on Trino. Cached results are keyed on the query and its filters, so users with different filter values or different row-level security rules do not share entries. The effect of caching depends on how often the same queries repeat and how long results stay valid for the business. Caching is configured in Superset, but the cache store and its sizing belong to the platform team.
- Hit rate by filter combination: Dashboards with many free-form filters produce many distinct cache keys and fewer hits.
- Cache timeout: A short timeout keeps data fresh but sends more queries to Trino, while a long timeout reduces load and delays updates.
- Row-level security: Per-user security rules split cache entries, which lowers the hit rate for large audiences.
- Concurrency at refresh time: Many users opening a dashboard just after a cache expires can trigger the same query at once.
- Trino resource groups: Limits on concurrent queries in Trino protect the cluster when dashboards refresh together.
Check the cache hit rate and the number of queries Trino receives per dashboard view for a representative week of use, and confirm the caching options against the Superset configuration documentation for your release.
Queries that take minutes, such as wide exports or multi-catalog scans for monthly reviews, are better run asynchronously so that the browser does not hold a connection open. The Superset architecture documentation states that async queries require the caching layer and worker components, and most installations use Redis and Celery for them. Without those components, long queries run in the web request and compete with interactive users. Query cancelation also depends on this design: a cancel request reaches Trino only when Superset tracks the query.
- Worker capacity: Celery workers each hold a query while it runs, so a few slow federated queries can block others unless workers are sized for them.
- Result backend storage: Async results must be stored and expire, so check where results live and how long they are kept.
- Cancelation path: Test that cancelling a query in Superset stops the matching query in Trino and frees its resources.
- Timeouts: Set separate limits for interactive charts and background work, and confirm the Trino query timeout matches.
- Scheduled reports: Reports and alerts also depend on the same worker components, so they share capacity with ad hoc async work.
Before relying on async execution, run a representative long federated query, cancel it midway, and confirm in Trino that the query stopped and the worker released its slot.
Common failures when connecting Superset to Trino and how to fix them
This table pairs common Superset-to-Trino failures with their likely causes and a check you can run to confirm each one. Read it from the symptom column when a connection, query or dashboard misbehaves, then work through the check before changing configuration. The main takeaway is that most failures trace back to driver versions, catalog grants, tunnel settings or caching scope, and each can be tested directly.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| Test connection fails with a driver or import error | The Trino SQLAlchemy driver is missing from the Superset image or is incompatible with the Superset release | Confirm the Trino driver package is installed in the same image as the running Superset web and worker containers, then check its version against the Superset documentation for your release |
| Connection succeeds but queries fail with a dialect error | The client library and SQLAlchemy dialect versions do not match each other or the installed SQLAlchemy version | Run the pinned package versions inside the Superset container and confirm they match the versions your image build records |
| TLS handshake or certificate verification error | Superset does not trust the certificate chain presented by the Trino coordinator, often an internal certificate authority | Add the internal CA bundle to the Superset image and set the verification option in the connection extras to point at it, then test from inside the container with the same hostname |
| Certificate error only for some hostnames | The certificate does not list the hostname or load balancer name used in the connection string | Compare the certificate subject alternative names with the host in the SQLAlchemy URI and correct whichever side is wrong |
| Queries fail for some users but work for administrators | Impersonation is enabled, and the impersonated Trino user lacks catalog, schema or table grants in the access control rules | Run SHOW CATALOGS and SHOW SCHEMAS as the affected user in Trino, then add the missing grants to the catalog's access rules |
| Impersonated query returns access denied on a catalog that appears in the list | Catalog-level access is granted but table-level or view-level rules block the query | Review the Trino access rules for the table and view names the dashboard references, and test the exact SELECT as the impersonated user |
| SSH tunnel connection times out | The bastion host cannot reach the Trino port, the tunnel key is not accepted, or a firewall drops idle connections | Test the tunnel from the Superset host with the same key and target, confirm the Trino port is reachable from the bastion, and check idle timeouts on both hosts |
| Dashboards hang or fail intermittently after the tunnel is set up | The tunnel is opened per request or drops under load, so connections are not reused | Confirm the tunnel host and port in the database settings are stable, review the bastion logs for dropped sessions, and retest with a single chart |
| Queries keep running in Trino after the user closes the browser | Superset stops polling for results, but the query remains active on the Trino cluster until it finishes or is cancelled | Check the query list in the Trino web interface after closing a chart, and confirm the cancellation path is enabled in your Superset release before setting resource limits |
| One user sees different rows or figures for the same dashboard | Cached chart results are shared across users, or impersonation is off so Trino applies a service account's rights to every viewer | Check the cache timeout and whether the cache key includes the user or impersonation setting, then compare the Trino query user recorded for each viewer |
How to test the Superset and Trino connection before users depend on it
Run a fixed test plan in staging before any dashboard owner points production content at Trino, and write down the expected result of every test before you run it. Start with a connection test for each Trino catalog that Superset exposes, confirming that the database connection in Superset resolves, authenticates and lists schemas and tables from that catalog only. Record the catalog name, the connection user or impersonated identity, and the schema list you expect. A mismatch at this stage usually means a wrong catalog or schema in the connection string, not a Trino fault, so fix it before moving on. This order matches the upgrade guidance to test in staging first and check breaking changes before anything reaches production.
Next, test access per role. Create one test account for each Superset role that will query Trino, sign in as each one, and run the same set of queries against tables those users should and should not see. Compare what Superset returns with what the Trino access rules and grants say should happen, and check the query history on the Trino side to confirm the real user identity was passed through when impersonation is enabled. Then run a cancelation test: start a deliberately long federated query from a Superset chart or SQL Lab, cancel it in the Superset interface, and confirm in Trino that the query stops and releases its resources. If it keeps running, the cancelation path is not working and dashboards will leave orphaned load on the cluster.
Finish with a failover or restart test of the worker tier, which handles async queries, alerts and reports in a deployment that uses the caching layer and Celery. Restart the worker processes during a running asynchronous query and confirm the query either completes or fails with a clear status, and that the next scheduled report still runs. Confirm your own worker recovery and restart behavior in your environment, because the outcome depends on your broker and deployment setup. Keep the recorded expectations, actual results and any deviations in the change record so that the sign-off decision rests on evidence, and so that the same plan can be rerun after every Superset or Trino upgrade.
Questions buyers ask before hiring help for a Superset and Trino integration
What drives the effort and cost of a Superset and Trino integration?
The main drivers are the number of Trino catalogs Superset must reach, the identity model that decides who each query runs as, whether user impersonation is required, how isolated the networks are between Superset, Trino and the data sources, and how much tuning the federated queries need. Each catalog adds connection design, role mapping and testing. Impersonation adds work on both sides, because Trino must trust the identity Superset passes and the data sources must enforce access for that identity. Network isolation adds approval cycles that often take longer than the configuration itself. Ask for a written, fixed-scope quote that lists each catalog, the identity provider, the impersonation approach and the network paths in scope.
What is one-time work and what recurs after go-live?
The one-time work covers design, the first driver and catalog configuration, identity and impersonation setup, network paths, query limits, testing and handover. Recurring work is less visible but continuous. Superset releases need staging tests, a metadata database backup and the upgrade steps in the upgrade documentation before production changes. Driver and Trino client versions change and need retesting. Access reviews must confirm that role mappings and catalog permissions still match the access model. Ask the provider to separate these items in the quote so you can see which costs repeat and who owns each one.
How long does an integration like this usually take?
Duration depends on the same scope drivers as cost: the number of catalogs, the identity integration, whether impersonation is required and how long network approvals take in your organization. A single catalog with a settled identity model and open network paths is a much smaller piece of work than several catalogs with federated identity, impersonation and tightly segmented networks. Ask for the timeline as part of the written scope, with the dependencies named, especially approvals from your network and identity teams. A timeline that does not list those dependencies is worth questioning.
What must our team provide before the work starts?
Three groups of people are usually needed. Trino administrators confirm the catalogs, the coordinator address, the authentication method and the rules that will apply to Superset's service identity and impersonated users. Identity owners confirm how users sign in to Superset, which groups exist and how they map to Superset roles. Data owners confirm which schemas and tables each role may read, and sign off on sample queries. Network owners approve the paths between Superset, Trino and any SSH bastion, along with certificate trust. Name these people in the scope document and agree on response times, because waiting on them is a common cause of schedule slippage.
Can our own team build and run this integration without a partner?
Yes, if your team already runs Trino, Superset and your identity provider and has someone who can own the impersonation design. The work is standard configuration, but it crosses several systems, and small mistakes in impersonation or catalog permissions can expose data that should stay restricted. A partner is most useful when the team lacks Trino or Superset experience, when the access model is complex, or when the work must meet audit expectations. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Whichever route you choose, the test is whether one person can explain how a given user's query reaches Trino and which rules apply to it.
What goes wrong most often with federated queries and impersonation?
The most common problem is a service account that quietly has broader access than the users it serves, so dashboards show data users should not see. The second is impersonation that is configured in Superset but not enforced in Trino, so every query runs as the same identity in the logs. Federated queries that join large tables across catalogs can also overload the sources, and long-running queries may need cancelation handling and sensible limits. Check these areas during testing by running queries as several test users with different roles and comparing the results and the Trino query history. Confirm exact setting names and behavior against the Superset and Trino documentation for your versions.
Does the work cover security review and audit evidence?
Integration work includes configuring and documenting the controls the integration depends on, such as role mappings, impersonation rules, catalog permissions and logging of who ran which query. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask the provider exactly which evidence it will deliver, such as configuration exports, test records and runbooks, and confirm that any security testing is listed as a separate line in the written scope.
How DeployOpen scopes and delivers a Superset and Trino integration
DeployOpen plans, builds, documents and supports self-hosted Superset connected to Trino inside your own infrastructure. Each engagement starts from a written, fixed scope that names the catalogs, identity model and query limits covered, so your team knows what is delivered before work begins.
How we scope
- Inventory the Trino catalogs, schemas and tables that dashboards will query, with their owners and sensitivity.
- Agree how Superset user identities map to Trino users for impersonation, and which roles see which data.
- Record the written scope, deliverables and timeline before work starts; ongoing support can be added as a retainer.
How we build
- Install the Trino driver in the Superset image and configure one connection per catalog with tested credentials.
- Enable user impersonation, then verify with test queries that Trino audit logs show the real user, not a shared service account.
- Test SSH tunneling, query cancelation and federated query timeouts against your network and performance expectations in staging.
How we hand over
- Deliver configuration, connection inventory, role mapping and runbooks for the Superset and Trino integration.
- Document the upgrade steps for Superset, including a metadata database backup, staging test and review of UPDATING.md.
- Walk your platform and data teams through verification results, open risks and the items you must confirm with Trino.
How we support
- Offer ongoing support, upgrades and continuous testing for the integration as a retainer.
- Re-run impersonation and query limit checks after Superset or Trino version changes.
- Review federated query performance and warehouse load with your team as dashboards and data sources grow.
