What Is Redis?
Redis is an open-source, in-memory data store that keeps information in RAM rather than on disk, which makes it extremely fast. Web applications use it mainly as a cache — storing results of slow queries or rendered pages so repeat requests return in microseconds — and to hold sessions, queues, and rate-limit counters. Because memory is volatile, Redis can optionally persist to disk, but its primary job is speed, not storage. It sits alongside a database like PostgreSQL or MySQL to offload work and keep busy sites fast.
- Type
- Open-source in-memory key-value data store, first released 2009
- Full name
- REmote DIctionary Server (redis.io)
- Speed
- Serves data from RAM, typically with sub-millisecond response times
- Common uses
- Caching, sessions, queues, pub/sub messaging, rate limiting, leaderboards
- Data types
- Strings, hashes, lists, sets, sorted sets, and streams (redis.io docs)
- Persistence
- Optional snapshot (RDB) and append-only file (AOF) saving to disk
What Redis is #
Redis, short for Remote Dictionary Server, is an open-source data store that keeps its data in memory — in RAM — rather than on a hard disk. That single design choice is the source of its defining quality: extraordinary speed, with typical operations completing in well under a millisecond. At its simplest, Redis is a giant, ultra-fast key-value store, like a dictionary where you set a key and get its value back almost instantly, but it also supports richer structures such as lists, sets, and hashes. It is not usually a replacement for your main database; instead it works alongside one, handling the jobs where raw speed matters most. The most common of these is caching, where Redis remembers the answers to expensive operations so they do not have to be recomputed. For busy websites and applications, adding Redis is one of the highest-impact performance moves available, which is why it features so often in the work behind our /services/speed-optimization and /services/web-app-development pages.
Why caching speeds up a site #
Caching is Redis's flagship use, and understanding it explains why the technology matters. When a web page needs data — a list of products, a user's dashboard, the result of a complex calculation — it often has to ask the main database, which reads from disk and may run a heavy query. Doing that on every single request, for every visitor, is slow and puts the database under strain. A cache short-circuits this: the first time the data is computed, it is stored in Redis under a key, and subsequent requests read it straight from memory in microseconds instead of hammering the database again. Because many visitors request the same popular data, a cache can absorb the majority of the load, making pages feel instant and letting the database breathe. This is one of the most effective ways to speed up a database-heavy site, and it is a standard technique our /services/speed-optimization team applies when a busy site is bottlenecked by repeated, expensive queries.
Redis caching in practice #
Using Redis as a cache follows a simple set-and-get pattern; here it is illustrated with the redis-cli tool.
# Store a value under a key, expiring after 3600 seconds
redis-cli SET "user:42:profile" "{...json...}" EX 3600
# Later requests read it straight from memory
redis-cli GET "user:42:profile"
# Application logic (pseudocode):
# value = redis.get(key)
# if value is null:
# value = database.query(...) # slow path, runs once
# redis.set(key, value, ex=3600)
# return valueBeyond caching: sessions, queues and more #
Although caching is the headline use, Redis earns its place with several other jobs busy applications rely on. It is a popular store for user sessions — the small pieces of data that remember a logged-in visitor between page loads — because reading and writing them from memory is fast and easy to share across multiple servers. Its list and stream structures make it a lightweight job queue, so slow tasks like sending emails or generating reports can be pushed onto a queue and processed in the background rather than making the user wait. Redis also powers rate limiting, counting how many requests an IP has made to block abuse, and its publish/subscribe feature enables real-time messaging between parts of a system, useful for live notifications and chat. Sorted sets make real-time leaderboards trivial. These capabilities show up in the architecture of interactive applications and integrations built through our /services/api-crm-integrations and /services/web-app-development work, where speed and coordination between components are essential.
Data types Redis supports #
Part of what makes Redis more than a simple cache is its range of built-in data types, each suited to particular jobs. Strings are the basic key-value pairing and can hold text, numbers, or serialized JSON. Hashes store field-and-value maps under one key, ideal for representing an object like a user profile compactly. Lists are ordered sequences that make natural queues and stacks. Sets hold unique unordered items and support fast membership checks and intersections, useful for tags or tracking online users. Sorted sets add a score to each member so items stay ordered, which is what makes real-time leaderboards and priority queues so easy. Streams provide an append-only log for event data. Because these structures live in memory and have optimized commands, operations on them are extremely fast. Knowing which structure fits a problem is what separates a naive cache from a well-designed Redis layer, and it is part of the engineering that goes into the performant systems on our /services/web-app-development page.
Persistence and durability #
A common question is what happens to Redis data when the server restarts, since memory is volatile and normally loses everything on a power cut. Redis answers this with optional persistence. RDB snapshots periodically save the whole dataset to disk, giving a compact backup taken at intervals, while the append-only file (AOF) logs every write so the data can be rebuilt more completely after a crash, at the cost of larger files. You can use either, both, or neither depending on how important the data is. For pure caching, where the data can always be recomputed from the main database, many teams run Redis with minimal persistence because losing the cache simply means rebuilding it. For data Redis owns outright, like certain sessions or queues, durability settings matter more. Understanding that Redis complements rather than replaces a primary database is key: it is a fast layer in front, not the permanent record. Configuring persistence correctly for each use is part of responsible infrastructure setup on our /services/vps-cloud-setup page.
Redis versus a traditional database #
It is tempting to compare Redis directly with PostgreSQL or MySQL, but they solve different problems and usually work together rather than competing. A traditional relational database is your durable system of record: it stores everything permanently, enforces relationships, and answers complex queries, all reading from disk with strong guarantees. Redis is a fast, in-memory helper that stores a subset of data — typically frequently accessed or transient — to relieve the main database and accelerate specific operations. In a typical architecture, the relational database holds the truth, and Redis caches copies of hot data and handles sessions and queues. You would not store your only copy of critical business records in Redis alone, nor would you run expensive analytical reports through it. Using each for what it does best is the point. This layered approach — a durable database plus a Redis cache — is a standard, effective pattern in the systems our /services/database-services and /services/speed-optimization teams design for high-traffic sites.
Hosting and scaling Redis #
Running Redis in production means giving it enough memory, since it lives in RAM, and deciding how to keep it available. For a single server, Redis is lightweight and easy to install, but larger deployments use replication to keep backup copies, Redis Sentinel for automatic failover if the primary node dies, and Redis Cluster to shard data across many nodes for very large caches. Because managing all this is real work, many teams use a managed Redis service from a cloud provider, which handles memory sizing, failover, backups, and updates. Others run it on a configured virtual server alongside their application. The main operational risk is memory: if Redis fills its allotted RAM, it must evict data or refuse writes, so setting sensible memory limits and eviction policies matters. Standing up Redis reliably, whether managed or self-hosted, is part of the infrastructure work covered on our /services/vps-cloud-setup and /services/managed-hosting pages, where sizing and failover are planned rather than left to chance.
When a site benefits from Redis #
Not every site needs Redis, and adding it to a small brochure website is unnecessary complexity. The clear candidates are applications where the same data is requested repeatedly and computing it is expensive, where a database is straining under read load, or where features like sessions across multiple servers, background job queues, rate limiting, or real-time updates are required. A busy e-commerce store, a membership site, a SaaS dashboard, or any application feeling slow because of repeated heavy queries will usually see a dramatic improvement from a well-placed cache. The signal to consider Redis is a database bottleneck or a need for the specific jobs it excels at, not a desire to use trendy technology. If your site is sluggish and you suspect the database, an audit will reveal whether caching is the fix. Start with a review through /free-website-audit or reach out via /contact, and see /services/speed-optimization for how a caching layer like Redis fits into making a busy site feel instant.
FAQ
Is Redis a database or a cache?
Both, but it is used most often as a cache. Redis is technically an in-memory data store, and it can hold data it owns, such as sessions or queues. In most web architectures, though, it sits in front of a durable database like PostgreSQL or MySQL, caching frequently accessed data to speed up the site rather than replacing that database.
Why is Redis so fast?
Because it keeps data in RAM rather than on disk. Reading from memory is orders of magnitude faster than reading from a hard drive, so Redis operations typically complete in well under a millisecond. Its simple key-based access and optimized data-structure commands add to the speed, which is why it is ideal for caching and other latency-sensitive jobs.
Does my website need Redis?
Only if it has a reason for it. A small brochure site does not. But a busy database-heavy application, a store, a membership site, or anything straining under repeated expensive queries usually benefits greatly from Redis caching. It also helps when you need shared sessions, job queues, rate limiting, or real-time features across multiple servers.
What happens to Redis data if the server restarts?
By default in-memory data would be lost, but Redis offers optional persistence: RDB snapshots save the dataset periodically, and the append-only file logs every write for fuller recovery. For pure caching, losing the data on restart is fine because it rebuilds from the main database. For data Redis owns, you enable persistence to protect it.
Is Redis free?
The core Redis software is open source and free to use and self-host. Commercial managed Redis services from cloud providers charge for the convenience of a hosted, scaled, and maintained instance, and some enterprise offerings add features and support. For most projects, you either self-host the free version or pay a modest fee for a managed service.
Can Redis replace my main database?
Generally no. Redis is a fast, in-memory layer meant to complement a durable database, not replace it. Your relational or document database remains the permanent, authoritative record with full querying and relationships, while Redis accelerates hot data and handles transient jobs. Storing your only copy of critical business data in Redis alone is risky and not recommended.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?