Performance

Ten thousand pods scroll like ten.

A cluster you actually operate has thousands of objects and a dozen controllers rewriting them. The list you are looking at has to stay honest without turning the window into a JSON firehose.

From the API server to the pixels

Shared, incremental watchers

Every view of a kind reads one watcher. Opening a second tab on the same resource costs nothing, and switching namespace filters the stream instead of refetching it. electron main · @kubernetes/client-node

Lean projections, lazy detail

A row carries the fields its columns need. The full object is fetched when you open it, so a ten-thousand-pod list is megabytes, not hundreds. electron/k8s/kinds.ts · one row per kind

A scheduler that keeps draining

Updates are applied on a frame budget, and the queue keeps draining when the window is in the background — so a busy cluster never leaves you with a stale table. TanStack Virtual · Svelte 5 runes

What you feel

Opening a 10,000-row tablescrolls at once, no spinner wall

Switching contextno reload, the window stays put

Two tabs on the same kindone watch, one stream

A controller rewriting 200 podsone repaint per frame, not 200

Window in the backgroundqueue keeps draining

Coming back after lunchwatch resumes from its resourceVersion

Measured in the repo, not on this page kdashboard ships a Playwright benchmark harness: mount, scroll frame cost, filter and update latency, and retained heap, at 200, 2,000 and 10,000 rows. Run it and get your own numbers — we would rather you did that than trust a chart on a marketing page.

$ bun run benchmark

scripts/bench

The events feed, one of the busiest views in the app

The events view: a live kubectl-style feed — Events · a live, kubectl-style feed that keeps up with a noisy namespace

Try it on your biggest cluster first. That is the one that tells you something.

Resource tables guide → Architecture → Download