Why is Redis so slow (~500 ms per operation) inside n8n workflows?

[iamrecan]

Hi everyone,

I’ve been using Redis inside my n8n workflows to store temporary state (session data, orchestration outputs, etc.).

However, I’ve noticed that every SET or DEL operation takes around 400–500 ms, which feels unexpectedly slow.

After some observation, it seems like n8n might be opening a new Redis connection for each node execution, rather than reusing a single persistent connection — but this is just a guess based on behavior, not a confirmed fact.
If that’s the case, it could explain the extra latency when Redis is called multiple times in one workflow.

Here’s what I’d like to ask:

1. Is this connection-per-node behavior actually how n8n handles Redis under the hood?

2. Is there any way to reuse a global Redis connection across multiple nodes (e.g., through environment variables or an initialized client)?

3. Would switching to an HTTP-based Redis service (like Upstash REST API) help reduce connection latency?

4. Any best practices or recommended approaches for improving Redis performance in n8n?

Thanks in advance — I’d really appreciate any insights from people who’ve dealt with Redis latency in n8n.

[achamm]

yo, so this is a classic one - yeah, n8n’s Redis node does create a new connection per node execution, which adds overhead. that 400-500ms you’re seeing is probably connection setup time, not the actual redis operation (which should be like 1-5ms).

here’s what typically helps:

**Option 1: Use the Redis node but batch your operations**

if you’re doing multiple redis calls in one workflow, try grouping them. instead of 3 separate Redis nodes each doing SET, use one Redis node and send all 3 commands at once using pipelining.

in the Redis node, you can send multiple commands:

```json

[

[“SET”, “key1”, “value1”],

[“SET”, “key2”, “value2”],

[“GET”, “key1”]

]

```

this way you only pay the connection overhead once.

**Option 2: HTTP request to Redis (if you have it exposed)**

some people run redis-cli via HTTP or use a simple wrapper API. bit more setup but avoids the node overhead entirely.

**Option 3: Use n8n’s internal storage instead**

depending on what you’re storing, n8n’s built-in variables or the storage feature might work. not as flexible as redis but no network overhead.

**Option 4: Keep-alive / connection pooling**

check if your Redis integration has any keep-alive settings. some self-hosted setups let you tweak this - worth checking your n8n config.

the image you posted would help figure out exactly what’s happening, but if every single operation is 400-500ms, its def the connection. actual redis is fast - the overhead is the setup.

what kind of operations are you doing? if its mostly reads/writes of small data, batching usually fixes it. lmk if any of these help

[Bropis]

AI slop answer