WeTask vs Redis: Performance Benchmarks

Redis still holds a significant lead in raw throughput, but my latest internal tests on WeTask v0.1.0-rc.1 show some interesting scaling behavior when dealing with larger pipelines. We've been evaluating WeTask as a potential alternative for specific task-lifecycle workloads, and while it doesn't replace a dedicated cache like Redis for every use case, the trade-offs are worth analyzing.

The Setup

I ran these benchmarks on a MacBook Air (M3, 16GB RAM) using Docker Desktop 4.66.1. To keep the environment clean, I used a standalone WeTask instance with consensus disabled and a Redis 7.4.9 instance with persistence turned off (save "" and appendonly no).

The clients were a mix of Go 1.26.5 (using go-redis/v9), Python 3.14.4, and Node 25.4.0. All workloads were executed serially to ensure no cross-load interference.

Network Cache Performance

In unary operation tests (SET/GET), Redis consistently outperformed WeTask. When testing with 64B payloads at a concurrency of 64, Redis hit 32,345 ops/s for GET hits, while WeTask managed 9,294 ops/s.

• 64B Payload (Concurrency 16): Redis reached 20,176 ops/s (SET) vs WeTask's 6,956 ops/s.
• 1,024B Payload (Concurrency 16): Redis reached 18,861 ops/s (SET) vs WeTask's 6,866 ops/s.
• Latency (p95): At 64B/Concurrency 64, WeTask's p95 was 14.23ms compared to Redis's 3.20ms.

It is important to note that these are single unary samples. While the ratio (roughly 2x to 3x in favor of Redis) is clear, these aren't absolute capacity ceilings.

Pipeline Throughput Analysis

The real interest lies in the mixed pipeline results (SET/GET/DELETE mix). As the pipeline size increases, WeTask's throughput scales more aggressively, even though it remains slower than Redis.

• 10-op Pipeline (Concurrency 16): WeTask 74,135 ops/s vs Redis 160,198 ops/s.
• 1,000-op Pipeline (Concurrency 16): WeTask 402,175 ops/s vs Redis 886,477 ops/s.

While Redis is still roughly 2.2x faster at the 1,000-op mark, the gap in perceived efficiency narrows as the batch size grows.

Technical Nuance: SubmitTask vs LPUSH

If you're looking at this from an AI workflow or LLM agent deployment perspective, don't mistake these numbers for a 1:1 equivalence.

When you call SubmitTask in WeTask, it triggers a full task lifecycle including a fallback handler. In contrast, a Redis LPUSH is simply appending bytes to a non-persistent list. The former is a functional operation; the latter is a data structure update. For those using Celery probes, remember that those typically measure producer enqueue only—they don't account for worker acknowledgement or retry logic, which WeTask handles natively.

Implementation Detail

For those trying to replicate this or integrate similar benchmarks into their own AI workflow, here is the basic environment config I used for the Redis side to ensure maximum speed:

# Redis optimization for benchmarking
redis-config:
  save: ""
  appendonly: "no"
  maxmemory-policy: "noeviction"
  io-threads: 1

And for the WeTask deployment:

# Deployment version used
docker pull wetask-io/wetask:v0.1.0-rc.1
# Note: Consensus disabled for standalone performance testing

WeTask is clearly targeting a different operational profile than a pure K/V store. If your priority is absolute lowest latency for simple cache hits, Redis is the obvious choice. But if you need a system that understands the "lifecycle" of a task, the throughput penalty is a manageable trade-off.