2024年3月、チームのSlackに「RedisがBSDライセンス廃止するらしい」という一言が流れてきた。最初は「また誇張された記事か」と思って無視した。でも翌朝、GitHubのリリースページを確認して本当だと分かった瞬間、「あ、これは面倒なことになった」と思った記憶がある。
うちのチームは4人のバックエンドエンジニアで構成されていて、当時Redis 7.2をキャッシュとセッション管理の中心に据えていた。問題なく動いていたし、乗り換える理由もなかった。でもライセンス変更という言葉は、エンジニアリング判断を超えた問題を含んでいることが多い。法務を巻き込んで長い議論をして、最終的には「とりあえず様子見」という判断になった。
あれから約2年。今はValkeyに完全移行している。この記事はその経緯と、2026年3月時点での正直な比較をまとめたもの。
SSPLとは何か — BSDと何が違ったのか
まず事実の整理から。2024年3月20日、Redis Ltd.はRedis 7.4以降のライセンスを「Redis Source Available License v2（RSALv2）」と「Server Side Public License（SSPL）」のデュアルライセンスに変更した。
SSPLは元々MongoDB社が2018年に作ったライセンス。OSI（Open Source Initiative）はこれを非オープンソースと判定している。BSD-3-Clauseとの決定的な違いはこの条項だ：Redisをサービスとして提供するなら、そのサービスを動かすインフラ全体のソースコードを公開しなければならない。
AWSやGoogle Cloud、Alibabaにとって、これは実質的に「うちのサービスでRedisを使い続けるなら、クラウドインフラ全体のコードをオープンにしろ」という要求に等しい。受け入れられるわけがない。だから大手クラウドプロバイダーが即座にフォークへ飛びついたのも、振り返れば当然の話だった。
正直に言うと、中小規模のSaaSや社内利用が主な私の立場では、SSPLの法的影響は直接的には薄い。問題は「オープンソースかどうか」という哲学的な部分と、エコシステムの先行きに対する不安だった。主要クラウドが支援を引いたら、コミュニティがどうなるか。その不確実性が判断を鈍らせた。
Valkeyが生まれるまでの9日間
Redisのライセンス変更発表から9日後の2024年3月28日、Linux Foundationが動いた。Redis 7.2.4をフォークした「Valkey」プロジェクトが正式に発表された。
初期コントリビューターのリストを見たとき、少し驚いた。AWS、Google Cloud、Oracle、Ericsson、Snap。これだけの企業が素早くコミットしてきた。
通常、こういうフォークプロジェクトは最初の熱量が高くても数ヶ月で失速することが多い。でも今回は構造が違うと思った。Linux Foundationが傘を張っているのと、主要クラウド企業が自社のビジネス上の理由でコミットし続けるインセンティブを持っている。これは単なる「理念のフォーク」じゃない。
Valkey 7.2が2024年4月にリリースされ、同年9月にはValkey 8.0が出た。
Valkey 8.0で個人的に注目したのはI/Oスレッドの改善。Redisはシングルスレッドアーキテクチャで有名だけど、Valkeyはここに手を入れてマルチスレッドI/O処理を強化している。高スループットのユースケースで意味のある差が出始めた。
一方のRedis側も手をこまねいていたわけじゃなく、Redis 8.0（2025年リリース）では以前モジュールとして別売りだったRedis StackのVector Search、JSON、Time Series等をコアに統合した。機能は豊富になった。ライセンスはSSPLのままで。
2週間ベンチマークして気づいたこと
移行を検討し始めた頃、自分でベンチマークを取った。環境はAWS EC2（r6i.xlarge、4 vCPU / 32GB RAM）、redis-benchmarkで50コネクション、100万リクエスト。
# 両環境で同一コマンドを実行（ホスト名だけ変える）
redis-benchmark -h ${HOST} -p 6379 -c 50 -n 1000000 -q
# 結果サマリ（抜粋）
# Redis 7.4: SET: 198,423 req/s GET: 212,765 req/s
# Valkey 8.0: SET: 214,891 req/s GET: 219,043 req/s
正直に言うと、差は「誤差範囲に近い」。SETで約+8%、GETで約+3%でValkeyが速い数字が出たが、うちのユースケース（1秒あたり数千リクエスト程度）では体感できる差ではない。
ここで予想外のことが起きた。WAITコマンドのレプリケーション挙動が微妙に違う。Valkey側でレプリカへの伝搬タイミングが特定の条件下でわずかにずれるケースがあって、これを検出するのに数日かかった。ドキュメントには記載がなく、GitHubのissue（#891付近のスレッド）を掘り返してやっと理解した。
こういう「互換性が高いが完全ではない」という落とし穴は、移行前に頭に入れておくべきだと思う。99%は動く。でも残りの1%が深夜に牙を剥く。
移行作業の現実 — スムーズだった部分と詰まった部分
ローカルで最初に試したのはDockerでの起動から。
# docker-compose.yml（本番に近い設定で試す）
services:
valkey:
image: valkey/valkey:8.0-alpine
ports:
- "6379:6379"
volumes:
- valkey_data:/data
command: >
valkey-server
--save 60 1
--loglevel warning
--maxmemory 512mb
--maxmemory-policy allkeys-lru
healthcheck:
test: ["CMD", "valkey-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
volumes:
valkey_data:
valkey-cliはredis-cliと同じコマンド体系なので、使い慣れた人ならほぼ違和感ない。INFO serverの出力でサーバー名がValkeyになっているのを見たとき、「あ、ちゃんと別物なんだな」と妙な感動があった。
アプリ側（Node.js + ioredis）は変更ゼロ。接続ホスト名を変えただけで動いた。これは本当に助かった。
本番への移行は、新しいValkeyクラスタを立てて既存Redisからデータを流し込む方法をとった。セッションデータはTTLがあるので、移行期間だけ両クラスタにデュアルライトする構成にして旧Redisを徐々にフェードアウト。この作業を金曜の夕方に始めたのは今思えば判断ミスで、翌朝3時まで監視することになったが、実際のエラーは発生しなかった。
AWSのElastiCache for Valkeyへの対応（2024年後半から提供開始）が想定より早かったのも助かった点だ。マネージドサービスをそのまま使えるのはインフラ管理の手間を考えると大きい。Sentinel構成からの移行も、コマンド互換性のおかげで思ったよりスムーズだった。
2026年現在の私の判断
新規プロジェクトはValkey一択。既存のRedisは積極的に移行を検討する価値がある。
Valkeyを選ぶ理由は二つ。ライセンスの安心感と、大手クラウドプロバイダーのマネージドサービス対応が本格化している点。AWS ElastiCache for Valkey、GCP Memorystore for Valkeyはどちらも本番実績が積み上がってきた。コミュニティのコミット速度も、2024年の熱量が2年経った今も落ちていない。
Redisが有利な場面も正直残っている。Redis StackのVector Search機能は、Valkeyのそれと比べて2026年3月時点ではまだ成熟度が高い。AIアプリのembeddingキャッシュやセマンティック検索用途で使うなら、Redisのほうが安定しているというのが私の現在の評価。ただし、SSPLライセンスを受け入れる前提で。
テラバイト規模のクラスタリング周りについては、うちが本番で扱っているのは500GB程度なので、正直そこから先は自分の実体験の範囲外になる。その規模で使っている人の話があれば聞きたい。
2年前に「様子見」と判断したのは間違いではなかった。でも今の時点で様子見を続ける理由はもうない。移行の手間は思ったより低く、法的・エコシステム的なリスクはValkeyのほうが明らかに低い。先延ばしにするメリットが見当たらない、というのが正直なところ。