Redis
Your quote lists Redis and a database. Here's why both.
The short answer
Redis is an in-memory store that sits alongside your database rather than replacing it. It keeps data in memory so it comes back almost instantly, which is why it turns up doing three jobs: caching, sessions and background queues. Memory is fast, finite, and gone when the power goes unless somebody arranged otherwise.
Somewhere in the quote there's a line for a database, and a separate line for Redis, and nobody explained why a build needs both. Redis isn't a second database or a spare one. It's a fast, forgetful layer in front of the permanent one, and the confusion comes from expecting it to be something it never was.
It holds a little data where it can be reached instantly
Redis keeps data in memory. That's the whole design, and everything else follows from it. Memory is where a computer holds what it's using right now, which is why reading from it takes a fraction of a millisecond and reading from a disk doesn't.
What it holds is deliberately simple. You give a piece of data a name, and later you ask for it by that name. It also holds lists, sets and counters, which is what makes it useful for more than single values. It has done that narrow job since 2009.
None of that makes it a place to keep your records. It's a fast copy of things that live somewhere else, and it's fast precisely because it gave up what a database does for you.
The three jobs you'll actually see it doing
Almost every time Redis appears in a proposal it's doing one of three things. They have little to do with each other, so it's worth asking which one is meant.
01
A page is requested
Someone opens a screen that needs a figure worked out from your records.
02
Redis is checked
A lookup by name. If the answer is sitting there, it comes straight back and nothing else runs.
03
The database answers
Only when it isn't there. The records get read and the figure gets worked out the slow way.
04
The answer is kept
It goes into Redis with an expiry on it, so the next person asking takes the short path.
1. Caching: not doing the same work twice
A page needs a figure that takes real work to produce. Rather than produce it for every visitor, the answer gets stored under a name with an expiry on it. The next person asking gets the stored copy instantly.
2. Sessions: remembering who is signed in
Every request from a signed-in person has to establish who they are before anything else happens. That check runs constantly, so it has to be quick, and it doesn't need to last forever. Lose the store and everyone gets logged out, which is irritating rather than serious.
3. Queues: work that happens after the page loads
Some work is too slow to make a visitor wait for it. Sending the confirmation email, building the export, resizing the upload. The job goes onto a list, the page finishes straight away, and something else picks it up and does it.
Memory is fast, finite and forgetful
Those three go together, and they're the trade you're making.
Finite is the part nobody mentions in a proposal. A server has far less memory than disk, and memory costs much more per gigabyte, so everything kept in Redis has to earn its space. Most setups get a memory limit and a rule for what gets discarded when it fills. A full cache dropping its oldest entries is working correctly, not failing.
Forgetful is the part that surprises people. Data in memory is gone when the process stops, so Redis can also write to disk, by saving a snapshot periodically or by appending each change to a file. Both are configurable, and neither turns it into the place your records should live.
One question settles most of this. If everything in Redis vanished right now, what couldn't be rebuilt from the database? The answer you want is roughly "nothing, the site would be slow for a few minutes". Any other answer is worth understanding before you approve the build.
Redis, in memory
Your database, on disk
- How much it holds
Redis, in memory: Whatever fits in the memory you rent, and memory is the expensive kind.
Your database, on disk: Far more, on cheaper storage, but reaching any of it costs a trip to the disk.
- After a restart
Redis, in memory: Whatever was last written to disk. How much that is comes down to a setting.
Your database, on disk: Everything committed. That guarantee is part of why it's slower.
- How you ask for things
Redis, in memory: By name. You have to know what you're looking for before you ask.
Your database, on disk: By question, including ones nobody anticipated, and a badly shaped question can stall the whole table.
- The failure you'll meet
Redis, in memory: A value that's quietly out of date and looks current.
Your database, on disk: A page that takes too long to load.
Where it stops
The first limit is what you can ask it. You look things up by name, so you have to know the name. A database can answer a question nobody anticipated when the data went in, which is most of what makes it worth having. Redis mostly can't.
The second limit is staleness, and it's the one that produces real bugs. Once a copy of an answer exists, there's a window where the original changed and the copy didn't. Somebody reports a figure is wrong, it's correct in the database, and it fixes itself an hour later. That's a cache, and the length of that window was somebody's decision.
The third is that it hides problems as capably as it solves them. A cache in front of a slow query makes the page fast and leaves the query as slow as it was. The work still runs whenever the cache comes up empty, and it gets slower as your data grows.
It also expects to sit on a private network, reachable only by your own application. Managed versions arrive configured that way. Installed by hand on a rented server in a hurry is where that goes wrong.
Redis, Valkey, and why you might see both names
If two quotes name different things here, this is usually why. Redis spent most of its life under a permissive open-source licence. In 2024 the company that develops it changed those terms, and several large cloud providers forked the last version under the old licence into a project called Valkey, run under the Linux Foundation. Redis added an open-source option again in 2025.
The two came from the same code, behave alike, and have been drifting apart since. For caching, sessions and queues you're unlikely to feel a difference. A proposal naming one rather than the other is usually telling you about hosting preferences.
What it costs you in people
Operationally, close to nothing. Every large hosting provider sells a managed version, so nobody on your side patches a server or arranges its backups. That part is a line on a bill.
The cost is judgment inside the build, and it tends to sit with one person. Somebody has to decide what gets cached, how long each thing lives, and what clears it early when the record underneath changes. That rarely gets written down, which is why "this screen is showing an old number" is a hard ticket for whoever inherits the code.
So ask for one page: what's kept in Redis, how long each thing lives, and what happens if it all disappears. If that page can't be written in an afternoon, the answers were guessed.
Worth knowing before you start
Ask what breaks if Redis is unavailable for ten minutes. "The site gets slower", "everyone gets logged out" and "the queued work is lost" are three different answers, and which one you get tells you what it's doing.
Ask for the expiry time on each cached thing and who chose it. A number nobody can defend is why a page eventually shows yesterday's figure to somebody who notices.
If a queue runs on Redis, ask what happens to jobs already on the list when it restarts. That answer decides whether a lost confirmation email is possible.
Check that the memory limit and the discard rule were set on purpose. Dropping the oldest entries is right for a cache, and it signs people out at random if the same instance also holds sessions.
Common questions
Not in the sense you want from one. It's a data store built to hold a fast copy of things kept properly somewhere else. If something exists only in Redis, that was a decision, and it's worth asking about.
Most builds don't, at the start. It earns its place when something specific is slow for a reason somebody can point at, or when work has to happen outside the visitor's request. Plenty of stacks handle caching, sessions and background jobs without it, so a proposal that never mentions Redis isn't missing something.
That depends entirely on the job it's doing. Caching: pages get slow while the database takes the full load. Sessions: everyone signed in gets logged out. Queues: work waiting is at risk unless it was set up to survive a restart.
Valkey is a fork of Redis, started in 2024 after the licence changed and now run under the Linux Foundation. For caching, sessions and queues you're unlikely to notice which one you have.
Often you should, first. A missing index, a query pulling far more rows than it needs, an image served at full size. A cache in front of any of those works, and buries the cause.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.