Why warm the Apache Superset cache before users arrive
Warming the cache is worth planning when a small set of dashboards is opened by many people at the same time and each open triggers warehouse queries that take a noticeable time to return. Picture a team whose executives open the same revenue dashboards at 8 a.m. on Monday (an illustrative scenario). Without preparation, the first viewer waits on cold queries, and the warehouse absorbs a burst of identical work. Superset's caching layer is the component that can hold those results, and its Celery worker and beat processes are the components that can compute them ahead of the first visit. The Superset architecture documentation lists the caching layer and workers as the parts that support asynchronous work such as alerts and reports, async queries and dashboard thumbnails, and most installations use Redis and Celery for them.
Warmup adds load before anyone asks for it. Every warmed chart is a query the warehouse must run, whether or not a user opens that dashboard that day. Warmup is usually justified when a few dashboards have predictable peak times, their queries are expensive, and the underlying data refreshes on a schedule that the warmup can follow. It is harder to justify for ad hoc exploration, for dashboards with many filter combinations, or for datasets that change continuously. Before enabling it, confirm with your data team how often each source refreshes, which dashboards carry business-critical traffic, and what your warehouse billing and concurrency limits are. Those answers, not the feature itself, set the size of the warmup job.
Which warmup strategy fits which dashboard set
A fixed list names the dashboards to warm by ID, usually chosen by the platform team with input from the business leads who open them most. The list lives in configuration or in a reviewed file, so every warmup run touches the same charts and the warehouse cost is easy to predict. The trade-off is that the list drifts: a dashboard built for a quarterly review keeps warming long after people stop using it, and a new board pack stays cold until someone edits the list.
- Who chooses: the platform team proposes the list, and each dashboard owner or business sponsor confirms that it should stay on it.
- Maintenance: review the list on a schedule and remove dashboards that no longer have an active audience.
- Warehouse load: predictable and bounded, because the number of charts and filter combinations is fixed in advance.
- Risk: stale entries keep consuming queries, and new high-use dashboards are missed until someone adds them.
- Ownership: record the approver for each entry so removal requests have a clear owner.
Before adopting this strategy, confirm with your data team which dashboards run the heaviest queries, since a short list of expensive dashboards can cost more than a longer list of cheap ones.
Usage-driven warming selects dashboards from recent view activity, so the set follows what people actually open. Superset's own usage data, or the audit and event logs in your deployment, can supply those counts, and the selection logic runs on a schedule. The benefit is that it adapts without manual edits. The cost is that the warehouse load moves with user behavior, so a sudden surge of views can enlarge the warming run at the wrong time.
- Who chooses: the platform team sets the rule (time window and ranking method), and the rule decides the list each run.
- Maintenance: the rule needs tuning as usage patterns change, and its inputs must be reliable and retained long enough to cover the window.
- Warehouse load: variable, because it grows with the number of dashboards that qualify and the filter combinations they expose.
- Risk: a cap on the number of dashboards per run keeps the load bounded, but it must be set deliberately, and the cap should be confirmed against your warehouse limits.
- Gap: dashboards used rarely but at critical moments, such as month-end, may fall outside the window.
Confirm how your Superset version exposes usage data and which thresholds your team wants to use. Avoid inventing a cutoff; set it from observed usage in your own environment.
Owner-based warming lets each team or dashboard owner decide which of their dashboards should be warm before their users start work. Ownership usually maps to the roles and groups already used for access, so the decision sits with people who know the audience and deadlines. This works well for organizations with distinct business units, but it spreads warehouse load across many decisions, and nobody may look at the total.
- Who chooses: each owner or team lead requests warming for their dashboards, and the platform team approves requests against a shared budget.
- Maintenance: owners update their entries when they change dashboards or retire them, which needs a named contact per dashboard.
- Warehouse load: the sum of many small requests, which is hard to forecast unless the platform team aggregates them.
- Risk: teams that request warming for everything can overload shared warehouse capacity, so a platform-level ceiling is needed.
- Access: warming runs as the executor user, so confirm that the executor can see every dashboard an owner requests and nothing beyond it.
Ask each team for its expected users, peak times and the warehouse budget it is willing to share, then compare the combined load with your database capacity before approving requests.
Choosing the executor user for cache warmup
The executor is the user account that runs warmup queries against your warehouse, and the setting that controls it is CACHE_WARMUP_EXECUTORS, which Superset 5.0.0 added according to the project's UPDATING notes. Pick this account deliberately before you enable any warmup task. Warmup does not run as the person who will later view the dashboard. It runs as the executor, so the result it stores is the result that the executor is allowed to see.
That matters because Superset applies row level security and dataset permissions when it builds a query. If the executor sees every row, the cache will hold full-table results, and a later viewer with a narrower role may be served data they should never have seen, depending on how your cache keys and guest or RLS rules are set up. Confirm this behavior in your own environment with a test dataset that has RLS rules, rather than assuming it. The safer pattern is a dedicated read-only account with access limited to the datasets that appear on the warmed dashboards, and with RLS rules that match the most restrictive audience those dashboards serve.
The risk of an over-privileged executor is both a data exposure issue and a warehouse cost issue. An account with broad grants will warm datasets nobody uses and can run expensive queries under a service identity that your warehouse audit logs attribute to Superset. Before rollout, ask your warehouse team to confirm the account's grants, and check the exact value format for CACHE_WARMUP_EXECUTORS in the Superset configuration documentation and the UPDATING notes for your version, since the format may differ between releases. Test the setting in staging first, then confirm which user appears in the warehouse query history during a warmup run.
Warmup options and when each fits
This table compares the four ways to warm the Superset cache: a fixed dashboard list, a scheduled Celery beat task, the executor user, and native filter warming. Read each row for what it does, when it fits, and what it costs the warehouse. The main takeaway is that every warmup run is real query traffic, so start with the smallest set of dashboards that users actually open first thing.
| Option | What it does | When it fits | Trade-off |
|---|---|---|---|
| Fixed dashboard list | Warms a named set of dashboards on a schedule, so their charts are cached before the first viewer opens them | A small number of executive or operational dashboards that many people open at the same time each morning | Every dashboard and filter combination in the list costs warehouse queries, even when nobody opens it that day |
| Scheduled Celery beat task | Runs the warmup as a periodic job through the Celery beat scheduler and workers, which Superset requires for this feature | Teams that need warmup on a fixed timetable and already run Celery workers and a single beat scheduler | Needs a broker, workers and one beat process; a second beat scheduler would trigger duplicate runs |
| Executor user choice | Sets which user account runs the warmup queries, using the CACHE_WARMUP_EXECUTORS setting added in Superset 5.0.0 | Warmup must read data under a specific service identity with known row-level access, rather than a personal account | The executor's permissions decide what gets cached, so a broad account can cache data that narrower viewers should not see from shared cache |
| Native filter warming | Pre-computes the option lists that native dashboard filters load, so filter dropdowns respond faster | Dashboards with native filters that users open with the default filter values | Each filter value combination is a separate cache entry, so warming many values increases query volume quickly |
Warming native filter options alongside dashboards
Warming charts alone leaves a gap. A dashboard with native filters first loads the option lists for each filter, such as a region picker or a date-range dropdown, and only then renders its charts. If those option queries are cold, the first view feels slow even when every chart result is already cached. Treat filter options as part of the warmup scope, not as a side effect of warming charts. In your warmup plan, list each dashboard's native filters, note which ones populate from a dataset query (value lists) rather than from fixed values, and confirm that the warmup run exercises those queries under the executor user. Filters with unbounded value lists, such as customer names, deserve particular attention because their option queries can be the most expensive part of the page.
The executor user decides what gets cached, so the check that matters most is whether warmed filter values match what real users see. Cache entries are keyed to the context in which the query ran, including the user's permissions. Confirm in staging that CACHE_WARMUP_EXECUTORS points to a service account whose row level security and dataset access match the audience for each dashboard. Then compare a warmed filter list against the list a test user with the same roles gets from a cold load. Check for missing values, values hidden by row level security, and stale lists after a data load. Confirm the exact behavior of your Superset version against UPDATING.md before relying on it, since warmup handling has changed between releases.
Warming filter options also adds warehouse load, and that cost repeats on every warmup run. Each dashboard's filter queries run again whenever the cache is refreshed, so a dashboard with many high-cardinality filters can multiply query volume quickly. In staging, measure how many filter queries a single warmup pass issues and how many of them return results that users actually select. Ask the warehouse team to confirm that the executor role's query limits and any cost controls cover these runs. If a filter is rarely used, leaving it cold is often the better trade, and the first load will be slower for only the users who need it.
The warehouse cost of warming too much
Cache warmup moves query cost from the moment a user opens a dashboard to the moment a schedule runs. Warming too much turns idle dashboards and broad filter combinations into recurring warehouse spend, often with no one watching the bill.
Warming dashboards nobody opens
A warmup schedule keeps running for every dashboard on its list, including ones whose audience has moved on or never adopted them. Each run sends the full chart query set to the warehouse and stores results nobody reads. Before you add a dashboard to warmup, check its view count in Superset's usage data and confirm an owner who needs it fresh. Measure the query count per dashboard run against the warehouse usage history for the same service account.
Broad filters that multiply queries
Native filters with many options, or warmup runs that iterate over every filter value, multiply the chart queries behind a single dashboard. A filter with hundreds of values can turn one dashboard into hundreds of warmed result sets. Limit warmed filter combinations to the defaults and the values people actually select. Compare query counts per warmup run before and after you change the filter scope.
Overlapping schedules on one warehouse
Several warmup schedules that start at the same minute, or that overlap with scheduled reports, alerts and refreshes, create bursts of concurrent queries against the same warehouse. Those bursts can hit concurrency limits, queue user queries and slow the dashboards you were trying to speed up. Stagger schedules by dashboard group and check the Celery beat schedule for conflicts. Review warehouse query concurrency graphs during each warmup window.
Expiry shorter than the warmup interval
If cached results expire before the next warmup run, users arrive to cold caches and the warmup spend buys little. The opposite mismatch also happens: a long expiry keeps stale data on screen after the source tables refresh. Set the cache timeout for each dataset or chart to cover the gap between the warmup run and the data refresh, and confirm it against your pipeline schedule. Track cache hit rates for warmed dashboards after each change.
Cost on pay-per-query engines
On engines billed by bytes scanned or queries run, every warmed query is a charge, even when no one opens the dashboard. Warming a wide dashboard each hour on a scan-billed engine can cost more than the interactive traffic it was meant to serve. Ask your warehouse vendor which billing model applies to your account and whether the service account is charged separately. Compare the bill for warmup queries, tagged by service account or query label, before and after warmup goes live.
Setting up cache warmup in order
This sequence moves a Superset instance from a working cache and worker stack to a scheduled warmup job that fills the cache for chosen dashboards before the morning rush. Each step ends with a check you can run, so a failed step is caught before it reaches users or the warehouse.
Confirm Redis and Celery are running
Your platform or infrastructure team confirms that the caching layer, a Celery worker and a Celery beat process are all running and can reach each other and the metadata database. Warmup depends on these components, and the Superset architecture documentation lists the caching layer and worker processes as the pieces that alerts, reports, async queries and thumbnails also need. The step is done when the worker logs show it connected to the broker, and beat is running as a single scheduler. Confirm that only one beat process is active, because duplicate schedulers will queue duplicate warmup runs.
Create a dedicated warmup user
A Superset administrator creates a separate service account for warmup, with the read-only roles and row level security filters that match the audience of the dashboards being warmed. Do not reuse a personal account or an administrator account, because the cache stores results under the executing user's permissions. The step is done when logging in as that account shows only the intended dashboards and datasets, and a test query against a restricted dataset is denied. Ask your security team to review the account against your access model before it is used.
Set the cache warmup executor
The platform engineer sets CACHE_WARMUP_EXECUTORS in superset_config.py so that warmup runs as the dedicated account. Superset 5.0.0 added this setting to control which user performs cache warmup, so confirm the version you run supports it before relying on it. The step is done when a manual warmup run for one dashboard completes in the worker log under the warmup account, not under an administrator or an owner account.
Choose the dashboards to warm
The business owner and the Superset administrator agree on a short list of dashboards that many users open at the same time, such as a daily operations view or a leadership summary. Include the native filter defaults that most viewers use, because warming can also pre-compute filter option lists. Keep the list short and review it against usage data, since every chart on every listed dashboard adds warehouse queries on each run. The step is done when the list is written down with an owner for each dashboard and the filter combinations to warm.
Schedule the warmup task with beat
The platform engineer adds a Celery beat schedule entry that runs the warmup task for the chosen dashboards at a time before users typically log in. Pick a schedule that finishes before the expected peak, and confirm the cache timeouts for those charts are longer than the gap between runs. The step is done when beat logs show the scheduled task being sent and the worker log shows it starting and finishing without errors.
Verify cache hits and warehouse query counts
After one scheduled run, the operator opens a warmed dashboard as a normal viewer and checks that the charts load from the cache rather than the warehouse. Compare the warehouse query history for the warmup window with the query count from a normal day, and confirm that the number of queries matches the charts you listed. If the count is far higher than expected, reduce the dashboard list or the filter combinations before the next run. The step is done when the cache hit behavior and query counts are recorded as the baseline for future changes.
Security and operational considerations for warmup
Cache warmup runs unattended, under a service identity, against your warehouse with credentials the web tier never sees. The cards below cover the decisions that keep warmup from exposing data, leaking secrets, duplicating work or breaking after an upgrade.
Warmup account data access
Warmup runs queries as a designated executor user, so the chart results it caches reflect what that user can see. Choose an account whose row level security and dataset permissions match the audience of each dashboard you warm, and avoid a broad admin account. Confirm that cached results are never served to users whose access differs from the executor's, and test this with two accounts before enabling warmup at scale.
Warehouse credentials in workers
Warmup workers open database connections, so the warehouse credentials must exist in the worker environment as well as the web tier. Inject them from your secrets manager at runtime rather than writing them into superset_config.py or image layers. Restrict the database role to read-only access on the schemas that warmup queries, and rotate those credentials on the same schedule as your other service accounts.
One beat scheduler only
Celery beat fires scheduled warmup tasks, and running more than one beat process causes each warmup to fire multiple times. Each duplicate run multiplies warehouse queries and can cause cache writes to race. Run exactly one beat instance, and on Kubernetes make sure replica settings and restarts cannot start a second one. Verify the schedule in worker logs after any deployment change.
Logging warmup activity
Warmup tasks run without a user clicking anything, so failures are easy to miss. Log each warmup run with its dashboard, executor account, start and end times, and query outcome, and send those logs to the same platform you use for web and worker logs. Alert on repeated failures and on runs that take much longer than their previous runs, since both often point to a warehouse problem or an expired credential.
Upgrade checks for warmup
Changes to cache settings, the warmup executor configuration or Celery task behavior can arrive in a Superset upgrade. Before each version change, read UPDATING.md for breaking changes that touch caching or async workers, and then run warmup against a staging copy of your configuration. Keep your configuration in version control so that a diff shows exactly which warmup and cache keys changed between releases.
Questions teams ask before warming the cache
What does Superset cache warmup cost and what drives that cost?
Warmup costs warehouse compute and worker time, not a Superset license, since Superset is Apache-2.0 licensed with no paid edition. Each warmed chart runs its query against your warehouse on every warmup cycle, so cost scales with the number of dashboards, charts, filter combinations and how often the cache timeout expires. Warehouses that bill per query or per scanned byte, such as BigQuery or Athena, make this cost visible on each run. Ask any partner for a quote that lists the dashboards in scope, the warmup schedule, the Celery worker capacity needed, and the warehouse billing model, along with a plan for what is one-time setup and what recurs.
How long does Superset cache warmup setup take?
Duration depends on your environment more than on Superset itself. The main variables are how many dashboards you want warmed, whether Celery workers and a beat scheduler already run, which cache backend and metadata database you use, and how many warehouse connections need credentials and permissions. Teams with an existing Redis cache and working Celery workers usually have less to build than teams starting from a SQLite or PyPI install, which the Superset architecture documentation does not recommend for production. Ask for a timeline in the written scope, and confirm the prerequisites in your own environment before agreeing dates.
What do we need from our team to warm the cache?
The work needs decisions and access from your side. You should provide the list of dashboards that matter to users, the owners who can confirm which filter values and tabs people actually use, and a dedicated warehouse account for the executor user. Your data platform team needs to approve the query load and any row or cost limits. Your platform team owns the Redis cache, Celery workers, the beat scheduler and the staging environment where changes are tested. Make sure these owners are named in the scope so testing and sign-off do not stall late in the project.
Can our own team set up Superset cache warmup without a partner?
Yes, if your team already runs Superset with Celery workers and a cache backend and has someone who understands the warehouse query plans behind your dashboards. The configuration itself is not the hard part. The harder work is choosing dashboards, scoping the executor user's permissions, and tuning the schedule against warehouse cost and concurrency limits. A partner is useful when you need an external review, a tested runbook, or help running warmup across several environments. Compare the internal effort with a fixed-scope quote before deciding, and confirm that your team can maintain the schedule after go-live.
How do we choose which dashboards to warm first?
Start with dashboards that many people open at the start of the day, that run expensive queries, and that do not change every few minutes. Usage data from Superset's logs and your warehouse query history shows which dashboards and filter combinations are popular. Warm the default filter state that most users see, and avoid warming every native filter option, because each combination multiplies warehouse queries. Dashboards that depend on real-time data or per-user row level security need a separate decision, since a shared cache entry may not match what each user is allowed to see. Review the list with dashboard owners before each change.
How do we confirm warmup is not overloading the warehouse?
Measure before and after each warmup change. Track the number of queries, concurrency, bytes scanned or compute time, and failed or slow warmup tasks during the warmup window, and compare them with the same period without warmup. Set a concurrency limit for Celery workers and a per-run query budget, and confirm that the executor account has only the permissions it needs. Your warehouse's query history and cost reports are the source of truth. Test the schedule in staging first, as the Superset upgrade documentation recommends for changes, and agree written thresholds that trigger a schedule review.
Which Superset user should run cache warmup, and why does it matter?
Warmup runs under an executor user, and Superset 5.0.0 added the CACHE_WARMUP_EXECUTORS setting to control which user that is. The executor determines which dataset and row level security rules apply to cached results, so a user with broad access can populate caches that others may see. Use a dedicated service account with read-only access to the datasets being warmed, and review its permissions whenever dashboards change. Confirm the exact behavior for your Superset version in the UPDATING notes before you rely on it.
How DeployOpen scopes and supports cache warmup
DeployOpen plans, implements, documents and supports self-hosted Apache Superset inside your own infrastructure, including cache warmup for the dashboards your users open first. The work starts with a written scope that names the dashboards, the executor account, the warehouse impact and the schedule before any task is configured.
How we scope
- Inventory the dashboards, native filters and users whose first load should be warm, and record which ones can tolerate stale data.
- Agree in writing which warmup strategies apply, the schedule for each one, and the warehouse capacity the warmup may consume.
- Confirm the dedicated executor account, its database role and the row level security it inherits before any warmup task is written.
How we build
- Configure the Celery beat schedule and worker queues that run warmup tasks, with the metadata database and Redis cache sized for the agreed scope.
- Set CACHE_WARMUP_EXECUTORS so warmup runs as the intended account, then test that cached results match what each audience sees.
- Measure warehouse query volume during a staged warmup run in a non-production environment, then adjust dashboard and schedule scope before go-live.
How we hand over
- Document the warmup task list, schedule, executor configuration, cache timeouts and the process for adding or retiring dashboards.
- Walk your platform and data team through the warehouse cost signals to watch and the settings that reduce warmup load.
- Provide a runbook for failed warmup runs, Redis outages and upgrade checks against UPDATING.md before each Superset version change.
How we support
- Engagements are fixed-scope, and the written scope defines what is delivered and when acceptance applies.
- Ongoing support, upgrades and warmup reviews as dashboards change are available as a retainer.
- Ask any partner to confirm how warmup behavior is verified after each Superset upgrade in your own environment before you rely on it.
