Redis Explained: What It Is & How to Use It With Node.js

Redis comes up in almost every backend conversation eventually. Someone says "just cache it in Redis" and everyone nods, but if you have never actually touched it, that sentence does not mean much. Is Redis a database? A cache? Both? Neither?

Most guides dodge that question and jump straight into installing things. This one answers it first, because the confusion about what Redis is is exactly what stops people from knowing when to use it.

By the end you will know what Redis is doing under the hood, why it is so much faster than a normal database, how to run it on your machine in one command, and how to wire it into a Node.js app with a caching pattern you will reuse for years.

Redis stands for Remote Dictionary Server. That name is more useful than "Redis" alone, because it describes exactly what is going on: it is a server you talk to over the network, and it behaves like a dictionary. You give it a key, it gives you back a value. No tables, no rows, no joins.

If you have used a JavaScript Map or a Python dict, you already understand the mental model. The difference is that this dictionary lives in its own process, on its own port, and every service in your system can read and write to it at the same time.

The "in memory" part is the whole story behind the speed. A traditional database like PostgreSQL writes to disk, because disk is where data survives a restart. Disk reads and writes are slow compared to RAM even on fast NVMe SSDs, and that gap is measured in orders of magnitude, not percentages.

Redis keeps the working set in RAM and only touches disk on its own schedule, which is why a Redis GET typically returns in well under a millisecond while an equivalent indexed database query is comfortably 10 to 50 times slower once you count connection overhead, query planning, and disk access.

One more thing worth knowing early: the core of Redis processes commands on a single thread. That sounds like a limitation, and in some workloads it is, but it is also the reason Redis operations are atomic without you doing anything. There is no partial update and no race between two clients incrementing the same counter, because commands run one after another.

Technically, yes. Redis is a database. It stores data, it can persist that data to disk, and it can be run as the primary datastore for an application. Some companies do exactly that.

In practice, almost nobody uses Redis as their only database, and the reasons are worth understanding because they tell you where the boundary sits.

Redis has no query language. You cannot ask it "give me every user who signed up last month and has more than three orders." You can fetch by key, or use the commands that belong to a specific data structure. That is plenty for a cache and completely unworkable for reporting or ad hoc analysis.

Redis is memory-first. Your dataset has to fit in RAM. A 200 GB PostgreSQL database runs happily on a machine with 16 GB of memory. A 200 GB Redis dataset needs roughly 200 GB of RAM, which changes the cost conversation entirely. If you are sizing an instance, our Redis memory calculator estimates how much RAM a given key count and value size will actually need.

Durability is opt-in. A relational database gives you durability by default: once a transaction commits, it survived. Redis makes you choose a persistence strategy on purpose, and the default configuration favours speed over guarantees.

So the honest answer: Redis is a database in the technical sense, but it is built to be exceptionally good at a narrower set of jobs. Most teams run it alongside PostgreSQL or MySQL, not instead of them. Treating those two rows of the table as competitors is the mistake; they solve different halves of the same problem.

Set the marketing language aside. Here is what Redis is genuinely good for, roughly in the order you will meet each one in a real job.

Caching. This is the big one, and it is the reason most teams install Redis in the first place. If your app runs the same expensive query or third-party API call over and over, store the result in Redis with an expiry and skip the expensive work next time. A dashboard query that takes 400 ms against Postgres becomes a sub-millisecond lookup, and the database stops carrying traffic it never needed to see. Which caching pattern you pick matters as much as the tool; our full breakdown of caching strategies covers cache-aside, write-through, and the invalidation traps in each.

Session storage. The moment you run more than one server instance behind a load balancer, storing sessions in process memory breaks. Request one hits server A and logs the user in; request two hits server B, which has never heard of them. Redis gives every instance one shared place to read and write session data, which is why it is the default session store for Express, Django, and Rails deployments at scale.

Rate limiting. Redis has atomic increment commands, so "allow this API key 100 requests per minute" is a counter with a TTL rather than a distributed locking problem. Because commands are atomic, two simultaneous requests cannot both read the same count and both decide they are under the limit.

Leaderboards and rankings. Sorted sets keep members ordered by score automatically. Building a live leaderboard on a relational database means an ORDER BY over a growing table on every page load, plus indexes to maintain. Redis gives you "top 10 players" and "what rank is this user" as single commands that stay fast as the set grows.

Pub/sub and real-time fan-out. Redis can broadcast a message to every subscribed client instantly, which is handy for live notifications, presence indicators, and pushing updates to WebSocket servers. It is fire-and-forget, so it suits UI updates rather than anything where a dropped message is a business problem.

Queues and background jobs. Lists and streams are commonly used as job queues, and popular libraries like BullMQ are built directly on Redis. This works well up to a point, covered in the "when not to use Redis" section below.

The fastest way to get Redis running on your machine, assuming Docker is installed, is a single command:

That pulls the official image, runs it detached, and maps the container's Redis port to port 6379 on your machine, which is the default every client library expects. Confirm it is actually alive:

If you get PONG back, Redis is running and accepting commands. That two-command loop is the whole local setup.

While you are in redis-cli, it is worth spending two minutes poking at it directly before you write any application code. Run redis-cli with no arguments to get an interactive prompt and try these:

If you would rather install Redis natively, it is available through the usual package managers: brew install redis on macOS, apt install redis-server on Debian and Ubuntu, and via WSL on Windows. Docker is still the easier path for local development, because you can delete the container and start from a clean state without touching anything installed on your system.

Redis is not limited to string keys holding string values. It ships with several built-in data structures, and choosing the right one often removes a chunk of application logic you would otherwise write yourself.

You do not need to memorise the command set for each of these today. Knowing that they exist, and roughly what each is for, is enough to recognise the moment you need one. The typical progression is to use strings for everything at first, then discover hashes when you get tired of parsing and re-stringifying whole objects to change one field.

There are more types beyond these five (streams, bitmaps, HyperLogLog, geospatial indexes), but they solve specific problems you will know you have when you have them.

You need a client library. ioredis and node-redis are the two mainstream options and either is fine for most projects. The examples below use ioredis because its API is slightly more direct.

That is the entire loop: connect, set, get. Create the client once and share it across your app rather than opening a new connection per request, because connection setup is the slowest part of the whole interaction.

Now the pattern you will actually use in production. This is cache-aside, and it covers a large share of real-world Redis usage:

Three details in that function are doing real work. The "EX", TTL_SECONDS argument sets an expiry so stale data cannot live forever, which is your safety net when cache invalidation goes wrong. The if (user) guard stops you caching null and turning a temporary miss into an hour of wrong answers. And the key namespace (user:123 rather than just 123) keeps different kinds of data from colliding in a shared keyspace.

The one thing this simple version does not handle is invalidation on write. If something updates the user, delete the key in the same operation:

Deleting the key rather than overwriting it is deliberate. The next read rebuilds the cache from whatever the database actually contains, so a bug in your update path cannot write bad data into the cache and keep serving it.

If you are on Bun rather than Node, you may not need a client library at all: Bun ships a built-in Redis client, which we covered in our write-up on Bun's native SQL and Redis clients.

This is the part most introductions skip, and it is the part that decides whether Redis is safe for a given job. Redis offers two persistence mechanisms, and you can run either, both, or neither.

RDB snapshots write a point-in-time dump of the whole dataset to disk at intervals you configure. They are compact and fast to restore, but a crash loses everything written since the last snapshot, which could be several minutes of data.

AOF (append-only file) logs every write command as it happens and replays the log on startup. It loses far less on a crash, at the cost of a larger file and slightly more write overhead. How much you can lose depends on the appendfsync setting: the common default flushes to disk once per second, so worst case is about a second of writes.

Running both is the usual recommendation for anything you would be upset to lose: AOF for the fine-grained recovery, RDB for fast restores and backups.

Related to this is eviction. When Redis reaches its maxmemory limit, its maxmemory-policy decides what happens: reject new writes, or evict existing keys (allkeys-lru evicts the least recently used, volatile-ttl evicts keys closest to expiry). For a pure cache, an LRU policy is what you want. For anything holding data you need, rejecting writes and alerting is safer than silently dropping keys.

Redis gets recommended reflexively, so it is worth being clear about where it is the wrong answer.

None of that is an argument against Redis. It is an argument for adding it when you can name the problem it is solving, which is the difference between a stack you understand and a stack you inherited.

Redis is simpler than its reputation suggests: a dictionary that lives in RAM, in its own process, that every part of your system can reach. Everything else, the data types, the persistence modes, the eviction policies, is detail hanging off that one idea.

Start with the Docker command and the cache-aside function above. Once that pattern is running against something real, the rest of Redis stops being a list of features and starts being a set of tools you reach for when you recognise the problem each one solves.