What is Redis? Redis is an open-source, in-memory data store: it keeps data in RAM and lets your app save and fetch it by name, or key. Because the data is already in memory, apps can read it almost instantly. That's why Redis often runs quietly behind apps that stay responsive with millions of users.
This guide explains what Redis is, why keeping data in memory makes it fast, and how it works inside. It covers keys, data types, saving to disk and expiring keys. Then it shows where Redis is used in real apps and the three mistakes that most often trip up beginners.
- Redis is an open-source data store that keeps data in RAM, not on disk.
- You save a value under a key with SET and read it back with GET.
- Data types like hashes and sorted sets let Redis organise data for you.
- It's mostly used as a fast helper beside a main database: caching, sessions, leaderboards and queues.
- Keep your real data in the main database, and always set memory limits and expirations.
- 0:00Intro
- 0:25When every page feels slow
- 1:23What Redis actually is
- 2:19Memory beats disk every time
- 3:11Store by key, fetch by key
- 4:10Five useful data types
- 5:01Saving data to disk
- 6:00Keys that expire on time
- 6:54How a cache answers requests
- 7:39One tool, many jobs
- 8:36Building a game leaderboard
- 9:22Queues and pub/sub messaging
- 10:18Three mistakes beginners make
- 11:16Redis beside your database
- 12:12Redis in six ideas
- 12:49A fast helper, not a replacement
Why do apps feel slow?
Picture opening a shopping app, tapping your cart and watching a loading spinner that never stops. Most people give up and close the app. When an app feels slow, the cause usually isn't the phone. More often, the app is waiting on its database, which answers the same questions from scratch on every visit.
Much of that work is repeated. Your profile, the product list and the top scores rarely change. Yet many apps ask the database for them again on every page load. Each request costs time and effort for an answer the app already had a moment ago.
This matters because users won't wait. A slow app loses people even when everything technically works. So the real question is how to answer common requests without making the database do the same work again and again. Redis is one of the most popular answers to that question.
- Repeated work: the same data is fetched again and again
- Users won't wait: people leave apps that feel sluggish
What is Redis, exactly?
Redis is an open-source, in-memory data store. Open-source means it's free to use, and anyone can read and improve its code. In-memory is the central idea. Most databases keep their data on disk. Redis keeps it in RAM, the fast working memory your computer uses for the apps you have open right now.
You use Redis through keys and values. You save something under a name, called a key, and later ask for it by that same name. A good mental picture is a cabinet of clearly labelled drawers. You don't search the whole cabinet. You open the drawer with the right label.
Most teams use Redis as a fast helper, not as their only database. It usually sits next to the main database and holds copies of popular data so the app can reach it quickly. Redis isn't magic. It's memory, organised very well.
Why is Redis so fast? Memory vs disk
Redis is fast mainly because reading from memory is far quicker than reading from a disk-based database. A regular database must find the data on disk, load it, then return it. Redis skips that step. The data is already in RAM, so it looks up the key and returns the value.
There is a trade-off. Memory is fast, but it's smaller and more expensive than disk. A disk database can hold everything and store it safely, while Redis is best for hot data, meaning the information your app reads most often. Redis is not meant to hold everything you own.
- Where data lives: disk database on disk, loaded when needed; Redis already in RAM
- Read path: disk is find, load, then return; Redis is look up and return
- Best for: disk holds everything safely; Redis holds hot, often-read data
- Size: disk is large; memory is limited
How Redis stores data: keys and values
Using Redis comes down to one idea: put a value under a key, then ask for it back. Redis uses short, readable commands. The two you'll use most are SET, which saves a value, and GET, which reads it back. They're enough to get started.
In the example, SET saves the value Sokha under the key user:42:name. GET then reads it back with the same key, and Redis replies with Sokha. A common habit is to group keys with colons, such as the word user, then the user's ID, then the field. With thousands of keys, this keeps them easy to understand later.
Direct lookup is a big reason this is quick. Redis doesn't scan rows or join tables. It goes straight to the key, like opening one labelled drawer. Simple access plus data held in memory is what makes Redis feel instant.
# save a value under a key
SET user:42:name "Sokha"
# read it back by key
GET user:42:name
# reply: "Sokha"Redis data types: five useful shapes
A Redis value doesn't have to be plain text. Each key can hold a small structure that does useful work for you. Choosing the right structure keeps your code simpler and your requests faster, because Redis handles the organising instead of your app.
For example, if you want the top ten players in a game, a sorted set already keeps them ranked. If you need a user profile with a name, email and other fields, a hash fits naturally. The right type up front saves your app work on every request.
- Strings: text or numbers, like a name or a counter
- Lists: items kept in order, like a to-do list
- Sets: unique items with no duplicates
- Hashes: fields grouped together, like a mini user profile
- Sorted sets: items ranked by a score
Does Redis lose data on restart? Persistence and TTL
If everything lives in memory, what happens when the server restarts? Memory is wiped. To handle this, Redis can write copies of its data to disk in the background. When your app makes a change, RAM updates at once so every read sees it. Redis then saves the change to a disk file it can recover from later.
There are two main ways to save data. Snapshots store a full copy of your data every so often. They're compact and quick to reload, but anything written since the last snapshot can be lost in a crash. An append-only file records every change in order, like a diary. Less data can be lost, so it's the safer option.
Redis can also delete data on purpose. You can give any key a time-to-live, or TTL. For example, you might save a login session for thirty minutes in a single command. When the time runs out, Redis removes the key itself, with no cleanup script needed. The next request then loads fresh data and saves it again with a new timer.
- Snapshots: a full copy saved from time to time
- Append-only file: every write logged as it happens
- TTL: keys expire automatically, keeping memory tidy and data fresh
How does Redis caching work?
Caching is the most common way to use Redis. The idea is that Redis remembers answers so the database doesn't have to repeat the same work. The rule is simple: always check Redis first. Only when the answer isn't there, which is called a cache miss, does the app go to the slower database.
Here's a typical request. A user's phone asks for a product page. The app server checks the Redis cache first. If the answer is there, it comes back almost instantly. If not, the app asks the main database, returns the result, and saves it in Redis for next time.
When popular data sits in Redis, most requests are answered straight from memory and never reach the database. The database gets breathing room, and the app stays fast as traffic grows.
What is Redis used for besides caching?
Many app features need lots of small reads and writes that must happen quickly, and Redis was built for that kind of work. Rate limiting is a good example. Each time a user makes a request, Redis adds one to that user's counter, which has a short expiry. If there are too many requests within that window, the app tells the user to slow down. Sessions are another common use: when an app runs on several servers, they can all read the same login data from Redis.
Leaderboards show how useful sorted sets are. When Dara's match ends with 900 points, the game server runs ZADD top 900 dara. The set re-sorts itself and Dara moves up. Reading the top three then returns Dara in second place with 900. Redis keeps the order current on every write, so you never have to re-sort a large table.
Redis can also carry messages between parts of an app. For a simple job queue, the app pushes a task, such as sending a welcome email, onto a list, and a background worker picks it up. With pub/sub, a publisher sends an event to a channel and every listener receives it at once. However, pub/sub doesn't store messages. A listener that's offline misses them, so use pub/sub for live updates, not for messages you can't afford to lose.
- Cache: remembers answers
- Sessions: remember who's logged in
- Leaderboards: rank scores with sorted sets
- Rate limiting: count requests per user
- Job queues and pub/sub: pass tasks and events between services
Common Redis mistakes and how to avoid them
Redis is easy to start with, so it's tempting to use it for everything. The problems usually show up weeks later, when data grows, a server restarts, or memory fills without anyone noticing. The biggest mistake is making Redis your only database. Even with snapshots or an append-only file, Redis is built for speed and shouldn't be the one place your important data lives.
The second mistake is ignoring memory limits. RAM is smaller than disk, and when Redis runs out of it, new writes can fail or older data gets pushed out. The third mistake is forgetting expirations. Without a TTL, cached data never leaves, and memory slowly fills with stale values.
The healthy design is the app server, then Redis, then the database. The database stays the source of truth, so losing Redis is an inconvenience rather than a disaster. Cap Redis's memory and choose what it removes when full, such as the least recently used keys. Give every cached key a TTL that matches how often the data changes: short for prices, longer for a product description.
- Don't use Redis as your only database
- Set a memory limit and an eviction rule
- Add a TTL to every cached key
Key takeaways
- Redis is an in-memory store, which is why it's fast.
- You store data by key and fetch it by key, with no table scans.
- Data types such as hashes and sorted sets do organising work for your app.
- Snapshots and the append-only file help Redis recover after a restart.
- It powers caching, sessions, leaderboards, rate limiting and queues.
- Keep the truth in your main database, and always set limits and expirations.
Frequently asked questions
Is Redis a database or a cache?
Redis is a data store that can do both, but most teams use it as a fast helper beside their main database. It holds copies of frequently read data, while the main database keeps the complete, authoritative copy.
Why is Redis faster than a regular database?
Redis keeps its data in RAM, so it can look up a key and return the value immediately. A disk-based database must find the data on disk and load it first. Direct key lookups, with no table scans or joins, add to that speed.
Does Redis lose data when it restarts?
Memory is cleared on restart, but Redis can save data to disk and load it back. Snapshots save a full copy every so often, while an append-only file logs every write, so less data can be lost.
What is a TTL in Redis?
A TTL, or time-to-live, is a timer on a key. When it runs out, Redis deletes the key automatically. It keeps memory tidy and makes sure cached data is refreshed from the main database.
Can I use Redis as my only database?
It's not recommended. Redis is built for speed, and its memory is limited, so important data should live in your main database. That way, losing Redis is an inconvenience, not a disaster.
