DEV Community: hepengju

I Rebuilt a Redis GUI on Tauri. The Installer Is 7.9 MB. Here's What It Cost Me.

hepengju — Sat, 31 Oct 2026 14:38:14 +0000

I keep three Redis GUIs installed: Another Redis Desktop Manager, TinyRDM, and the official RedisInsight. Two of the three are Electron, and those are the heavy ones: ARDM's Windows installer is 59 MB and it sits at 230 MB RSS on my machine once connected; the official RedisInsight is Electron too — its Windows installer is 110 MB. TinyRDM, which uses the system WebView just like Tauri does (Wails and Go), needs only 13 MB. The gap between those lines is what this post is about: not WebView versus no WebView, but bundling Chromium versus not.

You do not have to take my word for any of it. Installer sizes are straight from each project's GitHub Releases asset list (Windows x64, latest version at the time of writing):

Client	Framework	Installer (Windows x64)	Version
RedisME	Tauri (system WebView)	7.9 MB	v5.6.0, 2026-10
TinyRDM	Wails (system WebView)	13 MB	v1.2.7, 2026-03
Another Redis Desktop Manager	Electron	59 MB	v1.7.4, 2026-08
RedisInsight	Electron	110 MB	3.8.0, 2026-07

On a 32 GB machine where Docker and an IDE already claim their share, that is a bill I got tired of paying.

So I wrote RedisME on Tauri instead. This is the honest version of that decision: what I gained, what it cost, and which numbers you should not trust.

First: Electron's bill is not waste

Electron is large because it bundles an entire Chromium and a Node runtime. That is also its best feature:

Rendering is identical everywhere. Windows, Ubuntu 18.04, CentOS 7 — same pixels. You never think about the host's WebView version.
The ecosystem is mature. Any frontend library, any Node module, works.
Debugging is familiar. DevTools is right there.

For commercial software that must look identical on every customer machine, those guarantees are worth 200 MB.

But a Redis GUI does not need them. It runs on your workstation, next to Docker and an IDE — not on a fleet of customer machines that must render identically. Its interface complexity is a fraction of an IDE's.

When consistency is not your core constraint, the size and memory you pay for it is pure cost.

What Tauri actually changes

Tauri inverts the model: do not bundle a browser, use the one the OS already has.

	Electron	Tauri
Renderer	bundled Chromium	system WebView (WebView2 / WKWebView / WebKitGTK)
Backend	Node.js	Rust
Installer (Windows x64)	59 MB (ARDM v1.7.4) · 110 MB (RedisInsight 3.8.0)	7.9 MB (v5.6.0)
Idle RSS	200 MB+	~100 MB (my machine, one connection)

The installer size is the honest, reproducible win: you are not shipping Chromium, so you do not ship its tens of megabytes. Download the release and check the file size yourself — it is the easiest claim in this article to verify. For the record: the macOS dmg is ~11 MB and the Linux deb ~13 MB. (The Linux AppImage is bigger — it bundles the WebKit libraries so it runs anywhere, which is a different tradeoff.)

I am going to hedge on the memory number, because everyone overstates it. 100 MB is what I measured on Windows, one connection, empty key view. Different OS, different WebView build, larger datasets — all of it moves the number. Do not treat it as a spec sheet.

The difference you feel is cold start. On my machine, double-click to usable is under two seconds — there is no Chromium bootstrap in the way.

What it cost me

This is the part most "Tauri vs Electron" posts skip.

1. Three rendering engines, not one

WebView2 is Chromium. WKWebView is Safari's engine. WebKitGTK is a third thing. The same CSS can behave differently on all three.

Bugs I have personally shipped and fixed because of this: fake-bold and blurry font rendering on Linux (WebKitGTK synthesizes font weights; the fix is a dedicated html[data-platform='linux'] patch with font-synthesis: none and antialiased smoothing — the same workaround Yaak and JetPilot ship), macOS titlebar padding that differs across system versions (new macOS releases have bigger corner radii), and a macOS terminal right-click paste permission error that ended with switching to the Tauri clipboard plugin. None of these are Tauri's fault — they are the direct consequence of "use the system WebView."

If your UI depends on pixel-precise layout and animation, Tauri will eat your schedule in platform adaptation.

2. The build chain is longer

Vue + Element Plus on the front, Rust on the back. Change a line of Rust and you wait for a recompile. Shipping requires the Rust toolchain plus per-platform signing and notarization — macOS notarization in particular is its own afternoon.

For a solo maintainer, the release cadence is partly set by the build pipeline, not just by how fast you code.

3. Linux users must install dependencies

WebKitGTK is not present on every distro. A first run on Linux may mean installing libwebkit2gtk and friends. On Windows, WebView2 is effectively a system component now (bundled on 11, mostly delivered via Edge updates on 10), so it is a non-issue there.

4. Fewer ready-made wheels

In Electron, "show a native file dialog" is one line. In Tauri it is a plugin, and version mismatches are a real failure mode. Small frictions, but they accumulate.

Two UI decisions, and what they cost

Read-only mode deletes the buttons

The alternative is to keep every button and pop a "you are in read-only mode" confirmation. More complete, functionally.

I chose the aggressive version: in read-only mode, every mutating control disappears from the UI. Unlock with the padlock in the top bar.

The reasoning: when you are debugging production, every clickable element is a decision you have to make. "Will clicking this change data?" Removing the buttons removes the question.

The cost is real too: new users take a while to find delete. It is documented, but the muscle memory of "buttons are always there" works against it.

Multiple connections in windows, not tabs

Tabs are more popular and tidier in the taskbar.

I use windows because of one workflow: comparing the same key across two clusters. Two windows sit side by side on two monitors, or split half-and-half. With tabs you switch back and forth and have to remember what the other one showed.

Cost: a messy taskbar. Neither choice is correct — it depends on whether your day is "many operations on one database" or "the same operation across several."

Where this thing is actually differentiated

Three features I would point at, rather than a feature list:

1. Runtime config diff against version defaults. Pull CONFIG GET *, compare against Redis 6/7/8 defaults, highlight the differences. When you are asking "why does this node behave differently from the others," this is the only entry point that works. Cluster config drift is a genuinely nasty failure mode: CONFIG SET applies to one node, a failover happens a year later, and behavior changes.

2. Codecs for non-UTF-8 values, taken past "it decodes". RedisInsight and ARDM both read Java serialization (same library I use), so the difference is the layer after: java.time / records / collections rendered as JSON, per-field codec selection on Hash/List/Set/ZSet, and an external script hook (Python/Node/Java) exposing decode and encode for in-house formats. Your codec logic stays in your repo.

3. Cluster command broadcast and node targeting. In the terminal, CONFIG SET can broadcast to every node or run on one specific node. Cluster operations need both; most clients implement one.

Who should use it, who should not

Good fit: memory-constrained machines, multiple simultaneous connections, internal/production clusters behind SSH tunnels, Java services storing serialized objects, people who care about cold start.

Bad fit: software that must render identically on old customer machines; complex custom UI with heavy animation; single-database CRUD where tabs beat windows; anything needing a Redis module I have not implemented.

That last point deserves emphasis. RedisME has 129 stars. Another Redis Desktop Manager has 34.8K, TinyRDM has 13.1K. On ecosystem maturity, edge-case coverage, and community responsiveness, they are better. That is not modesty, it is a fact you should factor into your choice.

Links

GPL-3.0, fully open source, Windows / macOS / Linux, x64 and arm64.

I am not asking anyone to switch. I am pointing out that if "three GUI windows ate my RAM" is a problem you have, a 7.9 MB option now exists.

Why Your Redis Values Look Like Garbage in Every GUI (and How to Fix It)

hepengju — Sat, 31 Oct 2026 14:05:51 +0000

You connect your Redis GUI to the database your service writes to. You click a key. You get this:

\xac\xed\x00\x05sr\x00\x1dcom.example.order.OrderDetail\x00\x00\x00...

Or, depending on the client, a wall of �.

This is not a bug in Redis and it is not a broken client. It is a serialization problem — and the real problem is not that nobody supports it. Most clients do. RedisInsight has shipped a Java serialized objects formatter since 2.10 (September 2022), Another Redis Desktop Manager has a JavaSerialize viewer, and both use the same library I do (java-object-serialization).

The problem is that the default is still UTF-8, you have to know the feature exists to switch, and what you get after switching differs a lot between clients.

I maintain RedisME, an open-source Redis GUI. This post covers four things: why the bytes look like that, why the usual workarounds hurt, why "supported" and "usable" are different claims, and what to do with formats nobody ships a decoder for.

Redis stores bytes. Types are your client's problem.

RESP is binary-safe. SET foo bar stores three bytes — 0x62 0x61 0x72. GET foo returns those three bytes. Redis has no idea what they mean.

So when a Java service writes an OrderDetail object, what actually happens is:

// Spring Data Redis' default, effectively
RedisSerializer<Object> serializer = new JdkSerializationRedisSerializer();
byte[] bytes = serializer.serialize(orderDetail);

JdkSerializationRedisSerializer goes through ObjectOutputStream, which emits a stream starting with a fixed magic number:

Bytes	Meaning
`0xAC 0xED`	`STREAM_MAGIC`
`0x00 0x05`	`STREAM_VERSION`

That is your \xac\xed\x00\x05. It is a perfectly valid Java serialization stream, and it is an illegal UTF-8 byte sequence. By default, a GUI just decodes as UTF-8:

bytes -> decode as UTF-8 -> fail -> print � or \xNN -> done

That is not laziness. Doing it properly needs format detection, a runtime that can deserialize, and handling for every case where deserialization fails. So the capability is usually built in but off by default — you have to know it exists and remember to switch.

Five serializers, five kinds of garbage

Java teams do not have one way to write objects to Redis. They have at least five, and each produces completely different bytes:

Serializer	Where you see it	What's stored	GUI shows
`JdkSerializationRedisSerializer`	Spring Data Redis default	binary stream, starts `AC ED 00 05`	garbage
`StringRedisSerializer`	manual `toString()` / JSON strings	`{"id":10086,...}`	readable
`Jackson2JsonRedisSerializer`	explicit config	JSON text	readable
`GenericJackson2JsonRedisSerializer`	JSON with `@class`	`{"@class":"com...","id":...}`	readable, with type noise
Redisson `Codec` (Kryo / FST / Marshalling / JSON)	Redisson client	custom binary header	garbage
Protobuf / Hessian / in-house	custom RPC stacks	binary	garbage

One table explains a lot of confusion. The moment a team migrates serializers, or runs Spring Data Redis and Redisson side by side, the same database holds multiple formats at once. And the default dropdown still says UTF-8.

Worse, many developers do not know which serializer their RedisTemplate uses, because someone else configured it three years ago and it was injected with @Autowired.

The three workarounds, and why they hurt

If clients support this, why do people still do it? Because it is off by default, because plenty of developers do not know the feature exists, and because not every client ships it — TinyRDM's built-in decoders cover Base64/GZip/Msgpack/PHP/Pickle but not Java, so you wire up an external command; RESP.app has no Java formatter at all.

1. redis-cli --raw

redis-cli -h 10.0.0.1 --raw get order:10086

--raw only turns off redis-cli's output escaping. The bytes are unchanged. You get unprintable characters, and on some terminals you will need to reset afterwards.

2. A throwaway main method

public static void main(String[] args) throws Exception {
    byte[] raw = Files.readAllBytes(Paths.get("dump.bin"));
    Object o = new ObjectInputStream(new ByteArrayInputStream(raw)).readObject();
    System.out.println(JSON.toJSONString(o));
}

This works. The workflow is: copy Base64 out of the GUI, save to a file, base64-decode, run Java, read output. Five steps to look at one key. And readObject needs the class on the classpath, so you will spend most of your time fighting ClassNotFoundException in a scratch project that does not have your domain classes.

3. DUMP + an online decoder

DUMP output includes an RDB version header and a CRC64 checksum — it is not the same as the raw GET bytes. And pasting production data into a third-party website is not a tradeoff worth discussing.

All three share the same flaw: they turn a two-second "let me look at this value" into a cross-tool, cross-process workflow. When you are debugging, you need to click through five keys and confirm they share a structure. Any approach that requires switching windows has already failed at that job.

Supported is not the same as usable

Let me be precise about what already exists. RedisInsight has had a Java formatter since 2.10, ARDM has a JavaSerialize viewer, and both are built on java-object-serialization — the same library RedisME uses. Nobody has a monopoly here.

So the interesting question is not "does it decode". It is what you get after it decodes, and how many steps stand between you and the answer. That is where implementations drift apart.

Layer 1 — built-in codecs

Next to UTF-8 / Base64 / Hex, RedisME ships three decoders in the Data Encoding dropdown:

JavaSerial — JDK serialization
Pickle — Python pickle, protocols 0–5
PhpSerial — PHP serialize() text

The library solves "can we read the bytes". What the value looks like afterwards is written by each client, and that layer is where the work is:

Case	Raw deserialization output	What I render
`LocalDateTime` / `Instant` / `Duration`	nested `{seconds, nanos}` or epoch numbers	readable timestamps
Java 16+ `record`	fields fetched reflectively, often incomplete	expanded JSON by field
`ArrayList` / `HashMap` / `TreeSet`	`toString()`-ish `[a, b, c]`	arrays and objects, collapsible
very large values	the whole thing dumped into the page	truncated preview, downloadable

There is also a structural difference: Hash / List / Set / ZSet support per-field codec selection. Open the field editor and pick a codec for one field; if the magic number matches, it preselects it. Some clients apply one formatter to the entire key value, which does not help when a hash holds mixed formats.

Pickle maps dict / list / set / bytes to JSON, and objects carrying $class / $type are viewable. PhpSerial keeps the class name as $class for O: instances and handles nesting (references via R: / r: are not supported).

All three are read-only — more on why below.

Layer 2 — auto-detection

Select Auto and the client walks the built-in decoders, matching on magic numbers rather than guessing. AC ED is unambiguously a Java stream; O: + trailing ; is almost certainly PHP serialize. That keeps false positives out of ordinary strings.

Layer 3 — custom codec scripts

This is where the real problems live: in-house binary protocols, compressed JSON, AES-encrypted values, your company's own serialization framework.

RedisME delegates the work to an external script over a minimal stdin/stdout contract:

# read: Redis raw bytes (base64) -> text shown in the editor
{your command} decode {wire_base64}

# write: editor text -> Redis raw bytes (base64)
{your command} encode {editor_text_utf8_base64}

# when base64 exceeds 8000 chars (Windows command-line limits)
{your command} decode --stdin

Direction	arg 1	arg 2	stdout
decode	`decode`	base64 of Redis raw bytes	UTF-8 text
encode	`encode`	base64 of editor text (UTF-8)	single line of base64
large payload	same	`--stdin`	same

On failure, write to stderr and exit non-zero. The client surfaces the exact command it ran in the error dialog — which has saved me more times than I can count, because the cause is nearly always a space in a path or an interpreter missing from PATH.

The client ships templates for Python, Node, and Java. Export one, and you only edit two functions:

def decode(raw: bytes) -> str:
    """Redis raw bytes -> text for the editor"""
    return binascii.hexlify(raw).decode('ascii')   # replace with your logic

def encode(text: str) -> bytes:
    """editor text -> Redis raw bytes"""
    return binascii.unhexlify(text.strip())        # replace with your logic

Your codec logic stays in your own repository. The GUI only shells out to it — which matters if you have compliance constraints, because it means you never hand private keys or an internal protocol to a third-party tool.

One trap: the bundled hex template "succeeds" on any input, because every byte sequence converts to hex. If you tick Auto detect on it, it will claim every value in the database and you will think the client is broken. Only auto-detect the codec you actually use, and make its decode throw when the format does not match.

Three design decisions worth explaining

1. Switching encodings never re-queries Redis.

STRING / Hash / List / Set / ZSet are transferred over IPC as base64 wire, always. The Data Encoding dropdown only changes presentation.

Why it matters: an HGETALL on a production hash can be tens of megabytes. Re-fetching on every dropdown change is not "switching views", it is DDoSing your own database. And the lag you would feel makes you stop exploring.

2. Large payloads go through stdin, not argv.

Windows caps a command line at 32767 characters. The protocol switches to --stdin at 8000 base64 characters — deliberately below the ceiling, because paths, arguments, and environment variables all consume the budget.

3. The built-in codecs are read-only on purpose.

Writing back means fully reconstructing a valid serialization stream: class version UIDs, field order, circular references. Deserialization is best-effort; serialization must be exactly right. A bad write leaves you with a key that no service can read — significantly worse than not being able to read it yourself.

For write-back, use a custom codec script with your local java / python / php. Your runtime, your correctness. I think that boundary should be explicit.

Limitations, stated plainly

No write-back through the three built-in decoders.
Custom codec scripts time out at 5 seconds by default — not the place for heavy inference.
Auto-detection only works on formats with a recognizable magic number.
Stream and JSON types have the encoding dropdown disabled; their handling differs.

If you look at a value once a month, redis-cli plus a scratch main method is fine. If your day is spent confirming what eight Java services wrote into the same key, this saves hours.

Try it

RedisME is a cross-platform Redis GUI built with Tauri (Rust + system WebView), GPL-3.0, under 10 MB, for Windows / macOS / Linux.

Site: https://www.hepengju.com/en/
Source: https://github.com/hepengju/redis-me?utm_source=devto&utm_medium=article&utm_campaign=codec
Codec docs: https://www.hepengju.com/en/guide/usage/codec.html

If you have hit this problem, I would genuinely like to know which serializer your team uses — I want to find the ones I have not covered yet.