Valkey engine, a new option for MemStore
For services that require real-time responses, an in-memory data store is a key component. As fast read and write workloads such as user sessions, caches, and queues grow, database response performance becomes directly tied to service experience. In operations, stable failover, security patches, and version lifecycle management are just as important as performance.
KakaoCloud MemStore now supports Valkey 8.1 as a new engine, in addition to the existing Redis OSS family. In this post, we introduce the Valkey engine and the key operational points to check when configuring a Valkey-based cluster in MemStore.
Understanding the Valkey engine
MemStore is a fully managed in-memory data store service. It runs in a VPC environment and helps reduce database operation overhead by automating tasks such as node provisioning, network configuration, and node status management. Instead of building and managing a cache database directly, users can use managed features such as cluster creation, backup, monitoring, and access control.
Valkey is an open-source in-memory data store engine based on Redis OSS 7.2 and earlier open-source Redis versions. In MemStore, Valkey is provided as a managed in-memory data store engine alongside the Redis OSS family.
The Valkey engine may be a good option in the following cases.
- You want to configure a newly created cache or session store based on Valkey.
- You want to review the Valkey engine while keeping a familiar Redis OSS-based usage experience.
- You want to operate cluster mode, high availability, backup, and monitoring as managed service features.
Valkey 8.1 in MemStore
MemStore currently provides Valkey 8.1 and Redis OSS versions up to 7.2. When creating a cluster, you select an engine version and configure the parameter group and cluster settings that match the selected engine version.
Valkey also supports the key managed features of MemStore. Clusters are deployed in the user's VPC and subnets, and security groups control accessible IP ranges and ports. With cluster mode, data can be distributed across multiple shards, and Primary/Replica configuration helps prepare for node failures.
Operational features are also available. Automatic and manual backups help secure data for recovery, and clusters can be restored from backup files stored in Object Storage. TLS 1.2 transport encryption and user authentication can strengthen access security, while key metrics such as Valkey, CPU, memory, and network metrics help monitor cluster status.
Even when you choose Valkey, existing MemStore operational features such as cluster creation, backup, and monitoring are still available.
Operational Differences Between Valkey and Redis OSS
Valkey and Redis OSS are provided as in-memory data store engines within MemStore. The basic flow for creating and operating clusters is similar, but some differences, such as shard configuration and failover behavior, affect operational policy.
Both engines commonly support the following MemStore operational features.
- Shard-based distributed structure or single-shard structure depending on whether cluster mode is enabled
- High availability configuration based on Primary/Replica structure
- Network access control through VPCs, subnets, and security groups
- Automatic backup, manual backup, and backup-based restore
- TLS 1.2 transport encryption, user authentication, and key metrics monitoring
The following items differ depending on the selected engine.
Cluster mode configuration
Both engines can distribute data across multiple shards when cluster mode is enabled. The difference is the minimum number of shards. Valkey can be configured from a minimum of 3 shards, while Redis OSS can be configured from a minimum of 1 shard. Both engines support up to 12 shards.
The number of shards affects both performance and operational complexity. Increasing shards can help distribute data for scalability, but application data access patterns and cluster operation methods should also be considered. When using cluster mode with Valkey, plan the initial configuration based on the minimum of 3 shards.
When cluster mode is disabled, both engines create a cluster with a single-shard structure. A single-shard configuration is simpler to start with, but for environments that require high availability, review the node count and automatic failover policy together. Because the automatic backup option provided by MemStore is available only when there are 2 or more nodes, consider using at least 2 nodes for stable service operation.
Automatic failover
When cluster mode is disabled, automatic failover settings differ clearly between the two engines. For Valkey, automatic failover is enabled automatically when there are 2 or more nodes. For Redis OSS, users can choose whether to enable automatic failover when there are 2 or more nodes, and can change the setting after cluster creation.
Automatic failover promotes a Replica node to Primary when the Primary node fails, helping maintain service continuity. For services that require high availability, review the engine, node count, subnet placement, and failover policy together.
Manual promotion
Manual promotion also works differently. For Valkey, a Replica node can be promoted to Primary regardless of whether cluster mode or automatic failover is enabled. For Redis OSS, when cluster mode or automatic failover is enabled, the service automatically performs promotion when needed based on node failure conditions, and users cannot request promotion directly.
Manual promotion is useful when operators need direct control over node role changes during failure response or maintenance. If your operating procedure requires promoting a Replica to Primary at a specific time or explicitly controlling the failover flow, consider this difference when choosing an engine.
What to check before adoption
Valkey 8.1 is an engine that can be selected when creating a new cluster. If you plan to configure a new Valkey-based cluster, first check the features and settings used by your application, along with restore conditions.
When restoring a cluster from backup, you can restore only to the same or a later engine version than the version used for the backup. Restore may also fail if the cache size of the source backup is 60% or more of the memory of the target cluster node type, so check the data size and target configuration together.
Before designing a new workload or adopting Valkey, review the following items.
- Whether the features and settings used by the application are supported by the selected engine version
- Whether the cluster mode setting, number of shards, and number of nodes fit the workload scale
- Whether the automatic failover and manual promotion policies match the operating procedure
- Whether the cache size of the source backup satisfies the memory condition of the target node type
- Whether any engine version past EOL is still being used
Get started
You can create a Valkey 8.1-based MemStore cluster from Data Store > MemStore in the KakaoCloud Console. When creating a cluster, select the engine version and configure cluster mode, shards and nodes, VPC, security groups, automatic backup, TLS, and user authentication options.
If you are using MemStore for the first time, start with a small new cluster to check application connectivity, authentication, security groups, and backup policy. For production environments, adjust cluster mode, shard count, node count, and failover policy based on workload characteristics.
KakaoCloud will continue to expand supported engines and operational features so MemStore can serve as a stable data layer for applications that require fast responses.
Valkey® is a registered trademark of LF Projects. Redis® is a registered trademark of Redis Ltd.