Redis VPS sizing starts with peak memory, not average dataset size. Redis is an in-memory system, so a workload that reaches 10 GB during a peak cannot be safely planned as a 5 GB database simply because its average is smaller. You also need headroom for process overhead, fragmentation, persistence/replication buffers and the operating system.
What consumes memory on a Redis VPS?
- keys and values;
- data-structure overhead;
- allocator fragmentation;
- replication/AOF buffers;
- client connections;
- modules if used;
- operating-system memory.
Redis documentation notes that maxmemory is not necessarily the exact RSS ceiling of the process. Leave headroom rather than allocating every gigabyte of the VPS to the dataset.
Set maxmemory deliberately
For cache workloads, set maxmemory so Redis cannot consume the entire host. Redis then applies the configured eviction policy when the dataset crosses that limit. For 64-bit Redis, leaving maxmemory unlimited can allow the process to grow until the operating system itself becomes pressured.
Choose the eviction policy around data semantics
| Policy | When it can fit |
|---|---|
allkeys-lru | General cache where old/less-used keys may be discarded. |
allkeys-lfu | Cache where frequency is a better predictor than recency. |
volatile-* | Only keys with TTL are eligible for eviction. |
noeviction | Writes should fail instead of deleting data when memory is exhausted. |
Do not use an eviction policy to hide an undersized production database whose data is not safely reconstructable.
Cache vs primary data store
A Redis cache can usually evict data because the authoritative copy exists elsewhere. A Redis instance acting as a queue/session/state store can have very different durability requirements. Decide whether lost keys are acceptable before choosing persistence and eviction.
Persistence: RDB vs AOF
Redis Open Source supports RDB snapshots, AOF logging, both, or no persistence. RDB creates point-in-time snapshots. AOF records write operations so the dataset can be reconstructed. These have different recovery, write-amplification and disk requirements.
Persistence does not eliminate backups. Copy durable recovery files to another failure domain and test restore procedures.
RAM headroom for persistence and replication
Redis documentation notes that replication and persistence use buffers not necessarily counted the same way as evictable dataset memory. Leave headroom when setting maxmemory so AOF/replication activity does not push the host into operating-system memory pressure.
CPU requirements
Redis command execution is fast, but high request rates, TLS, modules, large values and persistence can consume meaningful CPU. Monitor CPU plus latency under peak traffic instead of assuming all Redis workloads are trivial.
NVMe requirements
If Redis is used only as a disposable cache with no persistence, storage matters less. If RDB/AOF and backups are important, NVMe can improve persistence and restart/recovery behaviour. Measure AOF fsync and snapshot impact on application latency.
4 GB, 8 GB, 16 GB or 32 GB?
Size from peak used_memory, RSS and workload overhead. A practical planning method is:
- measure peak dataset memory;
- measure peak RSS;
- add expected growth;
- reserve OS/persistence/replication headroom;
- set maxmemory below the total VPS RAM accordingly.
An 8 GB VPS can be plenty for a small cache and inadequate for a 7 GB dataset with AOF and application services on the same node.
Separate Redis from the application?
Keeping Redis on the same VPS removes network overhead and simplifies operations, but it also creates resource contention and one failure domain. Separate Redis when memory usage is large, independent scaling is useful or application processes are competing for RAM.
Monitoring checklist
used_memoryand RSS;- evicted keys;
- keyspace hit/miss ratio;
- latency;
- connected clients;
- AOF/RDB status;
- replication lag;
- CPU and disk latency.
Bottom line
Redis VPS sizing is fundamentally a peak-memory exercise. Set a deliberate maxmemory, choose eviction based on whether keys are disposable, pick persistence based on recovery requirements and leave enough host RAM for buffers, the OS and growth.
Next step: compare StreamData VPS tiers using your peak Redis memory, persistence mode and replication requirement.
Frequently asked questions about Redis VPS sizing
How much RAM should be left outside maxmemory?
There is no universal percentage because the answer depends on persistence, replication, modules, client buffers and allocator behaviour. Measure RSS and Redis memory statistics under peak load, then leave enough operating-system and buffer headroom that persistence or replication cannot push the host into swap or OOM conditions.
Is an 8 GB VPS enough for Redis?
It can be plenty for a small cache and too small for a large durable dataset. Compare peak used_memory, RSS, expected growth and persistence/replication overhead with the VPS capacity. Do not size from a quiet-hour average.
Should Redis persistence files be the only backup?
No. RDB/AOF provide durability mechanisms for the Redis instance, but important recovery copies should also be stored independently and tested. Replication is not a substitute for historical backup because accidental writes or deletes can replicate too.