Proof
One million entries on a $50 stick.
Measured 2026-08-13 · Amazon Fire TV (Fire OS 7, Android 11) · production import path
Most players are demoed against tidy 500-channel lists. Real provider playlists run to six and seven figures, so we benchmarked the real thing: a 1,000,000+ entry import, end to end, on the cheapest hardware we support daily. These are the honest numbers — including the slow ones.
Import (one-time cost per full sync)
| Stage | Time | Throughput |
|---|---|---|
| Landing (parse + stage all entries) | 5.8 min | 2,857 rows/s |
| Atomic publish (library swap — old library stays usable until the instant the new one is complete) | 59.4 min | 280 rows/s |
| Canonical graph (dedupe + title matching across sources) | 180 min | 92 rows/s |
| Total, cold | ~4.1 h | 994 MB database |
Yes, four hours is a long time — for a library roughly 20× larger than the largest real-world provider list we’ve seen. The point of the benchmark is the other column: nothing crashed, nothing corrupted, and the library stayed watchable throughout, on a stick. (Typical real playlists of 50–100k entries import in minutes.)
Once imported (what daily use feels like)
| Operation | Measured |
|---|---|
| Scrolling the library (two-page paged read) | 303 ms |
| All sources for a title (failover lookup) | 20 ms |
| Full-text search query | 227 ms |
What the benchmark caught
Publishing benchmarks is only worth doing if the bad news ships too: this run surfaced a real bug — full-text search returned zero matches on a freshly imported library until its first refresh — plus two optimization leads (index handling during the publish stage, and running ANALYZE after bulk import). The bug has a committed reproduction test and is being fixed; this page will say so when it is.
Reproducing it
The benchmark is code in the repository (LibraryScaleBenchmark), run against a generated 1M-entry playlist via adb on stock hardware — not a lab rig. Numbers above are from the single recorded run on the date shown.