What is Redis?
Redis is an in-memory data store. It keeps data in memory rather than on disk, which is why it answers in well under a millisecond and handles very high operation rates. It is used as a cache, a session store, a message queue and a real-time analytics store, and it holds more than plain strings: lists, sets, sorted sets, hashes, streams and HyperLogLog.
The mental model that gets people furthest: it is not a smaller relational database. It is a set of data structures you can share across processes over the network, and its usefulness comes from picking the right one for the problem.
What it is genuinely good at
Caching. The original use, and still the one that pays for itself fastest. A result your application computed expensively is worth keeping until it goes stale.
Session state. Web sessions want fast reads, an expiry and a store shared across application instances. That is exactly what Redis offers.
Rate limiting and counters. Atomic increments with expiry are a few lines and correct under concurrency, which is harder than it looks in a relational database.
Queues and streams. Lists give a simple work queue; streams give consumer groups and acknowledgement for something closer to a message broker. Past the point where the queue is load-bearing, RabbitMQ is built for the job.
Leaderboards and ranking. Sorted sets do exactly this, and doing it in SQL is a poor trade.
What it is not
It is not durable in the way a database is. Persistence options exist, and they are a safety net rather than a guarantee. Data whose loss you could not tolerate belongs in something that was designed to keep it, such as PostgreSQL.
It is not a primary store for relational data. No joins, no schema, no constraints. Modeling a relational problem in it is possible and unpleasant.
Memory is the budget. The dataset lives in RAM, so capacity is priced per gigabyte of memory rather than disk. Caching everything is a common and expensive instinct.
If all you want is a cache, look at Memcached first
Redis is often adopted for caching alone, and for that job it has a smaller competitor worth knowing about. Memcached describes itself as a distributed memory object caching system: an in-memory key-value store for small chunks of arbitrary data, intended for speeding up dynamic web applications by taking load off the database. Its own pitch is that the simple design is the feature.
That is the trade in one line. Memcached does one thing; Redis does that plus the data structures, persistence options, streams and replication described above.
So the question is whether you will use the rest. If the answer is genuinely "we want to cache database results and nothing else", Memcached is less to learn and less to run. If sorted sets, rate limiting, session semantics or a queue are anywhere on the roadmap, adopting Redis now avoids running two things later.
The license question, which is the real news
This is the part a learner most needs and finds least often, so it is worth stating plainly.
Redis was BSD-licensed for most of its life. Redis Ltd. changed that. Redis Open Source, starting with Redis 8, is offered under a choice of three licenses: the Redis Source Available License v2, the Server Side Public License v1, or the GNU Affero General Public License v3. Redis's own licensing page states that RSALv2 is not an open source license; AGPLv3 is.
In response to the earlier change, Valkey was forked from Redis and placed under the Linux Foundation. It is BSD-licensed, and the project states plainly that Foundation backing is what keeps it that way. It is the same data structures and the same protocol.
What this means in practice:
- If you are choosing today, you are choosing between a project whose license its own vendor changed once, and a fork under a foundation whose license is the reason it exists.
- If you already run Redis, nothing broke. Older versions keep their old license and your application does not care.
- If your compliance function reviews licenses, this is a conversation you will have, and it goes better before the deployment than after.
We have no interest in telling you which way to go. We have an interest in you knowing the question exists, because a surprising number of teams adopt one of these without noticing there is a decision here at all.
What running it in production involves
- Memory limits and an eviction policy. Set both. A Redis instance with no eviction policy that reaches its limit starts refusing writes, and finding that out during a traffic peak is the standard way to learn it.
- Persistence, chosen deliberately. Snapshotting and append-only logging make different trade-offs between write cost and how much you lose. The default is a decision even when nobody made it.
- Failover. A single instance is a single point of failure for every service that caches in it. Replication with automatic promotion is the minimum for anything user-facing.
- Monitoring the right numbers. Memory used against limit, eviction rate, and cache hit rate. A cache with a low hit rate is costing money and returning nothing.
- Keeping it off the public internet. It is fast partly because it is simple, and its defaults assume a trusted network.
Where VSHN fits
VSHN operates Redis on Swiss cloud infrastructure from CHF 60 per month, with up to 99.99% SLA, backups, monitoring and 24/7 incident response, on Cloudscale, Exoscale and other providers. Servala offers self-service ordering if you would rather start without a conversation.
If the license question above is live for your organization, it is worth raising in the first call rather than the last, because it changes what we deploy rather than how we operate it.