Redis database services for production teams.
JusDB provides Redis database services for scoped projects, ongoing remote DBA coverage, and production support. The work covers memory and latency tuning, Sentinel and Cluster failover, and migrations on Amazon ElastiCache, Amazon MemoryDB, Kubernetes, and your own servers. 24x7 on-call is available under your service agreement.
Or request a free audit of one database instance. Already in an incident? See how incidents are handled.
- NDA before access
- Read-only by default
- Changes measured against your baseline
Redis version status
Pick the version you run
Redis 8.10
Newest releaseThe newest minor release, generally available since July 2026, with security and critical fixes until six months after the next minor release.
Redis 8.10 adds the BACKUP command for online backups. Staying on standard releases means a minor upgrade within six months of each new one.
Plan a Redis upgradeRedis 8.2
Extended supportAn extended release, generally available since August 2025, with security and critical bug fixes until 1 September 2030.
The Redis 8 line for fewer upgrades, including for teams on 8.0, whose support ends no later than 1 December 2026. Redis 8 builds in search, JSON, and time series, and adds the AGPLv3 license option.
Plan a move to Redis 8Redis 7.2
Extended supportThe last Redis release under the BSD license, with security and critical bug fixes until 1 December 2029.
From 7.2 the paths split: Redis 7.4 moved to RSALv2 or SSPLv1, Redis 8 added AGPLv3, and Valkey continued under BSD.
Compare Redis and ValkeyRedis 6.2
Ends April 2027An extended release whose security and critical bug fixes end on 1 April 2027.
On Amazon ElastiCache, standard support for Redis OSS 6 ends on 31 January 2027, then clusters move to paid Extended Support.
Plan the upgrade off 6.2Version status from the Redis Open Source version management page, the Redis license page, Redis release notes, and Amazon ElastiCache, checked 28 October 2026.
- Platforms
- Amazon ElastiCache and MemoryDB, Google Cloud, Azure, your own servers, and Kubernetes
- High availability
- Redis Sentinel, Redis Cluster, ElastiCache Multi-AZ, and MemoryDB
- Incidents
- Initial-response targets are set in your service agreement. See the targets
Symptoms
Eight Redis problems we are asked to fix
Each one has a cause we can measure. The scoping call starts from the symptom you see.
Latency spikes every time a snapshot runs because the fork behind BGSAVE or an AOF rewrite runs on the main thread, and transparent huge pages make it worse.
One slow command stalls every client because Redis runs commands one at a time, so KEYS or a DEL on a huge key blocks everything behind it.
Writes fail with OOM errors at the memory limit because the default policy, noeviction, rejects new data, and the volatile policies do the same when no key has a TTL.
The kernel kills Redis during a background save because maxmemory was never set, and under heavy writes copy-on-write can double memory use during the save.
Replicas keep falling back to full resyncs after a write burst trips the replica output buffer limit or outruns a replication backlog still at its 1 MB default.
After a failover, the application still writes to the old primary because clients use a fixed address instead of asking Sentinel, and those writes are discarded when it rejoins.
Multi-key commands fail with CROSSSLOT errors on Redis Cluster because the keys hash to different slots, and only a shared hash tag keeps related keys in one slot.
The upgrade off 6.2 or 7.0 keeps slipping because Redis 7.4 changed the license, and 7.0 changed ACL Pub/Sub defaults and the AOF layout.
If one of these is costing your team time, a scoping call is the place to start.
Book a 30-min scoping call (opens Google Calendar in a new tab)Failover
How a Redis failover can lose acknowledged writes
Redis replicates asynchronously, so the primary confirms a write to your application without waiting for any replica to receive it. If the primary fails at that moment, Sentinel or Redis Cluster can promote a replica that never received the write.
One primary, two replicas, three outcomes
Choose a state to see where the writes go.
Application and routing
Clients ask Sentinel for the current primary and write there.
Primary
Replies to each write without waiting for replicas
Healthy
Replica 1
Reports its replication offset every second
Current
Replica 2
A little behind during write bursts
Slightly behind
The primary replies without waiting for the replicas, so the newest writes can exist only on the primary.
Application and routing
Application servers cut off with the old primary keep writing to it through a fixed address.
Old primary
Cut off by the partition, still accepting writes
Writes discarded later
Replica 1, promoted
Missing the last writes the old primary acknowledged
Missing writes
Replica 2
Resyncing from the new primary
Catching up
Your application was told those writes were saved, but when the partition heals, the old primary becomes a replica and discards them.
Application and routing
Clients ask Sentinel for the primary on reconnect, so they follow the failover.
Old primary
Refuses writes 10 seconds after losing its replicas
Refusing writes
Replica 1, promoted
Had the highest replication offset, so Sentinel chose it
New primary
Replica 2
Repointed to the new primary by Sentinel
Following
With min-replicas-to-write 1 and min-replicas-max-lag 10, a cut-off primary stops taking writes after 10 seconds. Writes acknowledged just before a failure can still be lost, even with WAIT.
We decide per workload how much write loss is acceptable, because a cache and a job queue need different answers. We limit the loss window with min-replicas-to-write and min-replicas-max-lag, and use WAIT where a write needs a replica copy first. We connect clients through Sentinel instead of a fixed address.
We alert on master_link_status and full resyncs, and rehearse failover on a copy before production depends on it. On ElastiCache, we drill failover with the TestFailover API. Where an acknowledged write must survive a failover, we assess Amazon MemoryDB, which AWS documents as logging each write across Availability Zones before confirming it.
What we cover
Full-spectrum Redis engineering
SLOWLOG, the latency monitor, and INFO drive every change, from one blocking command to a move onto Redis Cluster, measured against your baseline.
Latency and memory profiling
We find what blocks the main thread before changing anything, and size memory from INFO.
- SLOWLOG and the latency monitor
- Big and hot keys found with redis-cli scans
- maxmemory and eviction set per workload
Cluster and Sentinel HA
Failover designed around the data loss and downtime you can accept (RPO and RTO), then drilled on a copy.
- Three or more Sentinels in separate failure zones
- Redis Cluster slot layout and hash tags
- Switchovers with SENTINEL FAILOVER or CLUSTER FAILOVER
Redis expertise
Advanced data structures that keep commands cheap, and short Lua scripts, because a running script blocks every client.
- Data types chosen per access pattern
- Lua and Redis Functions checked for long runs
- Search, JSON, and time series in Redis 8
Security and encryption
Access, encryption, and network settings reviewed against the controls your auditors ask about.
- Least-privilege ACL users for each application
- TLS for clients, replication, and the cluster bus
- Admin commands such as FLUSHALL blocked for applications
Pub/Sub and event streams
Pub/Sub delivers at most once, while Streams store messages and track what each consumer group acknowledged.
- Consumer groups with XACK and XAUTOCLAIM
- Sharded Pub/Sub on Redis Cluster
- Output buffer limits for slow subscribers
Upgrades and platform moves
Version upgrades and platform moves with a tested way back (a rollback plan).
- Upgrades off 6.2 and 7.0, tested on a copy
- Moves between servers, ElastiCache, MemoryDB, and Kubernetes
- A license review before Redis 7.4 or 8
Incident support
A critical (P1) page, answered within your agreement's target
JusDB keeps your recovery procedures (runbooks) written down, so an incident starts from a known plan instead of a blank page.
Initial-response targets
2 to 4 hours
Business hours
During covered business hours
30 minutes
24x7 on-call
P1 incidents
Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.
Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.
What happens on a P1 page
Page
You page the on-call engineer
Through the escalation path your service agreement names.
Triage
Root cause from INFO, SLOWLOG, and the latency monitor
Slow commands, fork stalls, memory pressure, and broken replication traced to the command or setting behind them.
Mitigate
Stabilize first, from the runbook
Disconnect the client sending slow commands, pause the job flooding writes, or fail over to a current replica, then fix the cause once production is steady.
After
A review after every P1
What happened, why, and the change that stops it happening again.
Before and between incidents
- Your setup, written down firstDuring onboarding we record your versions, topology, persistence, eviction settings, and clients, so incidents start with context.
- One escalation path, in writingYour service agreement names the on-call contact, the hours, and the Redis deployments covered.
- Reviews between incidentsWe review latency, memory headroom, replication, and restores, and report open risks with next steps.
- Version dates trackedWe track Redis and ElastiCache support dates for the versions you run, and plan upgrades before support ends.
Process
How a Redis engagement runs, step by step
Written findings come before any change. Your team approves production changes, except routine actions you have pre-approved.
Scoping call
Your Redis deployments, versions, platforms, and what you need covered.
Read-only review under NDA
Our engineers use named accounts with only the permissions the review needs, then read your configuration, INFO, SLOWLOG, latency history, and Sentinel or Cluster state.
A written report before any change
Each finding comes with the change we propose, how we will measure it, and a way to undo it (a rollback plan).
Changes, then handover
We rehearse risky changes on a replica or a copy, apply them in the windows you approve, measure them against the baseline, and hand over updated operating instructions (runbooks).
Step one is a 30-minute scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Ways to work
Choose the Redis service your team needs
Start with the responsibility you need covered. Each engagement has its own scope, deliverables, access requirements, and acceptance criteria.
Projects
Scoped Redis projects
A defined piece of work with written findings, hands-on changes, and validation against your baseline.
- Redis consultingProduct, topology, and licensing decisions, with a written recommendation.
- Migration and upgradesVersion upgrades and moves between your servers, ElastiCache, and MemoryDB, with a rollback plan.
- Redis on KubernetesSentinel or Cluster on Kubernetes, with storage and failover planned per workload.
Ongoing
Ongoing coverage and support
JusDB monitors the databases, carries out the agreed maintenance, and responds to incidents during the coverage the proposal names. The team keeps a change record, recovery procedures, and a review after every P1.
Where your Redis runs, and the tools around it
Your team and ours
What a managed Redis service still leaves to your team
Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions.
| Question | Managed cloud service | Your own servers or Kubernetes |
|---|---|---|
| Servers, patches, and node replacement | The provider runs them. | Your team, or JusDB under your agreement. |
| Failover | The provider runs it. Your clients still have to reconnect cleanly. | You run Redis Sentinel or Redis Cluster, with write limits that narrow the loss window. |
| Persistence and backups | Snapshots are built in, but ElastiCache does not support AOF for Redis OSS, and restore tests are still yours. | Your team picks RDB, AOF, or both, and tests a restore. |
| Memory, eviction, and slow commands | Yours. The provider runs the nodes, not your keys or commands. | Yours. |
| Versions and end of life | The provider's calendar. Past standard support, ElastiCache enrolls clusters in paid Extended Support. | Your calendar. Fixes stop at each line's end-of-life date. |
| Moving off later | ElastiCache allows no external replicas, so data leaves as an RDB backup exported to Amazon S3. | Replication to the new target, with writes paused at cutover. |
Your team keeps control
- Set business priorities, application requirements, and release plans
- Approve production changes, except routine actions you have pre-approved
- Own your cloud accounts, access policies, and vendor relationships
- Decide when maintenance can happen and how quickly service must recover
- Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)
JusDB handles the agreed database work
- Monitor database health, investigate alerts, and involve the right people
- Review query performance, replication, capacity, and backup health
- Carry out approved changes and update the operating instructions they affect
- Report completed work, open risks, and recommended next steps
Weighing a managed service against running Redis yourself? We compare both against your workload on a scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Further reading
Redis guides and two comparisons
Guides from our blog on failover, persistence, Cluster, and tuning, plus two comparisons.
Guide
Redis Sentinel vs Redis Cluster
How each one fails over, what Cluster changes for multi-key commands, and how to choose.
Guide
Redis persistence: RDB and AOF
Snapshots, the append-only file, the hybrid mode, and what each one means for recovery.
Guide
Redis Cluster sharding and failover
Hash slots, replicas, failover, client routing, and cluster health checks.
Guide
Redis performance tuning
Latency layers, big and hot keys, eviction, persistence cost, and connection overhead.
Comparison
Redis vs Valkey
When each one fits, how the license change affects you, and the migration paths between them.
Comparison
Redis vs Memcached
Data structures, persistence, and threading compared, with the migration paths between the two.
FAQ
Common Redis questions
What buyers ask about Redis persistence, latency, failover, memory, and ElastiCache.
Still have a question?
Ask it on a scoping call. No production access needed.
Book a 30-min scoping call (opens Google Calendar in a new tab)How do you tune Redis persistence so a snapshot does not stall the primary?
JusDB measures how long each snapshot's fork takes, from latest_fork_usec in INFO. We set vm.overcommit_memory to 1, turn off transparent huge pages, and leave headroom for copy-on-write, which can double memory use under heavy writes. Where the primary cannot afford the fork, we snapshot on a replica. If the primary then runs without persistence, we turn off its automatic restart, because a primary that restarts empty also empties its replicas.
How do you achieve sub-millisecond p99 latency in production Redis?
JusDB does not promise a latency figure, because p99 depends on your commands, value sizes, network, and hardware. We measure the server's own latency floor with redis-cli --intrinsic-latency, then remove what blocks the main thread: SCAN replaces KEYS, and UNLINK replaces large deletes. We measure each change against your baseline.
When should we use Redis Cluster vs Redis Sentinel?
JusDB recommends Redis Sentinel when your data and write load fit on one primary, which Sentinel watches and fails over. Redis Cluster splits keys across 16,384 hash slots on several primaries, so memory and writes scale past one server. A multi-key command then needs all its keys in one hash slot, so related keys share a hash tag. Both replicate asynchronously, so neither keeps every acknowledged write through a failover.
How do you prevent Redis out-of-memory (OOM) crashes?
JusDB sets maxmemory below the server's RAM, because Redis has no memory limit by default on 64-bit systems. We leave headroom for replication and AOF buffers, copy-on-write, and fragmentation, which maxmemory does not count, and pick the eviction policy per workload. We alert on evicted_keys and mem_fragmentation_ratio before the limit is reached.
Can you migrate Redis from AWS ElastiCache to self-hosted Redis?
Yes. JusDB plans the move around one ElastiCache limit: it allows no external replicas. Data leaves as an RDB backup exported to Amazon S3, while your application pauses or double-writes later changes. The cutover runs in a rehearsed window with a rollback plan, and JusDB does not promise one cutover duration. Moves to Valkey are scoped on the Valkey migration page.
Next step
Talk to a Redis engineer about your databases
Tell us what is slow, fragile, or due to change. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.
NDA before access, read-only by default, and written scope first
Compare with other databases
If you are weighing alternatives, these are the databases most often compared with this one.
Valkey
The Linux Foundation fork of Redis 7.2.4, created after the March 2024 license change. It speaks the same protocol, and Amazon ElastiCache and MemoryDB offer it.
Dragonfly
A Redis-protocol-compatible store built for multi-core servers, with a multi-threaded, shared-nothing design.
Aerospike
When resharding and memory limits take up most of the operations work, teams evaluate Aerospike's hybrid memory and flash storage.
MongoDB
Redis as the cache in front of MongoDB as the primary store is a common pattern for read-heavy session and catalog data.