What is Valkey? The Redis-Compatible Engine Behind Your Next Cache Decision

Valkey is an open-source, BSD-licensed in-memory key-value data structure store designed as a high-performance alternative to Redis. When evaluating what is Valkey, backend engineers find an engine that preserves the Redis Serialization Protocol (RESP), supports existing client drivers, and maintains permissive open-source governance under the Linux Foundation.

For technical founders and infrastructure teams running cache, session, and rate-limiting workloads in 2026, the question of what is Valkey comes down to operational continuity and cost predictability. Understanding what is Valkey requires looking past branding shifts to inspect wire protocol compatibility, memory efficiency, governance stability, and deployment costs. Steada is a cost-first managed Valkey service—a Redis-compatible, BSD-licensed in-memory key-value store—for cost-sensitive production teams. Steada is independent of the Valkey project and the Linux Foundation.

The short answer: what is Valkey, and why it exists

Valkey originated in March 2024 as an open-source fork of Redis 7.2.4. The fork occurred after Redis Ltd. announced it would abandon the BSD-3-Clause license for future releases, moving Redis to dual proprietary licensing under the Server Side Public License (SSPLv1) and the Redis Source Available License (RSALv2). In response, maintainers, cloud providers, and enterprise contributors formed Valkey to keep an open-source, permissively licensed implementation available to the industry.

The Valkey project is hosted as a collaborative project under the Linux Foundation. Founding and participating organizations include Amazon Web Services, Google Cloud, Oracle, Ericsson, and Huawei, as documented in the official Linux Foundation announcement. This structure means project governance does not belong to a single commercial entity. A technical steering committee composed of long-time contributors sets development priorities, reviews pull requests, and maintains release schedules.

For application developers, Valkey is an in-memory data store speaking RESP2 and RESP3. Your application can connect using existing Redis clients, issue familiar commands such as GET, SET, HINCRBY, and ZADD, and handle cached objects or rate-limit windows without rewriting data layers. Steada is independent of the Valkey project and the Linux Foundation, operating managed instances configured for predictable application caching workloads.

Valkey vs Redis: what actually changed in the project

When analyzing the Valkey vs Redis project divergence, the differences divide into legal governance, licensing terms, and core engineering focus. While Redis Ltd. controls the development of upstream Redis to align with its commercial cloud and enterprise offerings, the Valkey community directs engineering toward core engine throughput, thread scaling, and memory efficiency.

The primary catalyst for the split was licensing. According to the Redis license page, recent versions of Redis are distributed under RSALv2 or SSPLv1. These licenses place restrictions on offering the software as a managed commercial service and restrict certain redistribution patterns. Valkey retains the BSD-3-Clause license. This permissive license gives organizations legal certainty when embedding the software into internal platforms, packaging it inside commercial distributions, or consuming it from infrastructure providers.

On an architectural level, Valkey has maintained strict backwards compatibility with Redis 7.2 while improving multi-threaded I/O. Valkey 8.0 introduced an updated threading model that separates network I/O and command parsing across worker threads more effectively than older Redis versions. This design reduces median and tail latency under heavy connection counts. Valkey open-source development prioritizes the stability of core in-memory data structures over proprietary modules.

For teams comparing these paths, our detailed Valkey vs Redis comparison reviews the divergence in release cadences, maintenance policies, and community roadmaps.

Valkey compatibility: what 'Redis-compatible' covers and what it doesn't

Valkey compatibility operates at the protocol and command level. Because Valkey implements the RESP wire protocol, established client libraries interact with it identically to Redis. Applications running standard drivers such as ioredis, node-redis, redis-py, go-redis, or Lettuce can point their connection strings to a Valkey host without requiring code changes for standard operations.

Command coverage across the core data structures is comprehensive. Valkey fully implements the commands powering everyday web application features:

• Strings and keys: GET, SET, MGET, MSET, INCR, DECR, EXPIRE, and DEL.
• Hashes: HGET, HSET, HMGET, HINCRBY, and HGETALL for structured session state.
• Lists and sets: LPUSH, RPOP, SADD, SMEMBERS, and SISMEMBER for simple collections.
• Sorted sets: ZADD, ZRANGEBYSCORE, and ZREMRANGEBYSCORE for sliding-window rate limiters.
• Transactions and scripting: multi-exec blocks and custom Lua scripts via EVAL and EVALSHA.

However, compatibility is not absolute. Proprietary Redis modules developed outside the core repository are absent. Steada does not support Redis modules such as RediSearch, RedisJSON, or RedisBloom. If your application architecture relies on in-database JSON path indexing, vector similarity searches, or graph operations managed by those modules, Valkey core will not execute those commands natively.

Furthermore, managed services expose curated execution environments. Commands that manipulate underlying operating system files, configure disks, or modify daemon security at runtime, such as CONFIG REWRITE, DEBUG, MODULE LOAD, or SLAVEOF, are typically disabled to maintain tenant isolation. Before planning a database cutover, review Steada's documented command compatibility subset to confirm your specific command list runs cleanly.

Where Valkey fits in a small SaaS stack: cache, sessions, rate limits

Choosing Valkey makes practical sense when an application requires high-throughput, sub-millisecond key-value operations for transient data. In a typical software-as-a-service architecture, these requirements cluster around three core components:

First, application-level caching. Database read queries, third-party API responses, and rendered HTML fragments frequently benefit from caching with an explicit time-to-live (TTL). If the cache instance restarts or clears its memory, the application queries its primary database to rebuild the cache. The transient nature of this workload fits Valkey's single-instance in-memory model.

Second, web user session storage. Fast lookups for authentication cookies and user permissions keep request latency low. Storing sessions in Valkey offloads high-frequency point reads from relational tables. If a cold instance restart occurs, users experience a session invalidation requiring them to log in again, an acceptable tradeoff for non-critical systems that avoid the complexity and cost of distributed storage.

Third, API rate limiting and traffic throttling. Implementing a sliding-window rate limiter requires issuing rapid INCR, EXPIRE, or sorted-set operations for every incoming HTTP request. This generates high command volume while consuming minimal memory. A few thousand keys can enforce limits across millions of daily API calls. Paying per command for this pattern quickly creates inflated cloud bills, making flat-rate in-memory stores cost-effective.

Workload fit depends on data recoverability. Steada is for cache, sessions, rate limiting, and low-risk metadata that can roll back—not source-of-truth data without an independent recovery path. Permanent records like invoices, customer accounts, and audit histories belong in durable relational or document databases.

Sizing the decision: memory, connections, and the arithmetic that matters

Sizing an in-memory key-value store requires calculating two distinct resource ceilings: memory footprint and client connection capacity. Underestimating memory results in premature key evictions, while underestimating connections causes connection timeouts during traffic spikes.

Calculating required memory

Memory requirements equal the aggregate size of your stored keys and values plus the internal metadata overhead of the engine, adjusted for eviction headroom. Valkey allocates memory for key names, internal pointers, expiry dictionaries, and client output buffers alongside the raw payload data.

Consider a SaaS product tracking authenticated user sessions:

• Target active concurrent sessions: 50,000.
• Average serialized payload per session: 1,500 bytes (JSON user ID, permissions, CSRF token).
• Raw payload footprint: 50,000 * 1,500 bytes = 75,000,000 bytes (~71.5 MiB).
• Key names and dictionary overhead: roughly 250 bytes per key = 12.5 MiB.
• Total base data requirement: ~84 MiB.

Running an in-memory database near total capacity risks memory fragmentation and unexpected evictions. Allocating an operational safety buffer with generous headroom keeps memory usage healthy. In this scenario, an 84 MiB active dataset comfortably fits inside a 256 MiB memory allocation, leaving adequate space for cache bursts or temporary spikes in active sessions.

Calculating connection ceilings

Client connection overhead represents an operational limit that teams frequently overlook. Every connected web application instance, background queue processor, and scheduled cron task maintains open TCP sockets to the datastore.

Calculate your connection demand using this formula:

Total Connections = (Web Dynos / App Pods * Connection Pool Size) + Background Workers + Ad-hoc Monitoring

If you add 4 worker containers running 10 background worker threads each, they consume an additional 40 connections. Your steady-state connection footprint reaches 130 persistent connections before accounting for health checks or deployment overlap.

During blue-green or rolling deployments, connection counts temporarily double as old and new containers run concurrently. If your managed provider enforces an aggressive connection ceiling, rolling deploys will trigger connection pool exhaustion errors. Choose a tier whose connection ceiling accommodates these transition peaks.

Flat monthly tiers vs request-metered pricing: running both numbers

When selecting a managed cache provider, teams generally choose between request-metered pricing (pay-as-you-go per command) and fixed capacity pricing (flat monthly subscriptions). Neither model is universally cheaper; the optimal choice depends strictly on your command throughput relative to your dataset size.

Steada charges a flat monthly price per plan; cost does not scale per request or per command, which is the explicit contrast with request-metered providers. Published self-service monthly plan prices on Steada are Starter (256 MiB) at $49, Growth (512 MiB) at $89, Scale (1 GiB) at $149, and Scale+ (2 GiB) at $249. Memory, connection, and compute limits apply to each tier, but issuing 50 million commands costs the same as issuing 500 commands. You can verify current rates on the Steada pricing page.

Request-metered platforms charge incrementally for each read and write command executed by the datastore. For early-stage products, staging environments, or low-throughput applications processing under 500,000 requests per month, pay-as-you-go billing is frequently more economical than any flat-rate tier. At negligible command volume, metered services can cost only a few dollars per month.

However, command-heavy workloads change the financial equation. Consider an application handling steady traffic: an API gateway serving 40 requests per second with rate limiting and session validation. Each incoming HTTP request generates 3 cache commands (one rate-limit counter increment, one session validation read, and one permission check):

• 40 incoming requests per second * 3 commands = 120 commands per second.
• 120 commands per second * 86,400 seconds = 10,368,000 commands per day.
• Monthly command total: ~311 million commands per month.

On request-metered platforms charging per hundred thousand or million commands, executing over 300 million commands creates a substantial monthly variable invoice. Even if the underlying dataset occupies less than 200 MiB of memory, the request volume drives up costs. To evaluate how these dynamics apply to your specific command volume, run the figures through the pricing calculator.

Migrating a Redis client to managed Valkey without a rewrite

Because Valkey implements the RESP wire protocol, migrating an active codebase from Redis to managed Valkey requires only updated connection parameters. The default connection path is native Redis/Valkey RESP over TLS with password authentication.

Configuring common client libraries

Standard open-source client libraries connect to Valkey by providing the target hostname, port, username, password, and TLS configuration flags.

For Node.js applications using ioredis:

import Redis from 'ioredis';

const client = new Redis({
  host: process.env.VALKEY_HOST,
  port: Number(process.env.VALKEY_PORT) || 6379,
  username: process.env.VALKEY_USER || 'default',
  password: process.env.VALKEY_PASSWORD,
  tls: {
    rejectUnauthorized: true,
  },
  maxRetriesPerRequest: 3,
  enableReadyCheck: true,
});

client.on('error', (err) => {
  console.error('Valkey connection error:', err);
});

For Python applications using redis-py:

import os
import redis

client = redis.Redis(
    host=os.getenv('VALKEY_HOST'),
    port=int(os.getenv('VALKEY_PORT', 6379)),
    username=os.getenv('VALKEY_USER', 'default'),
    password=os.getenv('VALKEY_PASSWORD'),
    ssl=True,
    ssl_cert_reqs='required',
    socket_timeout=5.0,
    retry_on_timeout=True
)

For Go applications using go-redis:

package main

import (
    "crypto/tls"
    "os"
    "github.com/redis/go-redis/v9"
)

func NewValkeyClient() *redis.Client {
    return redis.NewClient(&redis.Options{
        Addr:      os.Getenv("VALKEY_HOST") + ":" + os.Getenv("VALKEY_PORT"),
        Username:  os.Getenv("VALKEY_USER"),
        Password:  os.Getenv("VALKEY_PASSWORD"),
        TLSConfig: &tls.Config{
            MinVersion: tls.VersionTLS12,
        },
    })
}

For detailed connection strings and framework configurations, consult our connection guides.

Migration and rollback checklist

Follow a structured rollout plan to ensure zero operational surprises during infrastructure cutovers:

1. Audit application commands against the target service. Ensure code does not rely on unsupported commands or missing Redis modules.
2. Provision the new managed instance and verify network latency from your production application clusters.
3. Store both legacy and new datastore connection strings in your environment configuration behind a runtime feature flag.
4. Perform dual-write testing or switch non-critical rate-limiting traffic first to confirm socket stability and connection pooling under load.
5. Route read traffic to the new instance. Allow cache misses to repopulate naturally from the backing database.
6. Retain the old datastore endpoint active for at least one full operational cycle. If connection anomalies occur, revert the feature flag to point traffic back to the original endpoint immediately.

What a managed Valkey service does and does not handle

Managed hosting abstracts server maintenance, but engineering teams must understand the exact boundary between provider responsibilities and application responsibilities.

Steada provides single-instance Valkey environments hosted in DigitalOcean NYC3. The platform handles initial provisioning, host operating system security patching, network firewall rules, TLS termination endpoints, credential generation, and memory enforcement limits. Steada includes per-database usage telemetry, percentile latency, a projected month-end cost labeled a hypothesis, native threshold alerting, and read-only Prometheus + CSV export on the same tier. Teams can inspect these metrics live via the live dashboard preview without entering credit card details.

Understanding operational limitations is critical when architecting your cache layer:

• Steada does not offer multi-region or active-active replication. Databases run as standalone instances in a single datacenter region.
• Steada does not offer a formal SLA or uptime guarantee. Technical support is delivered via email during standard business hours without 24/7 on-call dispatching.
• Steada does not claim full Upstash REST API parity; the default path is native RESP over TLS, with only a narrow REST compatibility preview.
• Steada has no completed compliance certifications (SOC 2, HIPAA, PCI, ISO 27001) today.
• Steada makes no regulated-data commitments; do not store regulated or protected data such as PHI.

When instances restart (whether due to host maintenance, node failure, or tier resizing), in-memory cache entries can be lost. Applications using managed Valkey must tolerate cache cold-starts gracefully and handle session re-authentications when required.

When Valkey is the wrong choice

While Valkey provides an efficient, open-source caching engine, specific technical and business constraints make other architectures preferable:

First, workloads that require multi-region data replication. If your application architecture relies on geographically distributed active-active clusters to serve low-latency local reads across Europe, Asia, and North America simultaneously, a single-region deployment is inadequate. You need a distributed caching platform with cross-datacenter synchronization.

Second, datasets requiring strict, zero-data-loss durability. While Valkey can write append-only files (AOF) or point-in-time snapshots to disk, in-memory architectures are susceptible to loss between flush intervals. Relational stores like PostgreSQL or distributed document databases provide transaction logs, multi-node consensus, and point-in-time recovery designed for non-rebuildable data.

Third, architectures dependent on proprietary Redis modules. If your engineers use search query languages, full-text inverted indexes, or native graph traversal modules, core Valkey will reject those commands. Those features necessitate either running Redis Enterprise or migrating those capabilities to specialized search engines and document stores.

Fourth, minimal or bursty hobby workloads. If your service processes only a few thousand requests per week, paying for a fixed 256 MiB or 512 MiB monthly tier is unnecessary. A serverless, pay-as-you-go provider offering free or sub-five-dollar tiers is the pragmatic financial choice at very low volumes.

Frequently asked questions

Is valkey redis?

No, Valkey is not Redis. Valkey is an independent, open-source fork of Redis created from the Redis 7.2.4 codebase. It was initiated in 2024 by former Redis contributors and major tech organizations after Redis Ltd. shifted its licensing away from open source. Valkey maintains protocol compatibility with Redis but develops under separate governance within the Linux Foundation.

What is valkey redis?

The phrase "valkey redis" refers to the relationship between the two projects. Valkey is an open-source, Redis-compatible fork that implements the RESP wire protocol. Applications switch between them by changing their connection host, port, and credentials.

Can existing Redis client libraries connect to Valkey?

Yes. Standard client libraries including ioredis, redis-py, and go-redis connect to Valkey without code modifications. You configure the client with the Valkey endpoint address, port, and TLS credentials.

To evaluate your monthly command volume against fixed-rate options, review the pricing calculator or test an instance via self-service provisioning.