What Is Redis?
Redis is that whiteboard. Your main database (the filing cabinet) keeps everything safe on disk. Redis keeps the hot, frequently used data in memory, so your app reads it in a blink. Redis stands for REmote DImctionary Server — at heart it is one giant, very fast key→value dictionary.
Redis is an in-memory key–value store. You give it a key, it gives you back a value. Everything lives in RAM, which is why it answers in microseconds. It can also save to disk so data survives a restart, but its main job is speed.
Why Redis Is So Fast
Three simple choices make Redis fast. It keeps data in memory, it runs commands on a single thread, and it uses lean data structures. Let us look at each.
Memory vs Disk — the speed gap
Bars show how long a read takes. Shorter is faster. The right side puts it in human terms: if a memory read felt like 1 second, a hard-disk read would feel like more than a day.
The single-threaded model
Every command waits in one line and is served by one worker, in order. Each command is so quick that the line never gets stuck.
Because only one command runs at a time, you never get two commands clashing on the same key. Many operations are atomic for free. Modern Redis still uses extra threads for slow background jobs like saving to disk, but your commands run on one fast thread.
Redis vs a Normal Database (RDBMS)
Redis does not replace MySQL or PostgreSQL. They do different jobs. An RDBMS is the safe home for your data. Redis is the fast layer in front of it.
| Point | Redis | RDBMS (MySQL / PostgreSQL) |
|---|---|---|
| Stores data in | Memory (RAM) | Disk |
| Speed | Microseconds | Milliseconds |
| Data model | Key → value structures | Tables, rows, relations |
| Queries | Look up by key | Rich SQL, joins, filters |
| Transactions | Simple (MULTI/EXEC) | Full ACID across tables |
| Best for | Cache, counters, real-time | Source of truth, reporting |
| If it restarts | Can reload from disk (optional) | Data is always safe |
| Data read far more than written |
| Short-lived or throwaway data |
| Simple lookups by a key |
| Needs an answer in a blink |
| Data you cannot ever lose |
| Reports with joins across tables |
| Datasets larger than your RAM |
| Complex multi-table transactions |
Install and Run Redis
Pick the way that suits you. Docker is the quickest for trying it out. On a server, the package
manager is fine. Either way you talk to Redis through redis-cli.
Option A — Docker (quickest)
# start Redis in the background, mapped to port 6379
docker run --name my-redis -p 6379:6379 -d redis
# open the Redis command line inside the container
docker exec -it my-redis redis-cliOption B — Linux (Ubuntu / Debian)
sudo apt update
sudo apt install redis-server -y
# start the server (or it may already run as a service)
redis-server
# in another terminal, connect
redis-cliOption C — macOS (Homebrew)
brew install redis
brew services start redis # run it in the background
redis-cliCheck it works
PING
redis-cli shows a prompt like 127.0.0.1:6379>. Type
PING and Redis replies PONG. That is your "hello world". You are
now ready to store and read data.
Keys, Values, and Basic Commands
A key is a name. A value is what you store under it. These four commands do most of the daily
work: SET, GET, EXISTS, and DEL.
# store a value under a key
SET user:1 "Asha"
# read it back
GET user:1
# does the key exist? 1 = yes, 0 = no
EXISTS user:1
# delete the key (returns how many keys were removed)
DEL user:1
# now it is gone
GET user:1| Command | What it does | Reply |
|---|---|---|
SET key value | Store a value under a key | OK |
GET key | Read the value | the value, or nil |
EXISTS key | Check if a key is there | 1 or 0 |
DEL key | Remove a key | count removed |
Use a clear pattern like user:1, cart:57, or
chat:42:messages. The colon has no special power, but it keeps keys tidy and
easy to group. Good key names make a Redis database easy to read.
KEYS * scans every key at once and can freeze a busy server, because Redis is
single-threaded. To look through keys safely, use SCAN, which walks them in
small batches.
Key Expiry and TTL
A big reason Redis fits caching is that keys can expire on their own. TTL means "time to live" — how many seconds a key has left before Redis deletes it automatically. You never have to clean up old cache by hand.
A key with a TTL counts down. When it hits zero, Redis removes it. No cron job, no cleanup code.
# store a key and set it to expire in 60 seconds
SET otp:57 "839201"
EXPIRE otp:57 60
# how many seconds are left?
TTL otp:57
# do both in one step: set value AND expiry together
SETEX session:57 3600 "token-abc"
# the same idea using SET with the EX option
SET session:57 "token-abc" EX 3600
# changed your mind? make the key permanent again
PERSIST session:57
# check again: -1 means "no expiry set"
TTL session:57
TTL returns -1 when the key exists but has no expiry.
It returns -2 when the key does not exist at all (already
expired or never created). Any other number is the seconds left.
How Redis actually deletes expired keys
Give cached data a TTL that matches how fresh it must be. Cache a home-page list for 60 seconds, a user profile for 10 minutes, an OTP for 5 minutes. When the time is up, the key clears itself and the next read rebuilds it. No cleanup code needed.
Golden Rules
user:1 or cart:57. Good names keep the database readable.
KEYS * on a busy server; use SCAN instead.
EXPIRE or SETEX so old
data clears itself. Cache without a TTL slowly fills your memory.
-1 means no expiry set, -2
means the key is gone. Any other value is the seconds remaining.