--- title: Valkey's Next Chapter: Durability and Beyond | daily.dev description: Valkey's next development chapter centers on four connected efforts: durability, Cluster V2, data tiering, and active-active replication. Today, replication is... canonical: https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Valkey's Next Chapter: Durability and Beyond | daily.dev og:description: Valkey's next development chapter centers on four connected efforts: durability, Cluster V2, data tiering, and active-active replication. Today, replication is... og:url: https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor og:image: https://api.daily.dev/og/posts/SfFKR4nor.png og:image:alt: Valkey's Next Chapter: Durability and Beyond og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Valkey's Next Chapter: Durability and Beyond **[Valkey](https://daily.dev/sources/valkey-blog)** · 5 min read · 0 upvotes · 0 comments ## Summary Valkey's next development chapter centers on four connected efforts: durability, Cluster V2, data tiering, and active-active replication. Today, replication is asynchronous, so a primary can acknowledge a write before replicas receive it, risking data loss on failover. The proposed fix adds synchronous replication with uncommitted-write tracking. Cluster V2 would replace the full-mesh gossip protocol, which used around 5% CPU at 1,000 nodes with no traffic, with Raft-based leader coordination. Data tiering would move cold keys to disk automatically based on access patterns. Active-active replication is exploring last-write-wins and CRDTs for cross-region conflict resolution. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is Valkey's current replication not fully durable when a primary node fails? Valkey's replication is asynchronous, meaning the primary acknowledges a client write before replicas have received it. If the primary crashes in that window, the replica promoted to primary never saw the write, so the acknowledged data is permanently lost. Valkey's proposed durability work addresses this with synchronous replication that marks writes uncommitted until replicas acknowledge them. _Anyone weighing Valkey for durability-sensitive workloads can track this work as it lands on daily.dev._ ### Why is Valkey moving its cluster protocol from gossip to Raft for Cluster V2? Full-mesh gossip, Valkey's current approach for node communication and topology changes, doesn't scale cleanly: testing with roughly 1,000 nodes showed cluster communication alone consuming about 5% CPU even with no application traffic. Cluster V2 proposes Raft, a leader-based consensus algorithm where a majority of nodes must acknowledge changes, giving a consistent view of cluster metadata needed for reliable failover decisions. _Engineers planning large Valkey clusters can follow Cluster V2's progress via daily.dev._ ### How will Valkey's upcoming data tiering feature decide which keys stay in memory versus move to disk? Valkey's planned data tiering would automatically determine data placement based on access patterns, keeping hot data in-memory and moving colder, less frequently accessed data to lower-cost disk storage, rather than requiring developers to manually assign keys to tiers. Requests for cold data trigger asynchronous retrieval that only delays the requesting client, while other requests continue unaffected. _Teams sizing Valkey memory budgets can keep up with tiering design decisions on daily.dev._ ## Similar posts on daily.dev - [AWS Introduces Durable Storage Option for ElastiCache for Valkey](https://daily.dev/posts/aws-introduces-durable-storage-option-for-elasticache-for-valkey-w3oihx74d) · InfoQ · 0 upvotes · 0 comments - [Valkey · ValkeyConf 2026: Nobody Owns Valkey. That's Why It's Working.](https://daily.dev/posts/valkey-valkeyconf-2026-nobody-owns-valkey-that-s-why-it-s-working--sdursecws) · Valkey · 0 upvotes · 0 comments - [Valkey 9.0 Introduces Multi-Database Clustering, Atomic Slot Migration, and Major Performance Gains](https://daily.dev/posts/valkey-9-0-introduces-multi-database-clustering-atomic-slot-migration-and-major-performance-gains-2gkxrlley) · InfoQ · 7 upvotes · 0 comments - [Valkey just had a 17x year. Its lead maintainer still doesn’t want Redis to die.](https://daily.dev/posts/valkey-just-had-a-17x-year-its-lead-maintainer-still-doesn-t-want-redis-to-die--hymzgle9p) · The New Stack · 2 upvotes · 0 comments --- Tags: [#distributed-systems](https://daily.dev/tags/distributed-systems), [#redis](https://daily.dev/tags/redis), [#valkey](https://daily.dev/tags/valkey) [View this post on daily.dev](https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Valkey's Next Chapter: Durability and Beyond","url":"https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor"},"datePublished":"2026-10-29T22:02:53.622Z","dateModified":"2026-10-29T22:07:55.789Z","description":"Valkey's next development chapter centers on four connected efforts: durability, Cluster V2, data tiering, and active-active replication. Today, replication is...","image":"https://media.daily.dev/image/upload/s--ZrL_HSsR--/f_auto/v1722860399/public/Placeholder%2006","thumbnailUrl":"https://media.daily.dev/image/upload/s--ZrL_HSsR--/f_auto/v1722860399/public/Placeholder%2006","isAccessibleForFree":true,"articleSection":"Valkey","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Valkey","logo":"https://media.daily.dev/image/upload/s--XXPzEmD8--/f_auto,q_auto/v1787487496/logos/valkey-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/valkey-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"distributed-systems,redis,valkey","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Valkey","item":"https://daily.dev/sources/valkey-blog"},{"@type":"ListItem","position":3,"name":"Valkey's Next Chapter: Durability and Beyond"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/valkey-s-next-chapter-durability-and-beyond-sffkr4nor#faq","mainEntity":[{"@type":"Question","name":"Why is Valkey's current replication not fully durable when a primary node fails?","acceptedAnswer":{"@type":"Answer","text":"Valkey's replication is asynchronous, meaning the primary acknowledges a client write before replicas have received it. If the primary crashes in that window, the replica promoted to primary never saw the write, so the acknowledged data is permanently lost. Valkey's proposed durability work addresses this with synchronous replication that marks writes uncommitted until replicas acknowledge them. Anyone weighing Valkey for durability-sensitive workloads can track this work as it lands on daily.dev."}},{"@type":"Question","name":"Why is Valkey moving its cluster protocol from gossip to Raft for Cluster V2?","acceptedAnswer":{"@type":"Answer","text":"Full-mesh gossip, Valkey's current approach for node communication and topology changes, doesn't scale cleanly: testing with roughly 1,000 nodes showed cluster communication alone consuming about 5% CPU even with no application traffic. Cluster V2 proposes Raft, a leader-based consensus algorithm where a majority of nodes must acknowledge changes, giving a consistent view of cluster metadata needed for reliable failover decisions. Engineers planning large Valkey clusters can follow Cluster V2's progress via daily.dev."}},{"@type":"Question","name":"How will Valkey's upcoming data tiering feature decide which keys stay in memory versus move to disk?","acceptedAnswer":{"@type":"Answer","text":"Valkey's planned data tiering would automatically determine data placement based on access patterns, keeping hot data in-memory and moving colder, less frequently accessed data to lower-cost disk storage, rather than requiring developers to manually assign keys to tiers. Requests for cold data trigger asynchronous retrieval that only delays the requesting client, while other requests continue unaffected. Teams sizing Valkey memory budgets can keep up with tiering design decisions on daily.dev."}}]} ```