Valkey · Cluster · Sentinel · BSD-3Valkey, truly open source, truly fast.
Valkey is a high-performance, open-source in-memory data store created as a BSD-3-licensed fork of Redis 7.2 under the Linux Foundation. JusDB delivers end-to-end Valkey reliability engineering, seamless zero-downtime Redis migrations, Cluster slot sharding, Sentinel high availability, and 24/7 managed operations backed by an enterprise 99.99% uptime SLA.
We run production Valkey services across the lifecycle: deploy, migrate, operate, and support. That covers seamless Redis migration, cluster setup, and performance optimization. Valkey matches the Redis 7.2 command set and the RESP protocol, and it stays truly open source.
JUSDB_VALKEY_PRODValkey 8 · cluster
Redis-compatible (RESP) · multi-threaded I/O
0.00M
98.5%
0
0
Ops Throughput
0.00M ops/s[OK] valkey: multi-threaded I/O, 8 io-threads active
[INF] repl: replica-02 in sync via RESP, offset caught
[OK] compat: RESP3 drop-in, no client changes
[INF] maxmemory-policy allkeys-lru, 58% used
Representative fleet view · illustrative metrics
0+
Valkey Instances Managed
0.99%
Uptime SLA
0M+
Peak Ops / sec
0%
License Cost Removed
What we do
Valkey engineering
End-to-end Valkey services: deploy, migrate, operate, and support. Our team understands in-memory data stores inside out.
Cluster Setup
Design and deploy high-availability Valkey clusters with automatic sharding and failover.
Redis Migration
Seamless migration from Redis to Valkey with zero downtime and full data integrity.
Performance Optimization
Memory optimization, latency tuning, and throughput maximization for your workload.
High Availability
Sentinel and cluster configuration for automatic failover and zero-downtime operations.
Data Persistence
RDB snapshots, AOF logging, and hybrid persistence configuration for durability.
Monitoring & Alerting
Real-time metrics, dashboards, and proactive alerting for optimal operations.
In-memory performance
Valkey expertise
Deep Valkey engineering across deployment, migration, and operations, from the team that understands in-memory data stores inside out.
Cache Performance
After tuning2×
Throughput vs Redis
$0
License cost
Real cases
Workloads we've transformed
Licensed
$0
Redis SSPL license risk on every node
The fix
Drop-in swap, zero client code change
1.4M ops
3.1M ops
Single-threaded I/O bottleneck
The fix
Enabled io-threads on Valkey 8, 2× throughput
5,800ms
0.3ms
KEYS * blocking on 220MB hash
The fix
Replaced KEYS with cursor-based SCAN
0.00%
Cluster Uptime
<0s
Failover RTO
0ms
Replica Lag
High availability
Always on. Cluster-engineered.
We run Valkey Cluster with automatic sharding and built-in quorum failover between primaries, and Sentinel quorum-based failover for single-primary deployments. Where a second datacenter is in scope, we design cross-datacenter replication as well. We rehearse the failover paths we build with drills. The goal is real 99.99% uptime, not a theoretical SLA.
Incident response
A hot-key P1, handled in under 15 minutes.
A hot key or an eviction storm can spike latency. When that happens, a named Valkey engineer responds, not a ticket queue. Hot-key remediation and eviction tuning are applied online. A blameless postmortem follows.
used_memory hit maxmemory — OOM evictions spiking
Named Valkey engineer in under 15 min, not a queue
Big key — 220MB hash scanned by KEYS *
Swapped KEYS→SCAN, tuned io-threads + allkeys-lru
Evictions cleared, p99 80ms → 0.3ms — total 10 min
Information Gain · High-Consequence In-Memory Edge Cases
Valkey Engine Internals: Critical Failure Modes
Transitioning to Valkey and multi-threaded in-memory architectures unlocks massive throughput, but misconfigurations can cause subtle failure cascades. Here are the 3 engine failure modes our Valkey SRE team permanently remediates:
Threaded I/O Asymmetry & Socket Buffer Bottlenecks
While Valkey enhances multi-threaded I/O, improperly configuring io-threads relative to available vCPUs causes CPU thread thrashing and memory bus contention, degrading p99 latency beyond single-threaded baselines.
Benchmarking core pinning, setting io-threads to 75% of physical cores (excluding hyperthreads), enabling io-threads-do-reads yes, and isolating background fsync threads.
Cross-Slot Multi-Key Script Execution in Valkey Cluster
Executing transactions (MULTI/EXEC) or Lua scripts containing keys that hash to different slots across cluster nodes triggers instant CROSSSLOT errors, breaking application transactions.
Designing hash-tag schema partitions ({tenant_id}:session), enforcing client-side slot hashing routing, and implementing atomic Lua restructuring for clustered shards.
Replication Offset Drift & Sentinel Split-Brain During Partitioning
Network partitions isolate a primary node while Sentinel promotes a new primary. Without strict min-replicas-to-write configuration, the isolated master continues accepting client writes which are lost when connectivity heals.
Configuring min-replicas-to-write 1 and min-replicas-max-lag 10, enforcing odd-numbered 3+ Sentinel quorums, and testing network partition failover under load.
Our Valkey SREs execute read-only cluster and latency inspection routines to monitor 16,384 slot balance and command latency without impacting client throughput:
# Verify 16,384 cluster slots allocation and cluster state valkey-cli -p 6379 cluster info | grep -E "cluster_state|cluster_slots_assigned|cluster_slots_ok|cluster_known_nodes" # Audit master-replica synchronization offset and connected nodes valkey-cli -p 6379 INFO replication | grep -E "role|connected_slaves|master_repl_offset|second_repl_offset"
# Inspect latency spikes recorded by internal engine latency monitor valkey-cli -p 6379 LATENCY LATEST # Retrieve slowest commands exceeding latency thresholds valkey-cli -p 6379 SLOWLOG GET 10
Comparative Matrix · Valkey & Open-Source In-Memory
How JusDB Valkey Services compare to alternative options.
Adopting Valkey grants full BSD-3 open-source freedom, but production resilience demands deep expertise in multi-threaded I/O, slot sharding, and failover topologies. Here is how JusDB compares to managed cloud offerings, generic MSPs, and internal teams.
| Engineering Dimension | JusDB Valkey SRE | AWS Managed Valkey | Generic MSPs | In-House Devs |
|---|---|---|---|---|
| Open-Source Freedom & Licensing Security | Permissive BSD-3 license under Linux Foundation stewardship, zero risk of AGPL/SSPL copyleft contamination or vendor licensing surcharges | AWS offers managed Valkey alongside proprietary services, but pushes workloads toward higher-margin closed systems | Treats Valkey as identical to Redis without reviewing client driver dependencies or license boundary guarantees | Confusion around Redis 7.4/8.0 license transitions leaving infrastructure exposed to licensing compliance audits |
| Redis to Valkey Zero-Downtime Migration | Dual-sync replication pipelines, pre-migration command audit, rollback safeguards, and sub-1-minute cutover without cold cache penalties | Console migration wizard available for simple instances, but fails on high-write clusters or cross-region setups | Requires multi-hour maintenance downtime windows to export RDB snapshots and re-import data | Manual DNS flip causing cache stampedes, massive backend database connection spikes, and service degradation |
| Multi-Threaded I/O & Throughput Optimization | Tuning Valkey multi-threaded I/O (io-threads), socket buffer sizing, and event-loop concurrency to achieve > 1.2M ops/sec per node | Standard instance presets without kernel network stack tuning (TCP backlog, somaxconn, THP disabling) | Leaves default single-threaded configurations in place, capping throughput on modern multi-core cloud instances | Misconfigured io-threads causing CPU thread contention and higher p99 tail latency than default settings |
| Cluster Sharding & Cross-Slot Transaction Guard | 16,384 slot distribution modeling, hash-tag ({tenant_id}) schema partitioning, and automated multi-shard rebalancing | Slot resharding API provided without assistance for fixing CROSSSLOT transaction errors in application code | Unfamiliar with Valkey cluster gossip protocol and multi-master partition recovery procedures | Arbitrary slot allocations leading to severe memory skew and hot-node eviction storms |
| 24/7 SLA & Direct Principal SRE War Room | Contractual 15-minute Sev-1 first response with direct Slack/Teams bridge to named Valkey Principal SREs | Tiered ticketing system; Sev-1 tickets often routed through automated troubleshooting bots before reaching human engineers | Generic NOC technicians operating from static runbooks without deep in-memory engine diagnostic tooling | Developers burnt out handling recurring eviction alerts and cluster failover failures outside business hours |
| Cost Optimization & Cloud Independence | Deployable on self-hosted Kubernetes, bare metal, AWS, GCP, or Azure without proprietary cloud memory tax | Cloud providers price managed memory at steep markups and charge for egress between cluster shards | Recommends over-provisioning memory capacity rather than tuning memory allocation and data structure efficiency | Inflated cloud bills due to oversized cache nodes running with high memory fragmentation |
Pre-Migration Assessment
Redis → Valkey (drop-in, RESP-compatible)
Estimated cutover window: < 5 minutes
Migration
Move from Redis without the downtime
Redis 7.2 or ElastiCache Redis → Valkey 8. First we assess compatibility. Then we synchronize via replication or RDB/AOF snapshots. We validate in parallel, then cut over with minimal downtime and full data integrity.
Technology stack
Technologies We Work With
Complete Valkey ecosystem and integration tools
FAQ
Common questions about Valkey, Redis compatibility & migration
Frequently asked questions about Valkey services and Redis-to-Valkey migration
What is Valkey and how does it differ from Redis?
Valkey is an open-source fork of Redis 7.2.4, hosted by the Linux Foundation. It was created after Redis changed to a more restrictive license. Valkey keeps the BSD-3 license, so it stays truly open source. It is fully compatible with Redis clients and protocols, and community-driven with contributions from AWS, Google, Oracle, and others.
Is Valkey fully compatible with Redis?
Yes, Valkey maintains full API compatibility with Redis. Your existing Redis clients, libraries, and applications will work with Valkey without modification. Commands, data structures, and protocols are identical. That makes migration seamless.
How do you migrate from Redis to Valkey?
Our migration process starts with a compatibility assessment. We then synchronize data using replication or RDB/AOF snapshots. Next we update connection strings and validate with a parallel run. Cutover follows with minimal downtime, and we ensure data integrity throughout the process.
What's the licensing difference between Valkey and Redis?
Redis moved off the BSD license in 2024 to RSALv2 and SSPLv1, and Redis 8 later added AGPLv3 as a third option. Those terms mainly restrict offering Redis as a competing managed service rather than commercial use in general. Valkey uses the permissive BSD-3 license, which allows free use in any context, including cloud services, commercial products, and internal deployments.
Can you help with Valkey cluster setup?
Yes. We specialize in Valkey Cluster deployments, including shard configuration and slot distribution. We also handle replication setup, automatic failover, and cross-datacenter replication. For non-cluster deployments, we configure Valkey Sentinel for high availability.
What monitoring solutions do you recommend for Valkey?
We set up monitoring using Prometheus, Grafana, and Valkey's built-in metrics. We track memory usage, hit rates, replication lag, connection counts, and command latency. We tune custom alerting to surface issues early, so your team can act before users feel the impact.
Get started
Ready to Embrace Open Source Caching?
Whether you're migrating from Redis or building new caching infrastructure, our Valkey experts will help you achieve sub-millisecond performance with true open-source freedom.
Deep dives
Specialized Valkey Services
Each service below owns a distinct production intent: strategy, execution, ops, or incident. Pick by what you actually need to ship.
Consulting
Architecture review, migration strategy, cost modeling. Written recommendations, not runbooks.
Redis → Valkey Migration
Replication-based zero-downtime cutover from Redis 7.2 or ElastiCache Redis to Valkey 8.
Performance Tuning
Memory policies, eviction, persistence latency, hot-key remediation. Sub-ms p99 reads.
Cluster Mode
Multi-shard sizing, 16,384-slot rebalancing, MOVED/ASK redirection, cross-region federation.
High Availability
Sentinel quorum, replica lag monitoring, split-brain prevention, automated failover.
Valkey on Kubernetes
Valkey Operator, Helm charts, StatefulSets, persistent volumes. Production K8s deployments.
Remote DBA
Continuous 24/7 managed ops, capacity planning, patching. 99.99% uptime SLA.
24/7 Support
Reactive incident response, 15-min SLA on production-down. Hourly retainer or pay-per-incident.
Compare with Other Databases
JusDB operates production fleets across most major engines. If you're weighing alternatives, here are the most common ones our customers compare against.
Redis
The upstream Valkey forked from. Useful for comparing release cadence, persistence behavior, and ecosystem maturity.
Dragonfly
Single-binary Redis-protocol KV store using a modern thread-per-core design — competitive with Valkey on multi-core throughput.
Aerospike
Larger-than-memory workloads where Valkey's RAM-bound model breaks down — Aerospike's hybrid storage handles 10×+ data volume per node.
MongoDB
Common pairing: Valkey for sub-ms cache reads, MongoDB as the document store of record for the same entities.
Explore Our Valkey Services
Explore more ways our Valkey experts can help with your database infrastructure.