Valkey: il miglior sostituto open-source drop-in per Redis
A marzo 2024, Redis Inc. è passata dalla sua licenza permissiva BSD a RSALv2/SSPLv1, creando una reale esposizione alla conformità per i team di ingegneria commerciale.
In risposta, la community OSS e degli utenti ha quasi immediatamente effettuato il fork di Redis in una nuova opzione chiamata Valkey. Lanciato lo stesso mese sotto la Linux Foundation, Valkey offre un vero sostituto drop-in che evita il bagaglio legale introdotto da Redis.
Sostituisci Redis senza ricostruire le tue app
La risposte delle comunità alle modifiche apportate da Redis alla licenza è stata quella di cercare alternative rapide, coordinate e dotate di risorse adeguate, per lo più sotto forma di fork da parte delle comunità stesse. Valkey non è un fork di protesta con scarso sostegno. Valkey beneficia di un sostanziale sostegno istituzionale, supporto e sviluppo attivo; è quindi un'alternativa con licenza BSD completa e piena compatibilità con la codebase Redis che la maggior parte dei team sta già utilizzando.
Valkey: Rassicurazione integrata nel progetto e nel servizio
![[object Object]](https://assets.ovhcloud.com/1fiLCdLm2rnpzzL64g7Ebupwy_sN2JmNTk4MzJkMDY1NjMw/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_96bcf0ea.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fihA7kvoqCdjbpFh8CSqrAFg_sODM3OGYwNzczYjJhNGI5/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_a2fe1080.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fi4ELnwoChAbqnnwm3zvgAv5_sODJhOTlmMGI0OTUzYWJl/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_f9914d17.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiz8uqm8kwozpmrpt2nCdg5F_sNzRjNjI0Y2U4ZDlmOWQ0/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_fe1d1635.svg){kind=small}
Perché gli sviluppatori cercano un'alternativa a Redis nel 2026
Il cambio di licenza di Redis del 2024 spiegato
Redis è stato storicamente distribuito con la licenza BSD 3-Clause, una delle licenze open source più permissive. Era possibile utilizzare, modificare e costruire prodotti commerciali basati su Redis senza restrizioni. Tutto questo è cambiato il 20 marzo 2024, quando Redis Inc. ha annunciato che Redis 7.4 e tutte le future versioni con nuove funzionalità sarebbero passate a un modello a doppia licenza: RSALv2 (Redis Source Available License v2) e SSPLv1 (Server Side Public License). Nessuna delle due licenze è approvata dall'Open Source Initiative (OSI) ed entrambe pongono restrizioni esplicite su come il software può essere utilizzato in ambienti commerciali e cloud.
Perché la SSPL crea un rischio di conformità per i prodotti commerciali
La SSPL è stata originariamente scritta da MongoDB per impedire ai provider cloud di offrire servizi di database gestiti senza contribuire in cambio. Il problema principale per i team di prodotti commerciali è la Sezione 13: se l'applicazione viene resa disponibile come servizio e si basa su software con licenza SSPL, potresti essere tenuto a rilasciare il codice sorgente dell'intero stack del tuo servizio, inclusi i componenti proprietari che hai sviluppato.
Per la maggior parte dei team di ingegneria, un tale obbligo è un ostacolo insormontabile quando si sviluppano funzionalità e alternative. Anche laddove la consulenza legale stabilisce che il rischio è basso nella pratica, l'incertezza da sola crea attrito con gli acquisti, le revisioni di sicurezza e i contratti con i clienti aziendali. La RSALv2 aggrava la situazione vietando esplicitamente l'uso in prodotti o funzionalità concorrenti, conferendo a Redis Inc. ampia discrezionalità nel definire cosa costituisca concorrenza... lasciando ancora una volta gli utenti di Redis esposti a un campo minato di sfide legali: sfide che vengono facilmente evitate utilizzando invece codice regolato da una licenza approvata dall'OSI.
Rimanere su Redis 7.2: il debito di sicurezza nascosto
L'ultima versione di caching di Redis sotto BSD è stata la 7.2. Alcuni team scelgono di mantenere quella versione, piuttosto che accettare i nuovi termini di licenza. Probabilmente è una decisione pragmatica a breve termine che comporta un costo a lungo termine. Redis 7.2 non riceve più patch di sicurezza di ricerca o correzioni di bug da Redis Inc., il che significa che qualsiasi CVE scoperta dopo il cambio di licenza rimane irrisolta su quel ramo. Per i team che eseguono la cache di Redis 7.2 in un ambiente di produzione, che gestiscono dati sensibili o che operano nell'ambito di framework come NIS2 o SOC 2, questo non è un rischio teorico. Continuare a utilizzare Redis 7.2 comporta una lacuna di conformità che si aggrava di mese in mese.
Perché la AGPLv3 per Redis 8.0 non è una terza opzione
Con il rilascio di Redis 8.0 nel 2025, Redis Inc. ha compiuto un’altra mossa in materia di licenze, passando questa volta alla AGPLv3, approvata dall’OSI. È un vero passo avanti in termini di legittimità open source e affronta una delle critiche principali mosse al cambiamento del 2024. Tuttavia, la AGPLv3 è una licenza copyleft forte e introduce le proprie complicazioni per i team commerciali.
Qualsiasi software che interagisca con un componente concesso in licenza AGPLv3 tramite una rete potrebbe comportare l'obbligo di rendere pubblico il codice sorgente di tale software sotto la stessa licenza. Per i prodotti SaaS proprietari, questo continua a rappresentare un limite significativo per le alternative. Diverse figure di spicco del settore, tra cui alcuni collaboratori del progetto Valkey, hanno osservato che l’AGPLv3 (pur essendo più fedele ai principi rispetto alla SSPL) colloca comunque Redis in una categoria diversa rispetto alle alternative open source veramente permissive.
Preserva il comportamento dell'app e controlla la posizione dei dati
Anche le configurazioni multi-nodo possono mantenere modelli di resilienza già noti. La compatibilità richiede comunque dei test. I moduli, il comportamento specifico della versione e combinazioni insolite di comandi potrebbero produrre una risposta diversa. Anche la progettazione dell'archiviazione, le impostazioni del client e la topologia possono influire sulla stabilità o sulla velocità. Nessuna migrazione dovrebbe presupporre che ogni caso limite venga eseguito più velocemente o si comporti in modo identico. La licenza approvata dall'OSI di Valkey offre ai team commerciali un'alternativa open source duratura a Redis senza vincolare l'architettura dell'applicazione a termini restrittivi.
La scelta di implementazione aggiunge quindi una dimensione operativa. Una soluzione europea gestita può combinare elaborazione multi-thread, posizionamento resiliente dei nodi e hosting dei dati controllato. Questo approccio supporta la sovranità dei dati europea mantenendo visibili posizione, accesso e gestione contrattuale, riducendo al contempo l'amministrazione ordinaria della piattaforma.
In alcuni test, DragonflyDB risulta in testa in termini di velocità effettiva su un singolo nodo, ma tale vantaggio si riduce notevolmente nelle configurazioni a cluster. La parità di funzionalità con Redis 7.2 è stata completata e, da allora, la roadmap di Valkey ha previsto miglioramenti al multi-threading e una maggiore efficienza nella gestione della memoria che, in alcuni carichi di lavoro, lo rendono superiore alla versione da cui è stato creato il fork.
Altre tecnologie possono soddisfare requisiti specializzati, come la ricerca vettoriale o carichi di lavoro serverless intermittenti. La ricerca può includere materiale tecnico trovato tramite Google, discussioni della community e documentazione dei fornitori, ma la documentazione primaria e i test controllati dovrebbero avere un peso maggiore. Confronta ogni alternativa in base ai cambiamenti applicativi, alla maturità operativa, al supporto disponibile, alla governance e allo sforzo complessivo richiesto dalla migrazione. La tecnologia appropriata è quella che soddisfa i requisiti misurati con licenze e rischi operativi accettabili.
Adatta il modello operativo ai tuoi requisiti
Valkey gestito
I database gestiti di Valkey sono ideali per le aziende che desiderano operazioni semplici e costi di infrastruttura prevedibili. OVHcloud gestisce l'alta disponibilità, la manutenzione, il monitoraggio e i backup, riducendo il lavoro interno necessario per eseguire un servizio resiliente. La larghezza di banda e gli IOPS inclusi rendono anche la definizione del budget più chiara. Si tratta di una soluzione pratica predefinita quando i team di piattaforma hanno bisogno di Valkey senza doversi occupare di tutte le attività operative.
Valkey autogestito
L'autogestione consente di controllare le versioni del software, la topologia, le impostazioni di sicurezza e la posizione dell'implementazione. Può essere adatta ad aziende con requisiti specifici o operazioni di database consolidate. Gli svantaggi sono altrettanto reali: il team interno è responsabile di aggiornamenti, backup, osservabilità, test di failover e risposta agli incidenti. Le risorse della community sono utili, ma non sostituiscono un supporto alla produzione responsabile o la capacità operativa.
KeyDB
KeyDB potrebbe soddisfare le esigenze dei team che stanno studiando l'esecuzione multithread per specifici carichi di lavoro relativi ai dati in memoria e per determinati obiettivi di latenza. Valuta la compatibilità, l'attività di rilascio, lo stato di salute del progetto e il supporto disponibile prima di impegnarti. Esegui il benchmark dell'applicazione reale invece di presumere che una funzionalità architetturale migliorerà ogni pattern di richiesta. Anche le informazioni relative a un fondatore o alla dichiarazione iniziale del progetto dovrebbero essere verificate alla luce della documentazione attuale.
Alternative specializzate
I servizi serverless consentono di ridurre la pianificazione della capacità per i carichi di lavoro intermittenti, mentre i database vettoriali supportano la ricerca per somiglianza e altri modelli di dati specializzati. I software alternativi in-memory possono essere pensati per soddisfare esigenze specifiche in termini di velocità o persistenza. Questi strumenti possono risolvere problemi definiti, ma non sono necessariamente scelte immediatamente intercambiabili. Prima di optare per queste soluzioni anziché per Valkey, occorre tenere conto delle modifiche alle applicazioni, dello spostamento dei dati, della responsabilità operativa e dei costi a lungo termine.
Scegli un percorso di migrazione adatto al downtime
Arresta l'istanza di Redis per assicurare la coerenza dei dati, copia il file nella directory dei dati di Valkey, avvia Valkey e il gioco è fatto. Il tempo totale di migrazione è proporzionale alla dimensione del dataset, non alla complessità dell'applicazione. Per gli ambienti di produzione in cui il downtime non è accettabile, la replica live è il percorso più sicuro. Valkey può essere configurato come replica di un'istanza Redis 7.2 in esecuzione utilizzando il comando standard REPLICAOF.
Una volta che la replica è completamente sincronizzata, aggiorna la stringa di connessione della tua applicazione in modo che punti a Valkey, promuovila a primaria e disattiva l'istanza Redis. Poiché entrambi i sistemi utilizzano lo stesso protocollo di replica, questo processo è semplice e ben collaudato in ambiente di produzione dai team di tutti i principali fornitori di servizi cloud.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Costruisci un framework di preparazione alla migrazione in quattro parti
1. Compatibilità dell'applicazione
Crea un inventario di ogni comando, libreria client e versione di protocollo in uso. Registra le funzionalità RESP3, gli script Lua, le transazioni, i pattern pub/sub, le dipendenze JSON o dei moduli e il comportamento di timeout specifico dell'applicazione. Un core compatibile non dimostra che ogni estensione si comporti allo stesso modo. Confronta l'ambiente attuale con la versione di destinazione e testa le richieste rappresentative. Includi la gestione degli errori, il connection pooling e la logica di riprova. Se un'applicazione si basa su tecnologia fornita da un plugin esterno, verifica separatamente il suo stato di manutenzione. Questo inventario trasforma la compatibilità generale in prove basate su requisiti specifici.
2. Proteggi l'integrità dei dati
Misura il set di dati prima della migrazione, inclusi conteggi delle chiavi, distribuzione delle scadenze, dimensioni degli oggetti e consumo massimo di memoria. La destinazione necessita di memoria sufficiente per il normale funzionamento, la replica e il sovraccarico temporaneo durante la sincronizzazione o la persistenza. Esamina le impostazioni di snapshot e append-only invece di copiarle senza analisi. Dopo il trasferimento, confronta i conteggi delle chiavi, i valori campionati e il comportamento di scadenza. I controlli a livello di applicazione possono evidenziare problemi che i totali grezzi non rilevano, come sessioni non valide o lo stato incompleto della coda. Condividi i criteri di accettazione con i proprietari del servizio prima del passaggio, in modo che tutti utilizzino la stessa definizione di set di dati valido.
3. Mappa la topologia di destinazione
Documenta se la piattaforma attuale sia standalone, replicata o distribuita su un cluster. Registra ogni nodo, percorso di rete, regola di sicurezza, dipendenza DNS e posizione fisica. Questa mappa aiuta i team a selezionare un layout di destinazione che rifletta le esigenze di resilienza piuttosto che riprodurre scelte storiche. I test di connettività dovrebbero riguardare l'applicazione, i sistemi di monitoraggio e gli strumenti amministrativi. Per un carico di lavoro distribuito, verifica la gestione degli slot, il posizionamento delle repliche e il comportamento durante la perdita di un nodo. I requisiti di posizione dei dati possono anche determinare quali regioni o zone di disponibilità siano accettabili.
4. Controlla il cutover
Stabilisci le baseline di latenza, tasso di errore e risorse prima di spostare il traffico. Definisci le soglie di monitoraggio, i criteri di rollback e i responsabili delle decisioni mentre il servizio è stabile. Ciò impedisce ai team di discutere su quali siano i comportamenti accettabili durante un incidente. Sposta il traffico a fasi, laddove l'architettura lo consenta. Inizia con carichi di lavoro interni o a basso rischio, osserva gli errori dei client e confronta i risultati, quindi aumenta la quota. Mantieni la sorgente ripristinabile finché la convalida non è completa. Un cutover sicuro dipende da prove misurate, chiara responsabilità e un percorso di rollback, non solo da dichiarazioni di compatibilità.
Perché scegliere OVHcloud Managed Databases per Valkey
Una delle frustrazioni persistenti con i database gestiti nel cloud è l'imprevedibilità della fatturazione. Si pensi ai costi che aumentano vertiginosamente sotto carico, poiché la larghezza di banda, gli IOPS e lo spazio di archiviazione per i backup vengono fatturati separatamente. Il modello di prezzo di OVHcloud raggruppa questi costi in una tariffa mensile fissa. Larghezza di banda, operazioni di I/O e backup automatizzati sono inclusi, quindi il costo che vedi al momento del provisioning è il costo che paghi in produzione. Per i team finanziari e di approvvigionamento nelle scale-up che gestiscono budget infrastrutturali ristretti, questo rende la pianificazione della capacità significativamente più chiara.
