Redis vs SQL and NoSQL Databases
A new Wordcraft developer suggests moving the whole game into Redis "because it is faster". Another wants to drop Redis "because PostgreSQL can do everything". Both are missing the point: the stores answer different kinds of question, and most real apps use both.
The rule
Redis answers questions you can name by key; databases answer questions you describe.
A SQL database (PostgreSQL, MySQL) lets you describe what you want: "players from Pune who joined in March, sorted by coins". It plans a search, uses indexes, joins tables, enforces relationships and keeps data safely on disk. Its dataset can be far larger than memory.
A document or wide-column NoSQL database (MongoDB, Cassandra) relaxes the fixed tables but still lets you query by fields inside the data and stores it mainly on disk.
Redis is a key-value store. You must know the key: player:asha, leaderboard, session:9f2c. Core Redis has no WHERE clause over values and no joins (add-on modules such as Redis Search add indexes, but they are beyond the fundamentals). In exchange, a lookup by key is served straight from memory, and the built-in structures (sorted sets, lists, sets) do work that would otherwise need a query.
| Question | Best fit |
|---|---|
| What is Asha's score right now? | Redis |
| Who are the top ten players? | Redis (sorted set) |
| Which Pune players spent over 500 coins in March? | SQL |
| What did player 1042 buy last year? | SQL |
When to choose Redis: the data is small enough for RAM, you always reach it through a known key, you need answers in well under a millisecond, or the data has a lifetime (cache, session, rate limit). When not to: you need ad-hoc filtering, relationships between records, or a dataset much bigger than memory. Then Redis sits beside the main database, never instead of it.
The shortcut
Read the question aloud. If you can say the key before you ask, it is a Redis question. If you have to describe conditions, it is a database question.
Can you name the key?
Yes: a counter such as
games:ravi:2026-09-25.
The trap is speed-only thinking. Redis being faster per lookup does not help if you would have to fetch every key and filter in your app.
Drills
Answer fast — trust the rule.
Which query is a poor fit for Redis?
Why can a Redis key lookup be faster than a SQL query for the same single value?
The game history is 2 TB and grows every day. Where should it live?
What does Redis lack that a SQL database provides?
Remember
- Redis answers questions you can name by key; databases answer questions you describe.
- If you can say the key before you ask, it is a Redis question.
- Most apps use both: a durable database for records, Redis for the hot layer.