Why Apache Superset dashboards slow down and when to fix them
A Superset dashboard feels slow when a single page load fans out into many chart queries that each wait on the warehouse, and the page cannot render until the slowest of them returns. The usual causes are chart count, tabs that load everything at once, native filters that trigger repeated queries, cold caches, and datasets that scan far more rows than the chart needs. A tuning project is worth scoping when users complain about load times on dashboards they use daily, when warehouse spend rises with dashboard views, or when a dashboard that once loaded quickly now times out. Before scoping anything, ask whether the slowness is consistent or only appears at peak hours, because those two patterns point to different fixes.
Apache Superset is licensed under the Apache License 2.0 and has no paid edition, so there is no license upgrade that makes dashboards faster. The work is configuration, data modeling and infrastructure: deciding which charts belong on a page, how long results stay cached, which datasets point at raw tables versus summarized ones, and how many web and worker resources sit between users and the warehouse. Those decisions are the same whether your team or a partner carries them out, so the scope should be defined around measured bottlenecks rather than around a product change.
Confirm three things before you start. First, which Superset version you run, since query behavior and caching options vary between releases, and the release history is published on the apache/superset releases page on GitHub. Second, whether your metadata database and cache are sized for the load you have, because a slow metadata store slows every page. Third, which warehouse serves the slow charts, so you can read its query history alongside Superset's own logs. Without those baselines, any tuning change is a guess, and a guess can move load from the dashboard onto the warehouse bill without making users faster.
Finding the cause before changing anything
This sequence identifies which layer makes a dashboard slow (the browser, the Superset web tier, the cache or the warehouse) so the team fixes the right one first. Each step produces a finding that points to the next check.
Reproduce the slow load with a named user and dashboard
Someone on the BI or platform team opens the slow dashboard as the user who reported it, using the same filters, date range and browser. They record the time to first chart, the time until the last chart finishes and whether the page is responsive while charts load. The step is done when the slow load can be triggered on demand. If it only happens for one role, the team checks that role's row level security rules and dataset access before going further, because permissions can change the queries a dashboard runs.
Count charts, datasets and queries per dashboard
An engineer lists every chart on the dashboard, the dataset each one uses and how many charts share a native filter. They compare that count with the number of queries the browser sends when the page opens, which the browser's network panel shows. The output is a table of chart count, unique queries and the heaviest charts. A high query count with few unique datasets suggests the problem is dashboard design, while many slow queries against one dataset points to the warehouse or the dataset definition.
Check which tabs and charts load on open
The engineer checks whether charts on inactive tabs, collapsed sections and off-screen areas fetch data as soon as the dashboard opens. They note which requests fire before a user scrolls or clicks a tab. The check is complete when the team knows how many queries run on open and how many are deferred. If most queries are for hidden content, the next fix is in the dashboard layout and data fetch behavior, not in the database.
Compare cold and warm cache responses
The engineer runs the same dashboard twice, first after clearing the relevant cache entries and then immediately after, and records the response time of each chart request. Clearing cache means a test environment or a dataset with a known cache timeout, so the comparison is repeatable. If warm responses are fast and cold responses are slow, the team focuses on cache coverage, timeouts and warming. If both are slow, caching will not solve it, and the team moves on to the warehouse query plan.
Identify the slowest queries from Superset logs
An engineer pulls the SQL that Superset generated for the slowest charts, using the chart's query view or the Superset logs, and matches each statement to its chart and dataset. They sort by execution time and note row counts returned and any row limits applied. The output is a short ranked list of queries. This list tells the team which charts are worth tuning, and it shows whether the generated SQL is much heavier than the chart needs.
Read the warehouse query plan for the slowest queries
A database engineer runs the warehouse's explain or query profile command on each slow statement, using the same account and privileges Superset uses. They look for full scans of large tables, joins that multiply rows, missing partition or clustering use and repeated subqueries. The check is done when each slow query has a stated cause in the plan. The cause determines the fix: a missing filter or index belongs to the warehouse, while repeated heavy aggregation across many charts usually points to a pre-aggregated dataset.
Assign each finding to a layer and fix order
The team groups the findings into the browser and dashboard design, the Superset web and cache tiers, and the warehouse. They put the layer with the largest measured share of load time first, then write down the expected effect and the test that will confirm it. Confirm with your own environment which tuning options are available for your Superset version and warehouse before committing to a change, since settings differ by release. The output is a written finding list that is reviewed before any configuration or dataset changes are made.
Which fix matches which bottleneck
Every chart on a dashboard usually sends its own query when the page loads, and tabs do not prevent that by themselves. A dashboard with many charts spread across several tabs can multiply warehouse work and browser rendering before a viewer has looked at anything. Count the charts and the queries each one fires on first load before you change the layout.
- Split by question: Move charts that answer different questions onto separate dashboards. Trade-off: viewers navigate between dashboards, and each one needs an owner.
- Merge overlapping charts: Replace near-duplicate charts with one chart and a control. Trade-off: some viewers lose a detail view they scanned at a glance.
- Trim native filters: Each native filter can trigger queries when its value changes, so remove filters nobody uses. Trade-off: analysts have fewer ways to cross-filter.
- Cap rows on large tables: Set sensible row limits on table charts so the browser and warehouse do not return rows nobody reads. Trade-off: users who need the full extract must use SQL Lab or an export.
Check the query count on first load for each tab, and confirm actual usage with the dashboard owners before you remove any chart.
Once data arrives, the browser must draw every chart and table, and large result sets slow that work even when the query itself is fast. Deferred fetch changes when queries run, so charts on inactive tabs load only when someone opens them. Confirm how your Superset version handles tab loading and which related feature flags exist before you rely on them.
- Defer inactive tabs: Load charts on the active tab only. Trade-off: a chart on another tab can appear empty for a moment when a viewer first opens it.
- Virtualize long tables: Render only the visible rows so scrolling stays responsive. Trade-off: browser find and print behavior may differ, so test it with real users before rollout.
- Reduce points per chart: Aggregate time series to the grain people read, such as days instead of minutes. Trade-off: fine-grained investigation needs an explore view or a separate chart.
- Limit auto-refresh: Restrict refresh intervals on shared dashboards so many open browsers do not repeat the same queries. Trade-off: data on screen is older between refreshes.
Record the time to first useful chart on the slowest dashboard using the browser developer tools, then compare the same measurement after each change.
The data cache returns stored results for identical queries, so the hit rate depends on how similar incoming requests are. Varied filter combinations, per-user security context, short timeouts and frequently changing source tables all reduce matches. The architecture documentation describes the caching layer as optional, so confirm it is configured in your environment before tuning timeouts, since a low rate often has a design cause.
- Set timeouts per chart and dataset: Give stable reference data a longer timeout and fast-changing data a shorter one. Trade-off: cached data can be stale for up to the timeout.
- Reduce per-user variation: Filters based on the viewer's identity and row level security rules make each user's query different. Trade-off: shared results are harder to reuse, so keep these only where access control requires them.
- Standardize default filters: Give shared dashboards sensible default values so most visits send identical queries. Trade-off: viewers who want other defaults must change filters on every visit.
- Size the cache store: Confirm the cache has enough memory for the working set and watch for evictions. Trade-off: more memory cost, and a cache outage sends load back to the warehouse.
Compare hit rates before and after each change, and confirm which timeouts and user contexts each cached result is keyed to in your configuration.
Some dashboards stay slow because the warehouse takes a long time to answer, even with caching in place. Virtual datasets that join or aggregate large tables repeat that work on every cache miss. Review the query plan for the slowest charts first, then decide whether the fix belongs in the data model rather than in the dashboard.
- Pre-aggregate the grain people read: Build summary tables or materialized views at the day, account or region level that dashboards query. Trade-off: someone must build, test and own the refresh pipelines, and data arrives on the refresh schedule.
- Read the query plan: Use the warehouse's explain tooling on the SQL that Superset generates for the slowest charts. Trade-off: plan review needs someone who understands both the warehouse and the dataset logic.
- Align filters with table layout: Make common filters, such as date ranges, match partition or clustering keys where your warehouse uses them. Trade-off: the table layout may also need to serve other workloads.
- Move heavy logic upstream: Compute joins and calculated metrics in the pipeline so they run once per refresh. Trade-off: each change to business logic ships through the data pipeline, so it takes longer to reach dashboards.
Confirm with your warehouse vendor which plan and cost features apply to your edition, and track bytes scanned or compute consumed per dashboard load.
How chart count, tabs and filters shape load time
Most slow Superset dashboards are slow because of design, not hardware. Each chart on a dashboard is a query, and the way charts are grouped, filtered and refreshed decides how many of those queries run, how often and how many reach the warehouse.
Number of charts per dashboard
Every chart on the first screen of a dashboard issues its own query when the page opens, and the browser waits for the slowest one before the page feels finished. Count the charts that load on open, then check how many of them read the same dataset with slightly different filters. Those can often be merged into one chart with a dimension or metric switch. Ask your team to confirm the chart limit they consider acceptable before a dashboard goes to users.
Tabs that hide charts from open
Charts inside a tab that is not selected should not query on page load, but this behavior depends on the Superset release and on how the dashboard was built. Test it by opening the dashboard with browser developer tools and counting the chart requests before and after you click into a tab. Confirm the current behavior in the Superset release notes before you rely on it for a dashboard with heavy charts.
Native filter defaults that add queries
Native filters are useful, but a filter with no default or with a default that selects every value makes each affected chart query the full range. A filter that depends on another filter can also trigger a second round of requests as the first one resolves. Set sensible default values, limit the charts each filter applies to, and check whether a filter's option list runs its own query against the warehouse on every page load.
Auto-refresh intervals
Auto-refresh reruns every chart on a dashboard at a fixed interval, whether or not anyone is looking at it. A short interval on a dashboard with many heavy charts multiplies warehouse queries for each open browser tab. Set the shortest interval that the business decision actually needs, and ask whether the dashboard can use cached results between refreshes. Check the auto-refresh options in the release notes for your version, since intervals and limits have changed over time.
Performance options and when each fits
This table compares the main levers for making a slow Superset dashboard faster, from chart-level cache settings to warehouse-side objects. Read each row by first confirming where the time is spent, then choosing the lever closest to that cost. The main takeaway is that caching and row limits hide slow queries, while pre-aggregation and warehouse tuning remove the work itself.
| Option | What it changes | When it fits | Trade-off |
|---|---|---|---|
| Cache timeouts per chart and dataset | Reuses a previous query result for a set period instead of querying the warehouse again | Many viewers open the same dashboard and the underlying data changes slowly or on a known schedule | Viewers can see results that are as old as the timeout; stale data must be explained to business users |
| Redis-backed caching | Stores cached query results and metadata in Redis so all web replicas share one cache | Several web replicas serve the same dashboards and cache hits vary by which replica answers | Adds a service to run and monitor; if Redis is unavailable, users fall back to uncached queries |
| Row limits | Caps the number of rows a chart returns to the browser or query | Table and detail charts return far more rows than anyone reads | Totals and aggregates may be incomplete if the limit cuts the result before aggregation; check each chart |
| Deferred or tabbed loading | Fetches data only for the tab or section the user opens, not for every chart on load | Dashboards have many charts across tabs and most users view only one or two tabs | Users wait when they switch tabs; does not reduce work on the tab they open first |
| Pre-aggregated virtual datasets | Defines a dataset as a query over a smaller summary table or view in Superset | Charts repeatedly group large fact tables by the same few dimensions | Someone must maintain the summary logic, and definitions can drift from the raw tables |
| Pre-aggregated physical datasets | Materializes summary tables in the warehouse on a refresh schedule | Freshness needs are predictable and the warehouse can absorb scheduled rebuild cost | Refresh jobs add warehouse spend and an orchestration dependency; latency equals the refresh interval |
| Warehouse clustering or materialized views | Changes how the warehouse stores or precomputes data so filtered queries scan less | Slow queries filter on consistent columns, such as date or account, and the platform supports these objects | Clustering and materialized views have their own maintenance and cost rules; confirm them with your warehouse vendor |
Reading warehouse query plans behind slow charts
Once a slow chart is identified, the fastest way to learn why it is slow is to read the SQL that Superset sends to the warehouse and run it there with the engine's own plan tool. Open the chart in Explore, use the option to view the query, and copy the statement, including the time range, filters and any Jinja-templated values as they were rendered for that user. Then run it in the warehouse's query editor with its explain or profile command, such as EXPLAIN ANALYZE in PostgreSQL or the query profile in Snowflake, and compare the timing against what Superset reports. Look for full table or partition scans where the time filter should have pruned data, missing partition or clustering keys on the columns that dashboards filter on most, joins that multiply rows before aggregation, and the same subquery appearing several times because each chart on the dashboard rebuilds it. Confirm the exact plan commands and their output with your warehouse vendor, since the tooling differs by engine.
The fix often sits outside Superset. A dataset that exposes a raw fact table with no time or key filter will push every chart onto a full scan, and no amount of front-end tuning fixes that. Ask whether the dataset should point at a curated view, whether the filter columns are partitioned or clustered, and whether a pre-aggregated table at the grain the dashboard actually uses would answer most charts. Changes to dataset definitions, virtual datasets and warehouse objects need an owner who can approve them, and they should be tested against the same plan before and after, so the team can show the scan went away rather than assuming it did.
DeployOpen works with the data platform, analytics engineering and database teams that own the warehouse and the Superset datasets. We help identify which queries carry the cost, document the plan findings, and plan the dataset, partitioning or aggregation changes as a written scope with agreed deliverables. Changes that touch warehouse schemas or pipelines stay under the control of the team that runs them, and the scope should name who approves each change and how it will be verified in staging before it reaches production dashboards.
Security and operational risks of performance changes
Most speed fixes in Superset move data, reuse results or widen query limits, and each of those can expose rows, raise warehouse spend or break a dashboard that worked yesterday. The cards below cover the risks that come with caching, pre-aggregation, limits and rollout, and the prerequisites that must be settled before any of them go live.
Cache keys that ignore row-level rules
Superset caches chart results, and if the cache key does not reflect the filters applied for each user, one person's filtered result can be served to another. Row level security rules are applied at query time, so check that every cached chart, filter state and Explore result is keyed to the identity and rules that produced it. Test with two accounts that should see different rows and confirm the second account never receives the first account's cached data. Treat any shared cache as a data path, not a performance feature.
Pre-aggregated datasets that bypass row rules
A pre-aggregated table or materialized view is often faster because it removes the per-user filter path, but it can also hold rows or columns that row level security would have hidden from the source. Before exposing a summary dataset, confirm which roles can query it, whether the RLS rules are reapplied to it in Superset, and whether the aggregation has already collapsed the dimensions needed for filtering. Document the owner of each summary table and who approves its schema changes.
Raised limits that grow cost and exposure
Increasing row limits, query timeouts or the number of charts per dashboard lets more data leave the warehouse for each page load and more users run expensive queries. A higher limit can also return sensitive columns in a table chart or CSV export that a smaller limit hid by accident. Set limits per role where your platform allows it, record who approved each change, and review warehouse usage after the change to see which dashboards drove the increase.
Shared dashboards multiplying query load
A dashboard that works for a few analysts can fan out into a large number of warehouse queries once a team or an embedded audience uses it. Auto-refresh intervals, native filters that trigger many queries and tabs that load everything at once all multiply that effect. Before broad sharing, measure the query count per page view under realistic concurrency and confirm the warehouse account has spending or concurrency limits that protect other workloads.
Secret key and access model as prerequisites
Caching, sessions and any encrypted credentials depend on a user-specified SECRET_KEY that is stable across all web and worker replicas, and on a role model that already limits who can open which datasets. Changing cache behavior before those are settled can make failures harder to trace and can leave old cached data readable after a permission change. Confirm the key is set and rotated through a documented process, and confirm dataset and database permissions are correct before tuning anything.
Staging tests before production changes
Caching changes, dataset rewrites and limit adjustments each need a test that compares results, not only response time. Run the same dashboard as users with different roles in a staging copy that mirrors the production metadata database and warehouse permissions, and compare row counts and totals against the source. Back up the metadata database before changes, keep a rollback step for each change, and check the project's release notes for behavior that affects caching or charts when you upgrade.
Questions teams ask before fixing slow Superset dashboards
How long does it take to diagnose a slow Superset dashboard?
The length depends on how many dashboards are involved, how many charts each one holds, and whether query history and access to the warehouse are available from the start. A focused review of one dashboard with clean query logs is quick to scope. A portfolio of dashboards, shared datasets and several warehouses takes longer because each slow chart has to be traced from the browser request through the Superset web tier, the cache, and the warehouse query plan. No fixed duration applies to every environment, so ask for a written scope that lists the dashboards, the databases and the evidence the diagnosis will produce.
Can our team fix slow dashboards without outside help?
Often yes, if someone can read Superset chart query logs, run EXPLAIN on the warehouse, and change datasets and chart settings. The work usually splits into three areas: chart design (chart count, tabs, native filters), caching and worker settings, and warehouse work such as partitioning, clustering or pre-aggregated tables. Teams that own the warehouse and the Superset admin role can often handle the first two alone. Outside help makes sense when the bottleneck sits in several layers at once or when the team lacks time to run controlled tests in a staging instance.
What do we need to provide for a dashboard performance review?
Plan to provide four things before work starts:
- Read-only warehouse access for the database accounts Superset uses, plus a way to run query plans
- Query history or Superset logs for the slow dashboards, with timings and user counts
- A staging Superset instance with a copy of the metadata database, so changes can be tested without affecting users
- Named owners for the dashboards, datasets and warehouse, who can approve changes
Without staging, fixes tend to be guesses. Ask the reviewer to state exactly which of these items they need and what happens if one is missing.
What drives the cost of a Superset performance engagement up or down?
Cost follows the scope agreed in writing, which is why most engagements are fixed-scope. The main drivers are the number of dashboards and datasets, how many layers are involved (Superset configuration, caching, Celery, the warehouse), the state of access and logs at the start, and whether a staging instance already exists. Recurring costs come after the fix: warehouse compute for cache warming or pre-aggregation, Redis or worker capacity, and any retainer for ongoing tuning. Ask which of these costs are one-time and which recur, and who pays the warehouse bill for test queries.
Is caching safe when row-level security is enabled?
Caching is safe only when cache keys separate the data each user is allowed to see. Superset applies row-level security filters to queries, so a shared cache entry built for one user can expose rows to another if the cache key does not account for the security context. Review the cache configuration and the row-level security rules together, test with two users who should see different rows, and confirm that cached results are keyed by the relevant roles or filters. Also check whether cache warming runs as a user with broader access than the viewers it serves.
What should we ask for in a written quote for this work?
A useful quote lists the dashboards and datasets in scope, the Superset version and metadata database, the warehouses involved, and the evidence each deliverable produces, such as before and after query timings. Ask who performs each step, which access the work requires, and whether testing happens in staging. Confirm what is excluded, for example warehouse redesign, Redis capacity changes or future upgrades. Ask how changes are handed over, including documented chart and dataset settings, and whether a retainer for later tuning is offered as a separate item.
Does a slow dashboard usually mean the warehouse is the problem?
Not always. A dashboard can be slow because it renders too many charts at once, fetches data for hidden tabs, or triggers large numbers of queries on each filter change. It can also be slow because a query scans far more data than needed or because a web or worker tier is undersized for the number of users. Diagnosis separates these causes by comparing browser timings, Superset query logs and warehouse plans. Ask the reviewer to show which layer accounts for most of the delay before they propose changes.
Limits to confirm in your environment
Dashboard tuning depends on the platform underneath it. Before changing charts or caching, confirm the Superset version, the metadata database, the supporting services and the deployment path, because each one limits which fixes are available. The cards below are the checks to run first.
Superset version in use
Start by recording the exact Superset version your dashboards run on and comparing it with the current release list. Chart rendering, query behavior and caching options change between releases, so a fix written for one version may not apply to another. Check the release notes for your version before you copy a configuration from documentation or a forum post. If you plan to upgrade to fix performance, treat that as a separate change with its own staging test.
Metadata database version
Superset stores dashboards, charts and user state in its metadata database, and the configuration documentation lists supported PostgreSQL and MySQL versions. Confirm that your server falls within the supported range, and that you are not running the SQLite default or the Docker Compose PostgreSQL container, which the architecture documentation does not recommend for production. Slow metadata queries can make every dashboard feel slow, so check this layer before tuning charts.
Redis and Celery deployment
Caching, async queries and thumbnails depend on the caching layer and Celery workers. Confirm whether Redis and Celery are deployed in your environment, and whether the cache is actually configured for chart and dataset results. If they are absent, dashboards re-run every query on each load, and many of the fixes in this topic will have no effect. Ask who operates the cache and workers and how their health is monitored.
Warehouse concurrency limits
A dashboard with many charts sends many queries at once, and the warehouse decides how many of them run in parallel. Ask your data platform team for the concurrency limit, queue behavior and per-user or per-warehouse quotas for the account Superset uses. If the warehouse queues queries, removing charts may help more than adding Superset capacity. Confirm these limits with the warehouse administrator rather than estimating them from dashboard load times.
Helm chart or Kubernetes Operator
The deployment path changes how you apply resource and worker settings. The 6.1.0 documentation describes the official Helm chart, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. The Operator is in alpha with a v1alpha1 API whose schemas may change between releases. Confirm which path you run, and avoid tuning settings in a chart or resource you plan to replace.
Dashboard ownership and change control
Performance fixes often change dataset definitions, chart types and native filters, which other teams may depend on. Confirm who owns each dashboard, who approves changes to shared datasets and whether you have a staging instance that mirrors production data volumes. Without that, a fix that speeds one dashboard can break a report that a different team relies on. Record the baseline timings before any change so you can show the result.
Sequence for a performance tuning project
The sequence starts with measurements and a database backup, then changes one layer at a time in staging so every improvement can be attributed and reversed. Each step closes with a check that shows whether the change worked.
Record baseline timings and query logs
Before touching configuration, the team records load times for each slow dashboard under the same filters and user pattern, then pulls the SQL that each chart sends to the warehouse from Superset's logs and the warehouse's query history. Superset's own event and log data help match slow charts to specific datasets. The step is done when every slow dashboard has a written baseline with chart count, tab count, median and worst-case load time, and the number of warehouse queries per page view. Without this record, later changes cannot be proven.
Back up the metadata database
The owner of the metadata database takes a verified backup before any change that touches dataset, chart or dashboard definitions, cache settings or the database connections that Superset stores. Tuning work usually edits these objects, so a restorable copy is the basis for any rollback. The step is done when a restore has been tested on a separate instance and the team can name the backup timestamp it would roll back to. Confirm the backup method with your database operations team, since it depends on your PostgreSQL or MySQL setup.
Classify the bottleneck by layer
Using the baseline, the engineer assigns each slow dashboard to one layer: the browser (too many charts or tabs rendering at once), the web tier (slow requests or timeouts), the cache (low hit rates), or the warehouse (slow or expensive queries). This prevents work on a layer that is not the constraint. The step is done when each finding is linked to evidence, such as a browser profile, a request log entry, a cache hit count, or a warehouse query plan, and the team agrees on the single layer to change first.
Apply one change in staging
The engineer makes a single change, such as reducing charts per tab, enabling deferred loading, adjusting a chart cache timeout, or building a pre-aggregated dataset, in a staging copy that holds the same dashboards, datasets and a representative data volume. Changing one layer at a time keeps the cause of any improvement or regression clear. The step is done when the change is recorded in a change log with the exact setting or object modified, the person who made it, and the time it was applied.
Verify cache hits and warehouse cost
After each change, the team repeats the baseline test with the same filters and user pattern, then compares load times, cache hit behavior and the number and cost of warehouse queries against the baseline. Running the test twice, once cold and once warm, shows whether the cache is doing the work. The step is done when the results show a measured improvement on the target dashboard without a regression on others, or when the change is reverted. If the warehouse bills by query volume or scanned data, the team also compares those figures from the warehouse's own usage reporting.
Repeat the cycle for each layer
The team moves to the next layer on the classified list and repeats the apply and verify steps. Each pass uses the updated baseline, so later results are measured against the state the users will actually see. The step is done when every finding on the list is either fixed and verified, or documented as accepted with its remaining load time and warehouse cost noted. Stopping here keeps the change set small enough to review.
Promote with a rollback plan
The approved changes move to production in a single controlled window, with the metadata database backup from earlier still available. The plan names the exact reversal for each change, such as restoring a previous cache timeout, removing a deferred loading setting, or pointing a dashboard back to its original dataset. The step is done when the production results match the staging verification, the rollback steps have been rehearsed, and the owner has confirmed that dashboards load for a sample of users. Ask your team to confirm the production change window and approval process before the work begins.
How DeployOpen scopes and delivers dashboard performance work
DeployOpen starts dashboard performance work with a fixed scope agreed in writing before anyone changes a chart, dataset or cache setting. The scope names the dashboards in question, the users and roles that open them, the databases they query, and the environments in which work may happen. Diagnosis comes first. In practice that means recording which dashboards load slowly, how many charts and native filters each one renders, which tabs are loaded on open, and whether the slow requests reach the warehouse or return from the cache. The findings, with the query plans and timings behind them, are written up so the client can decide which fixes to approve. Changes that alter what users see, such as chart limits, deferred loading or pre-aggregated datasets, are listed as separate items in the written scope so they can be accepted or declined individually.
Changes are tested in the client's own infrastructure, not on a demonstration instance. DeployOpen works in a staging copy of the Superset deployment connected to the same warehouse account or a representative replica, because cache behavior, Gunicorn timeouts and warehouse concurrency only show their real effect under the client's network, identity and data. Before and after measurements use the same dashboards, filters and test accounts, and the client's data owners confirm that any pre-aggregated dataset returns the figures they expect. Anything that changes configuration is applied through the client's normal change process. Documentation is handed over at the end: the diagnosis, each change with its rollback step, the settings that were left deliberately unchanged, and the checks to repeat after a Superset upgrade. Confirm with DeployOpen which of these artifacts are included in your scope and in what format.
