Reflex vs Streamlit: NBA dashboard benchmark
Measured June 3, 2026. Summary prepared September 17, 2026.
This report summarizes the Reflex and Streamlit results from Reflex's supplied internal report, NBA Data App, Production Performance. It compares two implementations of the same NBA data application, with different rendering and compression configurations. It is not an independent benchmark or a measurement of every application built with either framework.
Time until the player table is visible
Time to visible data is max(first contentful paint, table rows entering the DOM). Lower is better. These are median cold-cache measurements, not time to full interactivity.
| Network profile | Reflex | Streamlit | Cold runs |
|---|---|---|---|
| Local | 436 ms | 681 ms | 7 |
| Cable | 484 ms | 1,727 ms | 5 |
| Simulated slow 4G | 2,132 ms | 15,556 ms | 3 |
Measurement setup
Source: NBA Data App, Production Performance, June 3, 2026. Production-mode apps on one Linux workstation, measured in Chromium with a cold browser cache. Values are medians of 7 local, 5 cable, and 3 slow-4G runs. Cable: 20/5 Mbps and 28 ms RTT. Slow 4G: 1.6/0.75 Mbps, 150 ms RTT, and 4x CPU slowdown. Time to visible data is the later of first contentful paint and table rows entering the DOM.
The supplied report identifies Chromium 147 via Playwright and Node 24.13. Reflex ran with reflex run --env prod; Streamlit ran headless. Network conditions were simulated locally. The report notes roughly 80 ms of timing variation between runs; it does not provide confidence intervals.
What explains the difference in this test?
The Reflex implementation prerendered the first page of the table into its HTML. The Streamlit implementation delivered its data after frontend startup. The measured Reflex branch also included a Radix vendor-chunk tree-shaking fix and font head preloading. These implementation choices affect initial visibility; the measurements do not isolate a universal framework effect.
Reflex served compressed JavaScript and CSS, while the measured Streamlit setup served uncompressed JavaScript. This difference matters under bandwidth throttling. The reported timings are not a compression-matched comparison.
Memory and interaction limits
| Measure | Reflex | Streamlit |
|---|---|---|
| Idle server PSS | 327 MB | 175 MB |
| Reported memory growth per held session | 0.40 MB | Approximately 0 MB |
PSS is proportional set size across each server's process tree. Session memory was measured separately with 25 concurrent held sessions. Approximately zero is the report's rounded observation, not a claim that Streamlit sessions never use memory. Held-session measurements do not establish request throughput or maximum supported concurrency.
The report did not measure Streamlit's filtering latency. These results therefore cannot establish which implementation has faster interactive filtering.
Versions, limitations, and reproducibility
These supplied results have not been independently reproduced. Caveats:
-
Reflex 0.9.3.post14.dev0 included branch-specific tree-shaking and font-preload changes. The report lists Streamlit's version only as 1.32 or later, without an exact version number.
-
The Reflex app prerendered its first table page.
-
Compression settings differed, so this is not a comparison at compression parity.
-
Initial visibility does not measure full interactivity or throughput. Streamlit filtering latency was not measured.
-
Reflex used more idle server memory (327 MB versus 175 MB PSS) and more memory per held session.
Results depend on the implementation and environment.
The source report references an application specification, a measurement harness, and raw JSON results. Those artifacts were not supplied with the report and are not included here. An exact Streamlit version, source snapshots, dependency locks, and those measurement artifacts would be needed to independently reproduce this comparison. This summary preserves the reported values; no new performance measurements were run for it.