Il branching di Supabase non è un backup. Va solo in avanti.

Hai acceso il branching di Supabase perché sembrava il modo accurato di lavorare. Adesso accanto al tuo progetto c'è un branch di preview, le modifiche si provano lì prima che qualcuno le veda, e tutto l'impianto sembra parecchio più sicuro del mese scorso.

Ed è più sicuro. Solo che non è un backup, e la differenza si vede esattamente in un giorno.

Ecco il pezzo che le guide sul branching saltano: un branch è un secondo database accanto al primo, non una versione precedente di quello. Il branching è il posto dove vai prima di fare una modifica. Un backup è il posto dove vai quando qualcosa è già andato storto. Accendere il branching non deposita una copia dei tuoi dati da nessuna parte.

Il branching di Supabase è un backup?

No. Un branch parte come un database vuoto vestito con il tuo schema, e niente nel branching rimette a posto una versione precedente dei tuoi dati.

La documentazione di Supabase è diretta: «I branch nuovi non partono con nessun dato del tuo progetto principale. Questo serve a proteggere meglio i tuoi dati di produzione sensibili». Un branch viene costruito dalle tue migrazioni, e una migrazione descrive la forma di un database. Le tabelle, le colonne, le policy. Mai le righe.

Quindi il branch che sta accanto al tuo progetto non è la copia di martedì. È un database nuovo che non ha mai visto i tuoi utenti.

Se non hai mai stabilito cosa stia davvero copiando il tuo database, quello è esattamente il compito verso cui questo articolo vuole mandarti, e il tuo piano ne risolve la maggior parte in due minuti.

Cos'è davvero un branch

Un intero secondo progetto Supabase, con tutto il suo.

«Ogni branch è un ambiente separato con la propria istanza Supabase e le proprie credenziali API», così dice la documentazione. La sua stringa di connessione, le sue chiavi, il suo Storage, i suoi account di accesso, le sue righe. Niente al suo interno è collegato al progetto su cui stanno i tuoi utenti, ed è precisamente questo a rendere sicuro romperci qualcosa.

Quell'isolamento è tutta la funzionalità, ed è anche il motivo per cui non può fare anche da backup. La copia dei tuoi dati che speravi non è mai stata presa, e il posto dove andresti a cercarla è vuoto dal giorno in cui è nato.

Cosa fa un merge, e cosa non fa

Porta le tue modifiche di schema in produzione. Non porta mai righe, in nessuna direzione, in nessun momento.

Quando fai il merge, Supabase applica le migrazioni del tuo branch al tuo database di produzione e distribuisce le tue modifiche alle Edge Functions. Questo è tutto il carico. Una tabella nuova, una colonna nuova, una policy riscritta: quelle viaggiano. Le righe che hai creato provando restano nel branch, e le righe in produzione restano esattamente com'erano, comprese quelle che speravi di sostituire.

La gente si aspetta una versione di questo che non esiste: un merge che entri in produzione e rimetta le cose com'erano. Quello che il branching ha al suo posto è un deployment, applicato in avanti, su qualunque cosa si trovi in produzione in quel momento.

Ma io ho clonato i miei dati di produzione nel branch

Allora hai una copia delle tue righe, e tre cose di quella copia decidono quanto vale il giorno in cui ti servirà.

Si può fare e non è una cosa oscura. La CLI di Supabase descrive l'opzione come la clonazione dei dati di produzione nel database del branch, e l'API di management accetta la stessa opzione quando crea un branch. Se l'hai usata, il tuo branch contiene davvero i tuoi dati.

• È stata presa una volta. Il clone avviene alla creazione del branch e dopo niente lo aggiorna. Ogni ordine, ogni iscrizione e ogni commento da allora vive in produzione e da nessun'altra parte, ed è tutta lì la differenza tra una copia e un calendario.
• Sta dentro lo stesso account. Un branch è un altro progetto sotto la stessa organizzazione, sulla stessa carta, dietro lo stesso accesso. Ogni modo di perdere il tuo account Supabase si porta via anche il branch, e quello è un disastro diverso dal rovinarsi i propri dati.
• Nessuno l'ha riletta. Un clone rimasto a metà è identico da fuori a uno arrivato in fondo, fino al momento in cui lo apri.

Il branch è la parte progettata per sparire

Un branch di preview viene cancellato quando la sua pull request viene mergiata o chiusa. È il comportamento documentato della funzionalità.

Supabase definisce i branch di preview «effimeri e adatti a test mirati» e dice che «vengono cancellati automaticamente quando una PR viene mergiata o chiusa». L'altro tipo, i branch persistenti, sono «di lunga durata e consigliati per ambienti come staging, QA o sviluppo», e quelli sopravvivono alla chiusura della pull request.

Quindi con l'impostazione di default, il branch che tiene la tua unica copia clonata è proprio quello che il tuo flusso di lavoro butta il giorno in cui il lavoro finisce. Tenerlo significa renderlo persistente, e un branch persistente è un secondo progetto Supabase acceso. Supabase offre il branching sui piani a pagamento e lo fattura per branch e per ora, sulla loro pagina dei prezzi.

A cosa serve davvero il branching

A parecchio, e questo articolo sarebbe disonesto se non lo dicesse.

Un branch è il posto più economico che esista per scoprire che una migrazione elimina una colonna, prima che elimini la colonna su cui sono seduti i tuoi clienti. Ti lascia provare una modifica alle policy contro un database fatto esattamente come il tuo, con le sue chiavi, così che un errore non raggiunga nessuno. Dà a un'IA un posto dove sbagliare che non è la tua app in produzione. Un backup non può fare niente di tutto questo.

Il buco sta in che tipo di incidente copre. Il branching protegge le modifiche che passano da una pull request. La maggior parte di ciò che davvero costa i dati alla gente non ci passa mai vicino: una cancellazione nell'editor di tabelle di Supabase che ha preso più righe del previsto, uno script di seed puntato sul progetto in produzione, una migrazione scritta da un'IA e approvata all'una di notte, una ripulita di quelli che sembravano dati di prova. Nessuno di questi attraversa un branch mentre va in produzione, ed è lo stesso motivo per cui tornare indietro con il codice non riporta una tabella cancellata.

Quel secondo tipo di incidente è ciò a cui risponde un backup. Sta dietro di te nel tempo e tiene lo stato del tuo database a un momento che puoi nominare, così che un errore commesso fuori dal tuo flusso di lavoro abbia ancora un posto dove tornare.

È anche quello che è Reeve Care: copie programmate del tuo database Supabase, conservate fuori dal tuo account Supabase, rilette e verificate prima che una di esse conti come fatta. Collega i tuoi bucket Storage e i file caricati dai tuoi utenti viaggiano insieme, così un ripristino rimette le righe e le immagini a cui quelle righe puntano.

Tieni acceso il branching comunque. Niente di quanto sopra è un argomento per spegnerlo.

Cosa fare questa settimana

Prima di chiudere questa scheda, apri il tuo progetto Supabase e guarda se qualcosa ne sta prendendo una copia secondo un calendario. Quell'unica risposta è tutto il lavoro di oggi, e il branching non la cambia in nessun senso. La checklist di sicurezza in 10 minuti la copre insieme al resto di quello che vale la pena confermare su un'app appena lanciata, e cosa contiene una copia e cosa fa davvero il pulsante di ripristino è spiegato passo passo sulla pagina sui backup di Supabase.