How I stopped Redis GUIs from freezing on 10M+ keys

#redis #devtools #performance #gui

Production Redis with tens of millions of keys. Open a GUI → freeze, RAM spike, or crash. Open a large hash/zset → the same freeze if the client tries to load every member at once.

I hit this enough times that I rebuilt the loading path. The result is RedisViewer, a local Redis desktop client built first for developers: load the keys you asked for, keep the UI virtualized, and confirm before touching large production databases.

Loading vs rendering

Most Redis GUIs mix two problems together: how keys are fetched, and how every row is painted.

RedisViewer splits them:

Load what you asked for. Via ScanConfig (default pattern *), it uses Redis SCAN and loads the full target key set. That is the R&D-friendly path — see the whole filtered result without endless "load more."
Confirm on large DBs. If DBSIZE ≥ 100,000 (configurable; "SCAN skip confirm"), it asks before loading.
Never render what you can't see. The key list is virtualized, so a large result set does not mean millions of UI nodes.

Large hashes / sets / zsets are separate: members load in chunks, so a fat collection does not freeze the window with one full dump.

Core bet: smooth browsing on huge instances, without a huge memory bill — full target load for debugging, safety gate for production-sized DBs, virtualized UI either way.

Value debugging for Java stacks

If you run Java services, Redis values are often not plain strings:

Java JDK serialization — open serialized objects without a one-off decoder
Escape / control characters — see and edit translated/escaped bytes visually
Jackson / Fastjson polymorphic JSON — inspect and edit structured polymorphic JSON