Benchmarks

Swytch is designed for production workloads where performance and durability both matter. This page presents benchmark results comparing Swytch to Redis under various conditions.

All benchmarks were run on:

• CPU: AMD Ryzen 5 3600 (6 cores / 12 threads)
• RAM: 64GB DDR4
• Storage: Samsung NVMe in RAID0
• OS: Ubuntu 24.04
• Connection: Unix socket (lowest latency)

Swytch’s performance advantage comes from a lock-free architecture designed from the ground up for multi-core systems:

• Lock-free transactional index: Concurrent reads and writes proceed without blocking each other. No thread waits for another to release a lock.

• Novel eviction algorithm: A self-tuning, lock-free eviction system that adapts to your workload in real-time. This is an area of active research—expect further improvements as we refine the algorithm.

• FASTER-inspired storage: The persistent storage layer uses techniques from Microsoft’s FASTER research project, enabling lock-free append-only writes with indexed lookups that don’t block the hot path.

Redis processes commands single-threaded. Swytch processes commands in parallel across all available cores while maintaining the same consistency guarantees. The result: linear scaling with core count instead of a single-threaded bottleneck.

Using redis-benchmark with default settings, four threads, Unix socket:

Swytch achieves 2x+ throughput while providing full per-operation durability. Redis was configured with appendfsync everysec (1 second of potential data loss).

Using memtier_benchmark with 4 threads, 50 clients, 256-byte values:

Latency comparison (Zipf 0.99 workload):

Using redis-benchmark -c 200 -P 32 (aggressive pipelining):

Swytch’s in-memory mode achieves 42% higher write throughput than Redis and 58% higher than Dragonfly. Even in persistent mode with full durability, Swytch GETs remain fastest.

Production workloads often involve values larger than the 64–256 byte defaults used in most benchmarks. Here’s what happens with 400KB values—closer to real-world JSON documents, serialized objects, or cached API responses:

Test: memtier_benchmark with 4 threads, 50 clients, 400KB values, Zipf 0.99, 10:1 read:write ratio

Key finding: Swytch read latency is 5x better than Redis with large values.

Redis’s single-threaded architecture blocks reads during large value eviction. Every 400KB eviction stalls the entire server. Swytch’s multithreaded design isolates eviction from the read path—reads stay fast while eviction happens in the background.

For read-heavy workloads (typical for caches), this translates to dramatically better user-facing latency.

We replayed production cache traces from published academic datasets to measure real-world hit rates and throughput.

256MB cache, realistic value sizes:

23 percentage points higher hit rate means 95.7% fewer backend database requests.

20GB cache, value sizes scaled to production dimensions:

With realistic value sizes, hit rates are tied while Swytch delivers 1.8x throughput.

Note: Earlier benchmarks with artificially small (<1 kb) values showed Redis with a slight hit rate advantage. This disappeared when value sizes matched production conditions.

8GB cache:

Under normal memory pressure, both systems achieve similar hit rates, but Swytch maintains 3x throughput.

Swytch’s tiered storage provides full durability (10 ms max data loss) with minimal performance impact.

Test: memtier_benchmark, 4 threads, 50 clients, 256-byte values, Unix socket

Write-through mode (full durability) adds minimal latency overhead. Ghost mode (write-back) offers higher write throughput when eventual persistence is acceptable.

Swytch delivers higher throughput, lower latency, and better durability than Redis across all tested workloads.

# Single operations
redis-benchmark -s /path/to/socket -t set,get,incr,lpush,lpop,lrange -q --threads 4

# Pipeline stress test
redis-benchmark -s /path/to/socket -n 2000000 -c 200 -P 32 -t set,get -q

# Realistic mixed workload
memtier_benchmark -S /path/to/socket \
  --protocol=redis \
  --threads=4 --clients=50 \
  --requests=100000 \
  --ratio=1:10 \
  --data-size=256

# Zipf distribution (hot keys)
memtier_benchmark -S /path/to/socket \
  --protocol=redis \
  --threads=4 --clients=50 \
  --requests=1000000 \
  --ratio=1:10 \
  --key-pattern=G:G \
  --key-zipf-const=0.99 \
  --key-maximum=100000 \
  --data-size=256

# Large values
memtier_benchmark -S /path/to/socket \
  --protocol=redis \
  --threads=4 --clients=50 \
  --requests=5000 \
  --ratio=1:10 \
  --key-pattern=G:G \
  --key-zipf-const=0.99 \
  --key-maximum=10000 \
  --data-size=409600