Redis vs Valkey năm 2026: hậu quả từ thay đổi giấy phép

Hãy dùng Valkey cho dự án mới. Redis 8 bổ sung AGPLv3 vào tháng 5 năm 2025, chính thức trở thành open source một lần nữa — nhưng “quá trễ” là nhận định hợp lý. Lúc đó, Valkey đã có AWS, Google Cloud, và Oracle đứng sau, rẻ hơn 20–33% trên các managed service của AWS, và đã ra mắt các tính năng cluster mà Redis vẫn chưa có. Nếu bạn cần Redis Enterprise, active-active replication, hoặc TimeSeries tích hợp sâu, Redis vẫn là câu trả lời đúng. Còn lại, fork đã thắng.

Bài này dành cho ai

Developers đang bắt đầu service mới và cần chọn một Redis-compatible store, cùng các kỹ sư đang chạy Redis OSS 7.2 và đang cân nhắc có nên chuyển sang fork không. Nếu bạn đang dùng Redis Enterprise với active-active CRDT replication hoặc Redis Insight Pro — tiếp tục đọc, nhưng kết quả sẽ khác.

Câu chuyện về giấy phép

Tháng 3 năm 2024: BSD chuyển thành SSPL và RSALv2

Redis Ltd. đổi giấy phép Redis 7.4 từ BSD-3-Clause sang mô hình kép:

RSALv2 (Redis Source Available License v2): cho phép dùng nội bộ, nhưng cấm cung cấp Redis như một managed database service cho bên thứ ba.
SSPLv1: nếu bạn cung cấp Redis như một service, bạn phải open-source toàn bộ stack — management layer, API, orchestration, backup. License này do MongoDB soạn thảo và không được OSI phê duyệt.

Dùng nội bộ (app của bạn kết nối đến Redis) hoàn toàn được phép theo cả hai. Việc đổi giấy phép nhắm vào các cloud provider đang bán Redis-as-a-service mà không có thỏa thuận thương mại — và đã có tác động. AWS, Google Cloud, và Alibaba Cloud chọn fork thay vì trả tiền.

Redis 7.2 và các phiên bản trước giữ nguyên BSD-3-Clause. Thay đổi không áp dụng ngược.

Tháng 5 năm 2025: Redis 8.0 bổ sung AGPLv3

Redis 8.0 bổ sung lựa chọn giấy phép thứ ba: AGPLv3. License này được OSI phê duyệt. Redis 8 hiện có ba giấy phép song song: RSALv2, SSPLv1, và AGPLv3.

AGPLv3 yêu cầu các bản phái sinh và sửa đổi khi dùng qua network phải được open-source — nhẹ hơn SSPL, nhưng chặt hơn BSD. Với một startup chạy Redis nội bộ, sự khác biệt thực tế không lớn.

Redis 8 cũng tích hợp các Redis Stack module vào core: JSON, TimeSeries, Bloom, RediSearch, và một kiểu dữ liệu vector set mới (do Salvatore Sanfilippo viết). Đây mới là thay đổi đáng kể hơn về mặt vận hành.

Cộng đồng đọc việc bổ sung AGPLv3 như một phản ứng thụ động. Trong suốt năm 2025, Valkey thu hút 346 active contributors, duy trì nhịp release nhanh hơn, và được các cloud lớn hậu thuẫn. Cảm nhận chủ đạo trên HN và Reddit: cành ô liu đến sau khi bữa tiệc đã tàn.

Valkey: tình trạng hiện tại

Valkey fork từ Redis 7.2.4 vào tháng 3 năm 2024, được Linux Foundation quản lý, cấp phép BSD. Danh sách hậu thuẫn — AWS, Google Cloud, Oracle, Alibaba Cloud — không cần giải thích thêm. Phiên bản ổn định hiện tại: Valkey 9.1.0 (ngày 19 tháng 5 năm 2026).

Dòng 9.x có các tính năng Redis chưa có:

Hash field expiration: TTL theo từng field bên trong một hash. Hữu ích cho session store và feature flag cần tự hết hạn.
Multi-DB trong cluster mode: tách biệt workload mà không cần nhiều instance riêng.
Atomic slot migration: resharding không lỗi, không downtime.
CLUSTERSCAN: scan key nhất quán trên toàn bộ cluster. Đây là thứ người dùng Redis trong cluster mode mong chờ nhiều năm.

Valkey 9.1 cũng thiết kế lại IO threading để tăng throughput lên đến 17% so với 9.0, giảm bộ nhớ per-key tới 10%, và bổ sung tự động reload TLS certificate.

Tính năng: Redis 8.0 vs Valkey 9.1

Tính năng	Redis 8.0	Valkey 9.1	Ghi chú
Kiểu dữ liệu cơ bản (String, Hash, List, Set, ZSet, Stream)	✅	✅	Ngang nhau
JSON	✅ tích hợp vào core	✅ bundled addon	Hỗ trợ query như nhau
Full-text search	✅ RediSearch trong core	✅ Valkey Search 1.2	Đều hỗ trợ vector, tag, numeric
Vector search	✅ vector sets	✅ Valkey Search 1.2	Cách triển khai khác nhau
Time series	✅ trong core	⚠️ bundled, không bật mặc định	Redis 8 có sẵn natively
Bloom / probabilistic	✅ trong core	✅ bundled
Hash field expiration	❌	✅ (9.0+)	Chỉ có ở Valkey
Multi-DB trong cluster	❌	✅ (9.0+)	Chỉ có ở Valkey
Atomic slot migration	❌	✅ (9.0+)	Chỉ có ở Valkey
CLUSTERSCAN	❌	✅ (9.1)	Chỉ có ở Valkey
RESP2 / RESP3	✅	✅
Pub/Sub	✅	✅
Lua scripting	✅	✅
RDB/AOF persistence	✅	✅
ACLs	✅	✅ + DB-level trong 9.1	Valkey chi tiết hơn
TLS	✅	✅ + tự reload trong 9.1

Một thực tế về tương thích: Valkey hỗ trợ Redis protocol đến Redis 7.2. Bạn không thể replicate giữa Valkey 9.x và Redis 8.x — hai codebase đã tách rời. Migration cần export và import, không dùng được live replication.

TimeSeries là điểm duy nhất mà cách tiếp cận của Redis 8 đơn giản hơn về mặt vận hành. Nó có trong binary core mà không cần cấu hình thêm. Valkey đóng gói nó như một addon không bật mặc định. Nếu bạn chạy time-series workload ở quy mô lớn, khoảng cách này có trọng lượng thực sự.

Hiệu năng

Các benchmark của bên thứ ba nghiêng về Valkey với mixed workload.

Benchmark năm 2025 của Percona trên AWS r6g.large (2 vCPU, 16 GB RAM) với thao tác SET 1 KB: Valkey 8.0 đạt 1.20 triệu ops/giây; Redis OSS 7.4 đạt 1.11 triệu ops/giây — chênh lệch 8%. Với mixed read/write traffic trên cache.m7g.large: P99 latency của Valkey là 1.8 ms so với Redis OSS 2.3 ms, cải thiện 22%.

Tài liệu ra mắt của Redis 8 tuyên bố câu lệnh nhanh hơn đến 87% và throughput gấp 2× với cache read-heavy. Các con số này chưa được bên thứ ba xác minh độc lập. Chúng phản ánh kiến trúc module-merged của Redis 8 trên một workload cụ thể. Hãy coi đây là chỉ số định hướng cho đến khi có benchmark độc lập.

Hiệu quả bộ nhớ cũng nghiêng về phía Valkey. Thiết kế lại hash table trong Valkey 8.1 giảm memory footprint hơn 20% với workload key-value thông thường. Trên AWS, cộng thêm thay đổi pricing, tổng tiết kiệm vào khoảng 36% so với Redis OSS 7.2.

Cloud và hosting

AWS

Valkey đã GA trên ElastiCache, ElastiCache Serverless, và MemoryDB trên tất cả các region từ tháng 10 năm 2024.

Service	Valkey tiết kiệm so với Redis OSS
ElastiCache Serverless	Rẻ hơn 33%
Node-based ElastiCache	Rẻ hơn 20%
MemoryDB	Rẻ hơn 30%

AWS ủng hộ Valkey rõ ràng như vậy cũng là tín hiệu mạnh về hướng hỗ trợ dài hạn. Azure, trong khi đó, vẫn hợp tác với Redis Ltd. và chưa có managed service Valkey-native — đáng lưu ý nếu bạn bị ràng buộc với Azure và muốn tính năng tương đương.

Upstash

Upstash cung cấp managed service tương thích Redis/Valkey theo mô hình pay-per-request: $0.20 mỗi 100K request cộng $0.25/GB storage. Scale về 0, có free tier, và HTTP REST API hoạt động được trên Cloudflare Workers, Vercel Edge, cùng các runtime không hỗ trợ kết nối TCP liên tục.

Phù hợp nhất: serverless workload, edge function, hoặc app giai đoạn đầu mà connection pooling thực sự là vấn đề. Từ 10 triệu request/tháng trở lên, ElastiCache kinh tế hơn.

Render

Render mặc định dùng Valkey 8 cho tất cả instance Key Value mới từ cuối năm 2024. Các instance Redis 6.2.14 hiện tại tiếp tục chạy — không bắt buộc migrate. Cả keyvalue lẫn redis service type trong render.yaml đều provision Valkey. Render là lựa chọn ít ma sát nhất nếu bạn đã trên platform này.

Railway

Railway cung cấp Valkey template với giá $1/tháng. Khác với Render, đây là container bạn tự quản lý — không phải fully managed service. Phù hợp nếu bạn muốn Valkey bên cạnh các Railway service khác và thoải mái với việc tự quản lý container.

Migrate từ Redis sang Valkey: Node.js

Ba lựa chọn theo mức độ phức tạp tăng dần:

Lựa chọn A: Đổi connection string (đúng cho hầu hết teams)

Với ioredis 5.3+, các thao tác cơ bản không cần thay đổi code:

# Trước
REDIS_URL=redis://your-redis-host:6379

# Sau
REDIS_URL=redis://your-valkey-host:6379

import Redis from 'ioredis'
const client = new Redis(process.env.REDIS_URL)

Kiểm tra HGETALL, HELLO, và CLIENT INFO nếu bạn dùng các tính năng RESP3-aware hoặc gọi HELLO trực tiếp. Transaction, pub/sub, sorted set: tương thích.

Nếu bạn đang dùng ioredis dưới 5.3, hãy nâng cấp trước.

Lựa chọn B: Chuyển sang Valkey GLIDE

GLIDE là Valkey Node.js client chính thức với Rust core. Throughput cao hơn ioredis với batch-heavy workload — nhưng API thay đổi đáng kể, và đây không phải thay thế trực tiếp:

Thao tác	ioredis	GLIDE
Cài đặt	`npm i ioredis`	`npm i @valkey/valkey-glide`
Kết nối	`new Redis(url)`	`GlideClient.createClient({addresses:[...]})`
DEL nhiều key	`del('k1','k2')`	`del(['k1','k2'])`
HSET	`hset('h','k','v')`	`hset('h', {k:'v'})`
ZADD	`zadd('z', 1, 'a')`	`zadd('z', [{score:1, member:'a'}])`
SETEX	`setex('k',5,'v')`	`set('k','v', {expiry:{type:TimeUnit.Seconds, count:5}})`
Transaction	`redis.multi().exec()`	class `new Transaction()`
Lua script	`eval()` / `evalsha()`	class `Script` + `invokeScript()`
Giá trị trả về của `exists`	Integer (0/1)	Boolean

Chỉ đáng tốn công migrate cho các code path đòi hỏi throughput cao: pub/sub khối lượng lớn, batch pipeline.

Lựa chọn C: @upstash/redis (zero friction nếu bạn đã chuyển sang Upstash)

SDK của Upstash trừu tượng hóa engine bên dưới. Đổi endpoint, giữ nguyên code:

import { Redis } from '@upstash/redis'
const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL,
  token: process.env.UPSTASH_REDIS_REST_TOKEN,
})

Không cần thay đổi gì khác.

Kết luận

Dự án mới: dùng Valkey. Giấy phép BSD dưới sự quản lý của Linux Foundation (không có rủi ro đổi giấy phép), rẻ hơn trên mọi managed cloud lớn, cluster tooling dẫn trước Redis 8, và migrate ioredis chỉ là đổi connection string.

Triển khai Redis OSS 7.2 hiện có: migrate vào lần nâng cấp tiếp theo. Con đường ioredis (Lựa chọn A) giúp bạn đến đích với ít rủi ro nhất.

Dùng Redis 8 nếu: bạn cần Redis Enterprise — hỗ trợ thương mại, multi-zone active-active replication, Redis Insight Pro. Hoặc nếu TimeSeries đủ trung tâm trong kiến trúc của bạn khiến việc load nó như một Valkey addon riêng gây ra ma sát vận hành thực sự.

Tránh Redis 8 nếu: bộ phận pháp lý hoặc compliance của bạn xem xét kỹ giấy phép. Điều khoản network-service copyleft của AGPLv3 — yêu cầu open-source các sửa đổi khi dùng qua network — có thể phức tạp hóa việc review nội bộ ngay cả với triển khai thuần nội bộ. BSD không có điều khoản như vậy.

Phản ứng “quá trễ” của cộng đồng không chỉ là cảm xúc. Valkey đã tiến về phía trước. AGPLv3 của Redis 8 khiến nó một lần nữa là lựa chọn hợp lệ; kinh tế và đà phát triển thì không thay đổi.

Nếu bạn đang xây dựng lại toàn bộ backend stack, bài so sánh Supabase vs Firebase trình bày trade-off của managed database cho cùng đối tượng người đọc. Nếu phần migrate Node.js khiến bạn muốn tìm hiểu thêm về runtime, Bun vs Node phân tích lựa chọn runtime và các vấn đề tương thích liên quan.