Valkey vs Redis: Haruskah Anda Migrasi Setelah Fork?

Selama lebih dari satu dekade, Redis adalah jawaban default untuk caching, rate limiting, penyimpanan sesi, dan antrean pekerjaan. Lalu pada Maret 2024 Redis Ltd mengubah lisensinya, dan dalam seminggu jawaban itu punya nama kedua: Valkey. Saya menjalankan instance yang kompatibel dengan Redis di VPS sendiri dan mengandalkan cache terkelola di kantor, jadi ketika fork terjadi saya harus benar-benar memutuskan apa yang akan dipasang ke depan. Tulisan ini adalah keputusan yang saya lalui, tanpa kebisingan perang lisensi di Twitter.

Versi singkatnya: ini bukan lagi cerita tentang perusahaan yang mengkhianati komunitasnya. Redis berbalik arah, kedua proyek kembali menjadi open source, dan kedua basis kode mulai menyimpang dengan cara yang menarik. Itu membuat perbandingannya lebih bernuansa daripada yang bisa ditangkap sebuah judul, jadi mari kita telusuri dengan benar.

Bagaimana kita sampai di sini: linimasa lisensi

Anda tidak bisa menimbang trade-off tanpa mengetahui urutan kejadiannya, karena hal yang ditakuti semua orang pada 2024 sudah tidak ada lagi pada 2026. Inilah rangkaian keputusan yang sebenarnya.

• Sebelum Maret 2024: Redis dirilis di bawah lisensi permisif BSD 3-Clause — keluarga lisensi yang sama yang kini dipakai Valkey.
• Maret 2024: Redis Ltd beralih ke model source-available ganda (RSALv2 dan SSPLv1). Keduanya bukan open source yang disetujui OSI, yang memicu perpecahan.
• Beberapa hari kemudian: para maintainer sebelumnya mem-fork Redis 7.2.4 dan, didukung AWS, Google, Oracle, dan Ericsson, menempatkannya di bawah Linux Foundation sebagai Valkey, berlisensi BSD.
• Mei 2025: Redis berbalik arah dan menambahkan AGPLv3 — lisensi open source yang disetujui OSI — ke Redis 8, di samping tingkatan source-available-nya.

Jadi keduanya kini open source. Namun AGPLv3 adalah lisensi copyleft dengan kewajiban nyata jika Anda memodifikasi server dan mengeksposnya lewat jaringan, sementara BSD 3-Clause milik Valkey hanya meminta atribusi. Jika tim hukum Anda pernah bergidik mendengar huruf AGPL, perbedaan itu saja bisa menentukan jawabannya.

Apa yang sebenarnya berubah di balik layar

Pada tahun pertama, Valkey pada dasarnya adalah Redis 7.2 dengan logo berbeda. Itu tidak lagi benar. Sejak fork, Valkey merilis 8.0 dan 8.1 dengan rekayasa yang tidak dimiliki Redis OSS pada waktu yang sama, dan di sinilah kedua proyek benar-benar menyimpang.

• I/O threading asinkron (8.0): pembacaan jaringan, parsing, dan penulisan respons dipindahkan ke thread I/O sementara eksekusi perintah tetap single-threaded, mendorong throughput melewati satu juta permintaan per detik pada perangkat keras yang sesuai.
• Hashtable yang didesain ulang (8.1) yang memangkas sekitar 20 hingga 30 byte overhead per kunci, yang berarti penghematan nyata dalam skala besar.
• Prefetching iterator yang membuat perintah seperti KEYS dan sinkronisasi replikasi sekitar 3,5 kali lebih cepat, ditambah peningkatan tertarget seperti ZRANK hingga 45 persen lebih cepat untuk leaderboard.
• Logging terstruktur (logfmt dan ISO 8601) serta COMMANDLOG untuk melacak permintaan berukuran besar — sentuhan operabilitas kecil yang terakumulasi.

Redis juga tidak diam. Redis 8 membawa percepatan perintahnya sendiri dan menambahkan Vector Sets untuk pencarian embedding. Intinya bukan bahwa satu secara universal lebih cepat — melainkan keduanya kini dua produk terpisah dengan roadmap terpisah yang kebetulan berbagi leluhur.

Kompatibilitas drop-in: seberapa dekat sebenarnya?

Karena Valkey di-fork dari Redis 7.2.4 dan mempertahankan protokol RESP serta seluruh set perintah, kode aplikasi Anda tidak perlu berubah. Pustaka klien yang sama tersambung, perintah yang sama berjalan, berkas RDB dan AOF termuat. Di server saya sendiri, saya menghentikan kontainer Redis, menjalankan kontainer Valkey yang menunjuk ke direktori data yang sama, dan aplikasi tidak menyadari apa pun.

# Same client, same commands — this is the whole point
redis-cli -h cache.internal ping        # PONG
redis-cli -h cache.internal info server | grep -E 'redis_version|server_name'
# On Valkey you'll see something like:
#   server_name:valkey
#   valkey_version:8.1.0
#   redis_version:7.4.0   <- reported for client compatibility

Peringatan kompatibilitas lainnya adalah modul Redis berpemilik — RediSearch, RedisJSON, RedisBloom, dan Vector Sets yang lebih baru. Itu adalah fitur Redis Ltd dan bukan bagian dari Valkey. Valkey punya cerita modulnya sendiri dan padanan komunitas, tetapi jika tumpukan Anda bergantung khusus pada RediSearch, itulah batas yang membuat migrasi tidak sepele.

Valkey vs Redis sekilas

Jadi haruskah Anda migrasi?

Jawaban jujur saya, untuk cache atau penyimpanan sesi biasa, keputusannya berisiko rendah di kedua arah — itulah justru mengapa Anda sebaiknya memilih opsi dengan ikatan hukum yang lebih sedikit sebagai default. Beginilah cara saya membaginya.

• Migrasi ke Valkey jika Anda self-host, menginginkan lisensi permisif BSD, peduli pada tata kelola netral vendor, atau ingin peningkatan memori dan threading 8.x tanpa pertanyaan lisensi.
• Tetap di Redis jika Anda bergantung pada RediSearch, RedisJSON, atau Vector Sets, nyaman dengan AGPLv3, atau berjalan penuh di Redis Cloud dan menghargai dukungan bawaan.
• Belum melakukan apa pun jika Anda memakai Redis terkelola yang berjalan baik tanpa tekanan lisensi, biaya, atau fitur — migrasi tanpa alasan hanyalah risiko sia-sia.

Bagaimana saya menjalankan migrasinya

1. Inventarisasi penggunaan Anda: dump set perintah dan periksa modul berpemilik dengan MODULE LIST sebelum mengasumsikan pergantian mulus.
2. Sematkan dan uji klien: tingkatkan pustaka klien Redis Anda ke versi terkini dan jalankan suite integrasi terhadap kontainer Valkey lokal.
3. Replikasi, bukan dump-lalu-berdoa: arahkan replika Valkey ke primary Redis Anda dengan REPLICAOF, biarkan tersinkron, lalu promosikan saat jendela pemeliharaan.
4. Pindahkan dan pantau: ganti connection string, jaga Redis lama tetap hangat untuk rollback cepat, dan pantau latensi serta tingkat error selama satu siklus lalu lintas penuh.

# Live migration via replication (zero-dump)
# On the new Valkey instance:
valkey-cli> REPLICAOF redis-primary.internal 6379
valkey-cli> INFO replication        # wait for master_link_status:up

# Once fully synced, promote Valkey to standalone:
valkey-cli> REPLICAOF NO ONE
# ...then repoint your app's connection string and keep Redis warm for rollback.

Setelah melakukan ini di infrastruktur saya sendiri, pergantian untuk cache biasa benar-benar tanpa insiden — pekerjaan menariknya adalah audit versi klien dan memastikan tidak ada modul berpemilik yang terpakai, bukan pemindahan data itu sendiri. Itulah keseluruhan cerita drop-in yang baik: migrasi yang membosankan adalah migrasi yang berhasil.