Use case · Databases
Redis hosting
Redis is an in-memory data store, extremely fast because it keeps data in RAM, widely used for caching, sessions, queues, and real-time features. Hosting it well means ample memory — memory is everything — optional persistence for durability, and replication for availability. Self-hosted on dedicated EU hardware, Redis or its open-source fork Valkey gives speed, control, and sovereignty.
Key points
- Redis is an in-memory data store, extremely fast because it keeps data in RAM.
- It's widely used for caching, sessions, queues, rate limiting, and real-time features.
- Memory is everything: Redis holds data in RAM, so memory capacity is the main constraint.
- It usually complements a primary database as a fast layer, rather than being the sole datastore.
- Redis and its open-source fork Valkey are both widely self-hosted; we host either.
What is Redis, and why host it?
Redis is an in-memory data store — a database that keeps its data in memory rather than primarily on disk — which makes it extremely fast. Because reading and writing memory is far quicker than storage, Redis can serve operations in a fraction of the time a disk-based database takes, which is its defining advantage. It is widely used wherever speed matters: as a cache in front of slower systems, as a store for session data, as a queue or message broker, and for real-time features. Redis has become one of the most popular pieces of infrastructure for adding fast, in-memory data handling to applications.
Hosting Redis well means providing infrastructure suited to its in-memory nature, which differs from hosting a disk-based database. The dominant consideration is memory, since Redis holds its data in memory, so the amount of memory available largely determines how much Redis can hold and is the main constraint on it. Redis also has options for persistence and for availability and scaling that shape how it is deployed. This page focuses on Redis; the general considerations of database hosting apply and are covered on the database-hosting page, while what follows attends to what is particular about running Redis.
In-memory: why memory is everything for Redis
Redis keeps its data in memory, which is the source of both its speed and its central constraint: the amount of memory available determines how much data Redis can hold. Because Redis serves data from memory, its operations are very fast, but the data must fit in memory to be held, so a Redis instance can store only as much as its memory allows. This makes memory the primary resource for Redis — the more memory, the more Redis can hold, and running out of memory is the main limit a Redis deployment hits.
Sizing memory for Redis therefore means providing enough to hold the data Redis is meant to store, with the amount of data bounded by the memory available. Because Redis is often used for data that suits being held in memory — caches, sessions, and similar — the memory required depends on how much such data the application keeps in Redis, and the memory should be sized to it. When memory is exhausted, Redis must evict data or reject writes, depending on configuration, so provisioning adequate memory is central to a Redis deployment working as intended. We provide the memory a Redis workload needs, since for Redis, memory capacity is the resource that matters most and the one that bounds what it can do.
Data structures and use cases
Redis is more than a simple key-value store: it provides a range of data structures — strings, hashes, lists, sets, sorted sets, and others — that make it useful for many purposes beyond basic caching. These structures let Redis serve varied roles naturally: lists and sorted sets suit queues and leaderboards, sets suit membership and uniqueness checks, hashes suit structured records, and simple keys suit caching and counters. This range of data structures is part of why Redis is so widely used, since it can be applied to many patterns with operations suited to each structure.
The result is a broad set of use cases. Redis is commonly used as a cache in front of slower databases, holding frequently-accessed data in memory to serve it quickly; as a store for session data that needs fast access; as a queue or message broker passing work between parts of a system; for rate limiting, counting, and real-time features that benefit from fast in-memory operations; and for publish-subscribe messaging. Understanding this breadth clarifies what Redis is for: a fast, in-memory store whose data structures and speed suit it to caching, coordination, and real-time work across many applications, wherever fast in-memory data handling helps.
Redis usually complements a primary database
It is worth being clear that Redis is usually a fast layer complementing a primary database, rather than the sole store of an application's data. Because Redis holds data in memory, it is typically used for data that suits being fast and, often, transient or reconstructable — caches, sessions, and the like — while the durable system of record remains a disk-based database such as a relational or document database. Redis speeds things up and handles fast, in-memory patterns; the primary database holds the authoritative, durable data. This division is the common and sensible way Redis is used.
Understanding this clarifies how Redis fits into an application's infrastructure and what to expect of it. Treating Redis as a complement — a fast cache and coordination layer alongside a durable primary database — matches its strengths, whereas treating it as the sole durable store for critical data would lean on it in ways its in-memory design is less suited to, unless persistence is carefully configured. There are uses where Redis holds primary data with persistence, but the typical, sound pattern is Redis as the fast layer beside a durable database. We host Redis in this role and alongside the primary databases it complements, providing the fast in-memory layer as part of an application's data infrastructure.
Persistence and durability
Although Redis is in-memory, it offers persistence options so that its data can survive restarts and be recovered, which matters where the data in Redis should not simply vanish on a failure. Redis can persist data to storage in more than one way: taking periodic snapshots of the dataset, and keeping a log of write operations that can be replayed to reconstruct the data. These mechanisms let Redis recover its data after a restart or failure, rather than losing everything held only in memory, giving a degree of durability to an in-memory store.
Choosing how to configure persistence depends on how important durability is for the data in Redis and the trade-offs involved. Snapshotting periodically means the most recent changes since the last snapshot could be lost on a failure, while logging every write gives stronger durability at some cost to performance and storage; the two can be combined. For a pure cache holding reconstructable data, persistence may matter little; for data whose loss would be more costly, stronger persistence is warranted. When we host Redis, providing fast storage for its persistence and helping configure it to the durability the data needs is part of the service, so that Redis's in-memory speed is paired with the durability appropriate to what it holds.
High availability and scale
Redis provides mechanisms for high availability and for scaling, so a Redis deployment can be made resilient and can grow beyond a single instance. For availability, Redis supports replication — keeping replica copies of the data — and arrangements that detect a primary's failure and promote a replica to take over, so the deployment survives an instance failing. For scale, Redis can be run in a clustered mode that distributes data across multiple instances, allowing a dataset and load larger than one instance can handle to be spread across several.
Deploying Redis for availability or scale therefore means running it across multiple instances in the appropriate arrangement. Replication with automatic failover keeps Redis available through the failure of an instance; clustering distributes data across instances for scale beyond one. The right arrangement depends on whether availability, scale, or both are needed, and how large the data and load are. Running these multi-instance configurations needs the several servers they involve, ideally arranged so a single failure does not affect several. When a Redis deployment requires high availability or scale, we provide the infrastructure its replication or clustering needs, so that Redis can be made resilient and scaled as the workload requires.
Redis, Valkey, and licensing
Redis's licensing has changed in recent years, and it is worth being clear about the current situation. Redis was permissively licensed for most of its history, then in 2024 moved to source-available licensing, and in 2025, with its version 8, added an open-source licence option again alongside the source-available ones, so current Redis is available under a choice of licences including an open-source one. For most organisations self-hosting Redis for their own application — as a cache or store for their own use — these licensing terms generally permit normal use; the stricter obligations of some of the licences mainly concern those who modify Redis and offer it to others as a service.
The licensing changes also prompted Valkey, an open-source fork of Redis governed by a foundation and permissively licensed, which is wire-compatible with Redis and widely adopted as a drop-in alternative. Valkey behaves like Redis, works with the same clients and protocol, and is fully open-source, which has made it a popular choice for those wanting a permissively-licensed option. For self-hosting, Redis and Valkey serve the same role and are hosted the same way, and the choice between them comes down to licensing preferences and the specific features each offers. We host both Redis and Valkey, since they share the same hosting needs and the choice is the user's; what this page describes applies to both.
Self-hosted, sovereign, and where we fit
Self-hosting Redis or Valkey on infrastructure you control gives control over the deployment and, on EU infrastructure, sovereignty over the data it holds. VV Internet Hosting is incorporated in the Netherlands, within the EU, so Redis or Valkey self-hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act, on infrastructure you control. Even though much Redis data is transient, it can include session data and other personal or sensitive information, so keeping it in the EU on controlled infrastructure keeps that data under European law.
We host dedicated infrastructure for self-hosting Redis or Valkey: ample memory sized to the data, fast storage for persistence, dedicated resources free of noisy neighbours, and the multiple servers replication or clustering need — in EU datacenters under European jurisdiction. This suits organisations self-hosting Redis or Valkey that want speed, control, and European sovereignty, running it as the fast in-memory layer alongside their primary databases. We are clear about our limits: we provide the dedicated infrastructure you run Redis or Valkey on, not a fully managed Redis service that operates it for you. If you want a fully managed in-memory data service, that is a different offering. We are the dedicated, sovereign infrastructure for self-hosting Redis or Valkey — and if that fits your needs, we can host it well.
Related use cases
See also
Questions
Redis, answered plainly
Common questions about hosting for Redis.
Why is Redis so fast?
Because it keeps its data in memory rather than primarily on disk. Reading and writing memory is far quicker than storage, so Redis serves operations in a fraction of the time a disk-based database takes. This in-memory design is its defining advantage — and it makes memory capacity the main constraint, since the data must fit in memory to be held.
Is Redis a replacement for my main database?
Usually not — Redis is typically a fast layer complementing a primary database, not the sole store. It holds data that suits being fast and often transient (caches, sessions), while the durable system of record stays a disk-based database. Redis can persist data, but the common, sound pattern is Redis as the fast in-memory layer beside a durable primary database.
What is Valkey, and do you host it?
Valkey is an open-source, permissively-licensed fork of Redis, governed by a foundation and wire-compatible with Redis, which emerged after Redis's licensing changes. It behaves like Redis, works with the same clients, and is a popular drop-in alternative. We host both Redis and Valkey — they share the same hosting needs, and the choice between them is yours.
Planning Redis infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.