Connecting Redis to n8n: caching, counters, and deduplication without a database

An n8n pipeline that checks Postgres on every call to know whether it has already processed an item, or that counts requests per minute with a dedicated table, solves the problem — but pays the cost of a connection and a SQL query on every execution for data that only needs to live for a few seconds or minutes. Redis, an in-memory key-value store, is built exactly for this: sub-millisecond reads and writes, automatic key expiration, and a handful of operations that cover caching, counters, and communication between workflows. This guide covers n8n's Redis node, its actual operations, and three use cases where it beats a round trip to your main database.

Connecting: the Redis credential

n8n's Redis credential asks for very little: Host, Port (6379 by default), an optional Password, the logical database index (Database Number, 0 by default — Redis splits a single instance into 16 numbered databases), and an SSL checkbox for managed services that require it (Upstash, Redis Cloud, most cloud offerings).

On local Docker, as with n8n's other database nodes, the host to enter is the Docker service name (redis in a typical docker-compose.yml), never localhost, which would point at the n8n container itself. If your n8n instance already runs in queue mode with Redis to distribute executions across workers, you can reuse that same Redis instance for the application-level node described here — as long as you separate concerns across different database indexes (index 0 for n8n's internal queue, index 1 for your application cache, for instance) to avoid any key collisions.

The Redis node's operations

The node exposes ten operations, picked depending on the need:

• Set — writes a key. The Key Type parameter offers Automatic, String, Hash, List, or Sets; for a structured object, the Value Is JSON option stores an object directly as a Hash. The Expire option with a TTL in seconds makes the write temporary — the central parameter for any caching use case.
• Get — reads a key, with the same Key Type options to specify the expected read format.
• Increment — atomically increments a numeric key (creating it at 0 if missing), with the same Expire/TTL options. This is the key operation for a counter.
• Delete — removes a key.
• Keys — returns keys matching a pattern, with an option to fetch their values directly.
• Push / Pop — adds or removes an element from a Redis list, with a Tail option to pick the end (stack or queue).
• List Length — returns the size of a list.
• Publish — sends a message on a Redis channel, to any subscriber (see Redis Trigger below).
• Info — returns general information about the Redis instance (memory used, version, connected clients) — useful for a monitoring workflow.

Increment's atomicity is what sets Redis apart from a simple Get followed by a Set: two concurrent executions incrementing the same key at the same time never overwrite each other, unlike a read-then-write pattern against a relational database without an explicit lock.

Use case 1: short-lived caching without hitting the main database

The most direct case: avoid re-calling a third-party API or redoing an expensive computation for data that doesn't change between executions within a window of a few minutes — an exchange rate, the result of a lead-enrichment lookup, a weather API response. The pattern is always the same: Get on the key before the expensive call, an IF node that skips the call if a value already exists, then Set with Expire enabled after the real call to populate the cache for the next executions.

This pattern differs from the semantic cache described in our guide on caching AI responses in Redis: where the semantic cache compares close but not identical questions via embeddings before hitting Redis, this simple cache compares an exact key — an identifier, a normalized parameter. The two combine well: exact caching absorbs repeated identical requests, semantic caching absorbs rephrasings.

A study by Privalov and Stupina (2024), published in the Indonesian Journal of Electrical Engineering and Computer Science ("Improving web-oriented information systems efficiency using Redis caching mechanisms", study on Google Scholar), measured the effect of adding a Redis caching layer in front of a relational database on a web application: data retrieval time dropped by 80.9% and order processing time by 72.3% in their tests. Those exact figures don't transfer one-to-one to an n8n workflow, but the structural conclusion holds: once a read comes back repeatedly with the same parameters, intercepting that trip with Redis costs far less than always falling back to the database or the API.

Use case 2: counters and rate limiting

Increment with Expire builds a sliding-window counter in a single operation: a key named, say, ratelimit:{{ $json.userId }}:{{ $now.toFormat('yyyy-MM-dd-HH-mm') }} increments on every call and expires automatically at the next minute, with no cleanup job to schedule. An IF node placed right after compares the returned value against your threshold and blocks or delays the execution past it.

This is a lightweight complement to the pacing described in our guide on OpenAI and Anthropic rate limits, which relies on Loop Over Items and Wait to pace a batch job you control end to end. The Redis counter applies when the constraint to respect isn't an AI provider's but your own — for example capping how many actions an end user can trigger per minute on a workflow exposed as a webhook, before the first AI call is even reached.

Use case 3: lightweight deduplication

To block processing of the same event received twice, the Redis pattern fits in one operation: Set on a key derived from the event's identifier, with Value Is JSON disabled and a TTL covering the plausible replay window (a few hours is enough for most webhooks). If the key already exists, a preceding Get returns the value and the workflow stops; otherwise processing continues.

This pattern stays lighter than a unique constraint in a database — but also less strict. Our guide on idempotent n8n webhooks explains why a Get-then-Set sequence isn't atomic against two genuinely simultaneous requests, and recommends a unique Postgres constraint with an upsert for cases where a duplicate has a real cost (billing, sending a payment). Reserve Redis-based deduplication for cases where an occasional false negative (a duplicate slipping through anyway) is tolerable — a Slack alert sent twice rather than an invoice issued twice.

Redis Trigger: getting two workflows to talk without a webhook

The Publish operation has a counterpart on the trigger side: Redis Trigger starts a workflow as soon as a message arrives on the channel it's subscribed to. The typical pattern — workflow A processes an event and then runs Publish on a channel named event-processed, while workflow B, independent and started by a Redis Trigger subscribed to that same channel, reacts in turn. This decouples the two workflows without going through an internal webhook that would need securing, and without an Execute Sub-workflow call that would tie them directly together. It's particularly useful for notifying several workflows in parallel from a single event: each subscribes to the channel it cares about, without the first workflow needing to know they exist.

Managed or self-hosted

To get started, a managed Redis service with a free tier (Upstash, Redis Cloud) avoids adding one more service to monitor — the extra network latency stays negligible next to the few milliseconds of a Redis call. Move to a self-hosted Redis instance in a container alongside n8n, as described in our Docker installation guide, once operations-per-second volume justifies removing that network latency, or when a Redis instance is already running for your instance's queue mode — better to share the infrastructure than pay for two.

Common pitfalls

• Forgetting the TTL: without the Expire option enabled on Set or Increment, a key meant to be a temporary cache entry stays in memory indefinitely — a silent leak that grows a managed Redis bill until someone notices.
• Mixing use cases on the same database index: n8n's queue mode and an application cache can technically coexist on the default index 0, but a poorly chosen application-side key pattern can collide with n8n's internal keys; separate database indexes as soon as you can.
• Treating Redis as durable storage: a Redis instance without persistence enabled server-side (AOF/RDB) loses its contents on restart — fine for a cache, dangerous for data you can't afford to rebuild.
• Ignoring the race between Get and Set: for strict deduplication under real concurrent load, prefer a unique database constraint over this pattern, which stays exposed to a race window between the two Redis calls.

Going further

The pacing built into the Inbox AI Pack (€79) and the queue in the RAG Assistant Pack (€119) currently rely on Supabase tables for the bulk of their logging — a deliberate choice for data durability on the product side. The Redis node covered here fits naturally as a complement in your own workflows once the data to store is temporary by nature: an API cache, a rate-limit counter, a signal between two workflows. If you're just getting started with n8n's database nodes, our Postgres node guide remains the right starting point for anything that needs to outlive a few minutes.