<article class="blog-post">The complaint arrives as &#8220;the dashboard is slow&#8221;, and the first instinct is to look at the database. Check the query time in Superset&#8217;s chart data response and it is often under a second. The other nine seconds are in the browser: parsing the response, transforming it, and drawing a hundred thousand DOM nodes.Custom plugins are especially prone to this because they are written against a sample dataset and shipped before anyone tries them on the real one. (If you have not built one yet, start with <a href="https://www.andolasoft.com/blog/how-to-build-a-custom-chart-plugin-for-apache-superset" target="_blank" rel="noopener">how to build a custom chart plugin for Apache Superset</a>; this post assumes that structure.) This post is about finding where the time goes and fixing it, in the order that gives the most improvement for the least rework.</p>
<h2>Where the time goes</h2>
<p>A chart render in Superset has five stages. Each can be the bottleneck, and the fix for each is different.</p>
<div class="table-responsive">
<table>
<thead>
<tr>
<th>Stage</th>
<th>Where it runs</th>
<th>What makes it slow</th>
</tr>
</thead>
<tbody>
<tr>
<td>Query</td>
<td>Database</td>
<td>Missing indexes, no aggregation, huge row limits</td>
</tr>
<tr>
<td>Transfer</td>
<td>Network</td>
<td>Large JSON payloads, no compression</td>
</tr>
<tr>
<td>Transform</td>
<td>Browser, <code>transformProps</code></td>
<td>Per-row work, sorting, string building, repeated parsing</td>
</tr>
<tr>
<td>Render</td>
<td>Browser, your component</td>
<td>SVG node count, layout thrash, re-rendering on every prop</td>
</tr>
<tr>
<td>Interaction</td>
<td>Browser</td>
<td>Tooltips and hover on thousands of elements, cross-filter round trips</td>
</tr>
</tbody>
</table>
</div>
<p>Measure before you change anything. Three tools give you the whole picture:</p>
<ul>
<li><strong>Superset&#8217;s own timing.</strong> Open the chart in Explore, use &#8220;View query&#8221; and &#8220;View as table&#8221; to see row counts, and check the network tab for the <code>/api/v1/chart/data</code> response time and size.</li>
<li><strong>Chrome Performance panel.</strong> Record a dashboard load and look at the flame chart. Long yellow blocks under your plugin&#8217;s function names are transform time; long purple and green blocks are layout and paint.</li>
<li><strong>React Profiler.</strong> Shows how many times your component rendered and why. A chart that renders four times per load is doing four times the work.</li>
</ul>
<p>Write down the numbers. Ninety per cent of the time one stage dominates, and it is usually transform or render.</p>
<h2>Fix 1: Do not fetch what you will not draw</h2>
<p>A chart 900 pixels wide cannot display 100,000 distinct points. If the plugin fetches them anyway, every downstream stage pays for it. The right place to fix this is <code>buildQuery</code>, because it is the only stage where the database does the work.</p>
<p><strong>Aggregate.</strong> If the chart shows a value per category, group by the category. If it shows a time series, apply a time grain. <code>buildQueryContext</code> does this from the standard controls; make sure the plugin&#8217;s controls expose them rather than pulling raw rows.</p>
<p><strong>Limit series, not just rows.</strong> For multi-series charts, <code>series_limit</code> and <code>series_limit_metric</code> keep the top N series and drop the tail that nobody can read anyway.</p>
<p><strong>Set a sensible `row_limit`.</strong> The default row limit is often far higher than any chart needs. A row limit control with a default matched to the chart&#8217;s capacity protects users from themselves.</p>
<p><strong>Use server-side post-processing.</strong> Superset&#8217;s query object accepts a <code>post_processing</code> list of pandas operations that run on the backend after the query: <code>pivot</code>, <code>aggregate</code>, <code>rolling</code>, <code>resample</code>, <code>cum</code>, <code>contribution</code>, <code>sort</code>, <code>rename</code>, <code>flatten</code>. Rolling averages, pivots for a heatmap, and percentage-of-total calculations belong here, not in <code>transformProps</code>:</p>
<div class="code-block">
<div class="code-header">typescript</div>
<pre><code class="language-typescript">return buildQueryContext(formData, baseQueryObject =&gt; [
  {
    ...baseQueryObject,
    post_processing: [
      {
        operation: 'pivot',
        options: {
          index: ['__timestamp'],
          columns: formData.groupby,
          aggregates: { [metricLabel]: { operator: 'mean' } },
        },
      },
      {
        operation: 'rolling',
        options: { rolling_type: 'mean', window: 7, min_periods: 1, columns: { [metricLabel]: metricLabel } },
      },
    ],
  },
]);</code></pre>
</div>
<p>The payload that reaches the browser is already in the shape the chart needs. This one change often removes the transform stage entirely.</p>
<h2>Fix 2: Keep transformProps cheap and pure</h2>
<p><code>transformProps</code> runs on every render trigger, which means every time the user touches a cosmetic control. Anything expensive in it is paid repeatedly.</p>
<ul>
<li><strong>No per-row string formatting.</strong> Format values at draw time for the visible elements, or in the tooltip, not for every row up front.</li>
<li><strong>No sorting of large arrays</strong> if the query can return them sorted (<code>orderby</code> in <code>buildQuery</code>).</li>
<li><strong>No nested loops.</strong> Building a lookup map once and indexing into it is O(n); the nested <code>find</code> is O(n²) and 100,000 rows makes that ten billion operations.</li>
<li><strong>Return plain data, not React elements.</strong> Keep <code>transformProps</code> framework-free so it is cheap to test and impossible to accidentally allocate components in.</li>
</ul>
<p>A useful guardrail is a unit test that runs <code>transformProps</code> on a 100,000-row fixture and asserts it completes under a threshold. It fails the moment someone adds a quadratic step.</p>
<h2>Fix 3: Choose the rendering technology for the data size</h2>
<p>This is the change people reach for first, and it is the third most effective, because the first two usually make it unnecessary. When it is necessary, the guidance is simple.</p>
<p><strong>SVG</strong> is fine up to a few thousand elements. Each element is a DOM node with layout, style and event handling. Past roughly 5,000 to 10,000 nodes the page becomes sluggish regardless of how well the code is written.</p>
<p><strong>Canvas</strong> draws pixels, not nodes, and handles hundreds of thousands of points. ECharts, which Superset&#8217;s own charts use, renders to canvas by default. If your plugin wraps ECharts, three options matter for large data:</p>
<div class="code-block">
<div class="code-header">typescript</div>
<pre><code class="language-typescript">series: [{
  type: 'line',
  sampling: 'lttb',      // downsample to the visible pixel width while preserving shape
  large: true,           // enable large-data mode for bar and scatter
  largeThreshold: 2000,
  progressive: 4000,     // render in chunks so the UI stays responsive
  progressiveThreshold: 10000,
  data,
}]</code></pre>
</div>
<p><code>sampling: 'lttb'</code> (largest triangle three buckets) is the single most valuable one for time series: it reduces a 100,000-point line to the number of pixels available without losing peaks and troughs.</p>
<p><strong>WebGL</strong> through deck.gl is for the cases canvas cannot handle: millions of points, geospatial layers, 3D. Superset ships deck.gl plugins, and the <a href="https://www.andolasoft.com/guides/patrol-analytics-with-superset" target="_blank" rel="noopener">patrol analytics guide</a> shows the pattern in a real deployment. The cost is complexity and a harder testing story, so reach for it only when the data justifies it.</p>
<style>
.as-inline-cta{display:flex;align-items:stretch;border-radius:14px;overflow:hidden;<br />background:#eaf4f6;border:1px solid #dee7ea;margin:32px 0}<br />.as-inline-cta__icon{flex:0 0 128px;background-color:#1aa9ca;<br />background-image:radial-gradient(rgba(255,255,255,.35) 1.4px,transparent 1.4px);<br />background-size:11px 11px;display:flex;align-items:center;justify-content:center;padding:20px}<br />.as-inline-cta__icon span{width:64px;height:64px;border-radius:50%;background:#fff;<br />display:flex;align-items:center;justify-content:center;box-shadow:0 2px 6px rgba(0,0,0,.12)}<br />.as-inline-cta__icon svg{width:28px;height:28px;stroke:#0f7f9c;fill:none;stroke-width:2;<br />stroke-linecap:round;stroke-linejoin:round}<br />.as-inline-cta__body{padding:22px 28px;display:flex;flex-direction:column;justify-content:center;gap:8px}<br />.as-inline-cta__body h4{font-size:19px;font-weight:700;color:#1e2246;margin:0}<br />.as-inline-cta__body p{font-size:14.5px;line-height:1.6;color:#45506b;margin:0;max-width:52ch}<br />.as-inline-cta__link{display:inline-flex;align-items:center;gap:5px;font-size:14.5px;<br />font-weight:700;color:#0f7f9c;text-decoration:none;width:max-content}<br />.as-inline-cta__link svg{width:16px;height:16px;stroke:currentColor;fill:none;stroke-width:2.4;<br />stroke-linecap:round;stroke-linejoin:round}<br />.as-inline-cta__link:hover{text-decoration:underline}<br />@media (max-width:560px){.as-inline-cta{flex-direction:column}<br />.as-inline-cta__icon{flex:0 0 auto;width:100%;padding:16px 0}}<br /></style>
<div class="as-inline-cta">
<div class="as-inline-cta__icon"></div>
<div class="as-inline-cta__body">
<h4>Applied these and it&#8217;s still slow at your row counts?</h4>
<p>Some performance ceilings are architectural, not fixable with these seven changes alone. A Plugin Scoping Call looks at your specific dataset shape and rendering approach.</p>
<p><a class="as-inline-cta__link" href="https://www.andolasoft.com/what-we-do/superset-plugin-scoping" target="_blank" rel="noopener">Book a Plugin Scoping Call</a></p>
</div>
</div>
<h2>Fix 4: Virtualise tables and lists</h2>
<p>Table-style plugins are a special case. Users expect to see every row, so aggregation is not an option, but rendering 100,000 table rows as DOM nodes is exactly the SVG problem in a different costume.</p>
<p>The fix is virtualisation: render only the rows in the viewport plus a small buffer, and swap them as the user scrolls. <code>react-window</code> and <code>@tanstack/react-virtual</code> both do this well. Superset&#8217;s own table chart also supports server-side pagination, where each page is a separate query; that is the better choice when the dataset is large enough that even transferring it is slow.</p>
<h2>Fix 5: Stop re-rendering</h2>
<p>The React Profiler often shows a chart rendering several times per dashboard load: once with empty data, once with data, once when the dashboard finishes laying out, once when a filter indicator updates. Each render repeats any work not memoised.</p>
<ul>
<li>Wrap expensive derived values in <code>useMemo</code> keyed on the data reference and the relevant props.</li>
<li>Memoise the component with <code>React.memo</code> if its props are stable.</li>
<li>For ECharts, call <code>setOption</code> with <code>notMerge: false</code> and update only the series that changed, rather than recreating the instance.</li>
<li>Make sure <code>transformProps</code> returns the same object references for unchanged data. A new array on every call defeats memoisation downstream.</li>
</ul>
<h2>Fix 6: Make interaction cheap</h2>
<p>Tooltips that recompute on every mouse move, hover highlighting that touches every element, and cross-filter emissions that fire on drag are all ways to make a fast chart feel slow.</p>
<ul>
<li>Throttle hover handlers to animation frames.</li>
<li>For canvas charts, use the library&#8217;s built-in hit testing rather than your own.</li>
<li>Emit cross-filters on click or on the end of a brush, not continuously.</li>
</ul>
<h2>Fix 7: Let long queries run asynchronously</h2>
<p>When the database stage genuinely is slow, the dashboard should not freeze waiting for it. Superset&#8217;s global async queries feature runs chart queries through Celery workers and lets the browser poll or receive the result over a websocket. The dashboard renders immediately with loading states, and charts fill in as their data arrives. This is a deployment change (<code>GLOBAL_ASYNC_QUERIES</code> feature flag, Redis, Celery workers) rather than a plugin change, but plugin authors should test that their chart handles the loading and error states it produces.</p>
<p>Async queries do not make a slow query fast. They make a slow query stop blocking everything else. Pair them with caching and query tuning, which is a platform question covered in our production operations guide and in the <a href="https://www.andolasoft.com/what-we-do/superset-architecture-review" target="_blank" rel="noopener">Architecture Review</a>.</p>
<h2>A worked order of operations</h2>
<p>Faced with a plugin that takes nine seconds on 100,000 rows:</p>
<ul>
<li>Measure. Say the query is 0.8 s, transfer 0.6 s, transform 3.1 s, render 4.2 s.</li>
<li>Move aggregation and the rolling calculation into <code>buildQuery</code> with post-processing. Rows drop to 8,000. Transfer is now 0.1 s, transform 0.3 s, render 1.9 s.</li>
<li>Switch the SVG line to ECharts canvas with LTTB sampling. Render drops to 0.2 s.</li>
<li>Add <code>useMemo</code> around the option object. Renders per load drop from four to one.</li>
</ul>
<p>Total: under two seconds, and most of it is the database. No WebGL, no virtualisation, no heroics. That is the usual shape of these fixes: the first two steps do most of the work.</p>
<h2>Frequently Asked Questions</h2>
<h3>How many rows can a Superset chart plugin handle before it gets slow?</h3>
<p>It depends on what you render with, not on Superset. SVG is comfortable up to a few thousand elements, because each one is a DOM node with layout, style and event handling, and becomes sluggish somewhere past five to ten thousand nodes however well the code is written. Canvas draws pixels rather than nodes and handles hundreds of thousands of points; WebGL through deck.gl goes further again, at the cost of complexity. Match the technology to the expected row count before writing the plugin.</p>
<h3>Should aggregation happen in the browser or in the query?</h3>
<p>In the query, nearly always. Aggregating by category, applying a time grain, setting a realistic <code>row_limit</code>, and limiting the number of series with <code>series_limit</code> all keep rows from being fetched at all. Rolling averages, pivots and percentage-of-total belong in the query object&#8217;s <code>post_processing</code> list, which runs on the backend, rather than in <code>transformProps</code>. The fastest transform is the one that has less data to transform.</p>
<h3>Why does my chart render several times on every dashboard load?</h3>
<p>Usually because a prop identity changes on each render, so memoisation never holds. The React Profiler shows the render count and the reason. A chart that renders four times per load does four times the transform and paint work, which is why re-render control often buys more than micro-optimising the transform itself.</p>
<h3>What should <code>transformProps</code> avoid doing?</h3>
<p>Per-row string formatting, sorting large arrays that the query could have returned sorted through <code>orderby</code>, nested loops, and allocating React elements. A nested <code>find</code> inside a loop is O(n squared), which at 100,000 rows is ten billion operations; building a lookup map once and indexing into it is O(n). Keep the function plain-data-in, plain-data-out and it stays cheap and testable.</p>
<h2>Build It With Andolasoft</h2>
<p>Performance is much cheaper to design in than to retrofit. When we scope a plugin, expected row counts and interaction patterns are part of the conversation, and they decide the rendering approach before any code is written. If you have a chart in mind, or one that has started to struggle, our <a href="https://www.andolasoft.com/what-we-do/superset-plugin-scoping" target="_blank" rel="noopener">Plugin Scoping Call</a> is free and 45 minutes, and the written estimate you get afterwards will say which of the approaches above the design needs. Where the bottleneck turns out to be the platform rather than the plugin, that is the territory of a <a href="https://www.andolasoft.com/what-we-do/superset-architecture-review" target="_blank" rel="noopener">Superset Architecture Review</a>.</p>
<p>If a dashboard in front of real users is freezing and you need to know whether the fix is the plugin, the query or the deployment, <a href="https://www.andolasoft.com/contact-us" target="_blank" rel="noopener">talk to us</a>. We will profile a real load and tell you which of the three it is before anyone commits engineering time.</p>
</article>


Superset Plugin Performance: Rendering 100k-Row Datasets Without Freezing the Dashboard

Table of Contents

Related Articles

For Sales