JuiceFS metadata on Redis: create plus rename went from 22 ms to 3.2 ms
What the move from Postgres to Redis gained on a loaded production filesystem, and what it cost in durability.
We measured create-plus-rename latency on the production JuiceFS filesystem that held agent disks in June and July 2026, before and after moving its metadata from Postgres to Redis. That shared filesystem is retired. Agents now run in Firecracker microVMs, and Workspaces keep their files.
The short answer
- About 7x faster on production. One create-plus-rename pair took about 22 ms on Postgres and about 3.2 ms on Redis, measured on 2026-06-21.
- Batching fsync gained nothing. JuiceFS serializes metadata mutations, and fsync was nearly free under writeback.
- Redis becomes the source of truth. We ran it with
noeviction, AOFeverysecplus RDB snapshots, andmaxmemorybelow the container memory limit.
Clean-room comparison
Same juicefs binary (1.3.1), same node, same storage backend, only the metadata engine differing:
| Operation | Postgres | Redis |
|---|---|---|
| create + rename | ~13.9 ms | ~3.2 ms (~4.4x) |
| create only | ~5.4 ms | ~0.92 ms (~5.9x) |
| rename only | ~9.1 ms | ~2.2 ms (~4.1x) |
When it applies
- The 7x is our workload's number. It compares a loaded production Postgres with Redis. The clean-room multiple was about 4.4x, and all numbers come from juicefs 1.3.1. We have not re-run the comparison on 1.4.0.
- Durability: a single Redis instance with
everyseccan lose up to about one second of metadata mutations. Postgres gave synchronous durability. If that window is unacceptable, use a SQL engine or TiKV. - Capacity is RAM, not disk: about 400 bytes per inode on our filesystem, so ten million inodes is on the order of 4 GB. File contents stay on object storage.
The full post has the juicefs dump and juicefs load migration steps and a configuration drift trap we nearly hit after the cutover.