Ce se întâmplă când o bază de date gratuită intră pe pauză

Orice bază de date găzduită gratuit se plătește undeva, iar într-un plan gratuit o parte din preț este disponibilitatea. Supabase pune pe pauză un proiect din planul Free care a stat liniștit o săptămână. Pentru un proiect secundar, schimbul este corect: o bază de date Postgres reală fără cost, în schimbul opririi unui server pe care nu îl folosește nimeni. Pentru orice depinde de o persoană, același comportament este o întrerupere programată, cu un email de avertizare atașat.

Întrebarea utilă nu este dacă pauzarea este bună sau rea. Ci ce face ea și ce trebuie să existe înainte să se întâmple. Practicile de mai jos fac dintr-o pauză un inconvenient, nu un incident.

Ce face de fapt pauzarea unui proiect

Un proiect pus pe pauză nu doarme cum doarme un laptop. Baza de date nu mai răspunde, iar proiectul nu este utilizabil până când cineva îl reia. Starea supraviețuiește: ghidul de pauzare al Supabase spune că un proiect reluat revine la starea anterioară, inclusiv datele și configurația.

Revenirea este o operațiune de platformă, nu un întrerupător. Ghidul de upgrade notează că proiectele Free trec pe ultima versiune minoră de Postgres când sunt restaurate. Baza de date pe care o primești înapoi poate să nu fie identică, iar restaurarea nu este un wake-on-LAN.

Când pune Supabase pe pauză un proiect Free

Supabase pune pe pauză proiectele din planul Free care arată activitate scăzută pe o perioadă de 7 zile, ca să economisească resurse de server. Un proiect este considerat inactiv dacă nu primește suficientă activitate de la utilizatori în baza de date în ultima săptămână. Ghidul este intenționat vag în privința pragului, apoi dă o regulă practică: de obicei, câteva cereri pe zi către baza de date, în săptămâna precedentă, sunt suficiente ca proiectul să nu fie pausat.

Două detalii contează mai mult decât numărul. Activitatea este activitate în baza de date, deci un dashboard fără interogări este candidat. Iar folosirea lui de către tine poate să nu fie suficientă: ghidul avertizează că volumul poate fi prea mic chiar dacă lucrezi la proiect. Planurile plătite nu sunt puse pe pauză pentru inactivitate.

Avertizarea vine înainte de pauză

Supabase trimite două emailuri proprietarului proiectului: un avertisment cu aproximativ o săptămână înainte ca pauza să se aplice și o confirmare după ce proiectul a fost pausat. În intervalul de avertizare, pauza poate fi evitată fie vizitând proiectul în dashboard, fie făcând apeluri API către el.

Emailul acela este termenul real, nu ceasul de șapte zile. Ajunge la proprietarul proiectului, nu la fiecare membru al organizației, așa că verifică dacă adresa este citită de o persoană. Noi tratăm avertismentul ca momentul în care proiectul primește activitate sau este mutat.

Cum recuperezi un proiect pausat

Traseul documentat este în dashboard: deschizi organizația, selectezi proiectul pausat, apeși Resume project și confirmi. Nu există o procedură separată de învățat. Ghidul nu spune cât durează reluarea, așa că nu dăm o durată. Dacă proiectul contează, tratează reluarea ca o operațiune care cere o persoană și o verificare după.

După reluare, verifică trei lucruri: aplicația se conectează, rândurile pe care le aștepți există și orice job programat care indica baza de date și-a revenit. O pauză nu pune munca în coadă. Un webhook care a rulat cât proiectul era oprit a eșuat.

Fereastra de restaurare este documentată cu două numere

Aici documentația este inconsistentă intern, iar inconsistența contează pentru că este diferența dintre a planifica un trimestru și a planifica un an.

Textul ghidului de pauzare spune că poți restaura un proiect pausat până la 1 an de la momentul pauzei, iar secțiunea despre fereastra de restaurare repetă că există o fereastră de 1 an. Ancora aceleiași secțiuni este 90-day-window-to-restore. Changelogul Supabase din iunie 2024 anunța că proiectele Free pausate sunt restaurabile 90 de zile de la data pauzei. Pagina din knowledge base despre recuperarea unui proiect expirat are slug-ul restore-project-after-90-days-pause, iar titlul spune mai mult de 1 an.

Singura afirmație datată este changelogul de 90 de zile. Cifra de 1 an apare în textul actual, dar ancora propriei secțiuni nu a fost actualizată.

Sfatul nostru este să planifici pe perioada mai scurtă. Nouăzeci de zile este numărul pe care te poți baza fără să aștepți ca documentația să fie de acord cu ea însăși, iar un proiect pausat un trimestru fără ca nimeni să observe are altă problemă. Tratează un an ca pe o posibilă extensie, nu ca pe un termen limită.

Ce se întâmplă la finalul ferestrei este documentat. Opțiunea de restaurare este înlocuită cu una de descărcare a ultimului backup logic, luat chiar înainte de pauză, împreună cu toate obiectele din Storage. După ce proiectul este șters, toate datele asociate, inclusiv backup-urile, sunt eliminate definitiv și nu mai pot fi recuperate. Ghidul explică de ce: backup-urile sunt păstrate doar o perioadă limitată, iar schimbările de platformă pot să nu fie compatibile cu cele vechi. Backup-ul static al unui proiect pausat nu poate fi actualizat ca să urmeze acele schimbări.

Ghidul de backup descrie backup-uri zilnice doar pentru Pro, Team și Enterprise și recomandă proiectelor gratuite să își exporte regulat datele cu comanda db dump din Supabase CLI și să păstreze copii în afara platformei. Un backup de bază de date nu include nici obiectele încărcate prin Storage API; acelea trebuie copiate separat.

Dacă ești pe un plan gratuit, indiferent de furnizor

Supabase este exemplul de aici pentru că documentația lui este publică și precisă, dar forma este comună. Un plan gratuit care oprește resursele inactive le va opri și pe ale tale. Patru practici acoperă cea mai mare parte a riscului și niciuna nu depinde de logo-ul din dashboard.

Păstrează un dump pe care îl poți restaura altundeva

Rostul unui dump este portabilitatea, nu stocarea. Un dump logic se restaurează în orice Postgres compatibil, la orice furnizor sau pe mașina ta. Am scris despre disciplina de a testa un backup înainte să ai nevoie de el, iar ea se aplică aici neschimbată.

La Supabase, supabase db dump rulează pg_dump și lasă deoparte schemele interne. O singură comandă nu este un backup complet: referința CLI spune că dump-ul implicit nu conține date sau roluri personalizate, iar schemele ignorate includ auth și storage. Un set util este un dump de schemă, unul de date cu --data-only, unul de roluri cu --role-only și o copie separată a fișierelor din Storage. Scrie-le în afara furnizorului, păstrează mai mult de o generație și restaurează din când în când cel mai nou dump într-o bază de test. Un dump care nu a fost restaurat niciodată este o presupunere.

Dacă proiectul a trecut deja de fereastra de restaurare, pagina din knowledge base oferă totuși o ieșire: descarci backup-ul și obiectele din Storage, creezi un proiect nou și încarci fișierul cu psql. Supabase documentează și restaurarea locală a unui backup descărcat cu supabase db start --from-backup. Ghidul avertizează că o bază de date pornită din CLI nu este pregătită de producție. Este o cale de recuperare pentru inspecție, nu un plan de găzduire.

Ține proiectul treaz sau ține o verificare care îți spune când s-a oprit

Sunt două treburi diferite și e ușor să cumperi una crezând că ai luat cealaltă. Un keep-alive este o cerere programată care contează ca activitate în baza de date: o interogare mică prin API, o dată pe zi, este tipul de trafic documentat. O verificare este o cerere care eșuează zgomotos când proiectul nu mai răspunde, cu o alertă care ajunge la o persoană.

Keep-alive-ul are propriul mod de eșec: scheduler-ul face acum parte din stivă, iar dacă se oprește, proiectul intră pe pauză în liniște. O verificare fără alertă nu este o verificare. Dacă proiectul trebuie să răspundă când nu veghează nimeni, un plan gratuit este gazda greșită: pauza este o caracteristică a planului, nu un bug pe care îl configurezi să dispară.

Cunoaște canalul de avertizare

Află ce adresă primește emailul de pauză și asigură-te că o citește o persoană. La Supabase este proprietarul proiectului. Dacă persoana a plecat sau adresa este un alias de tip no-reply, primul avertisment pe care îl primești este întreruperea. Pune o notă recurentă în calendar pentru momentul în care un proiect liniștit ar fi pausat și verifică starea în dashboard când ceva a stat neatingut o vreme. Avertismentul este o curtoazie, nu o garanție: filtrele, regulile de forwardare și adresele schimbate îl pot rupe.

Decide dinainte când proiectul nu mai este un proiect secundar

Scrie criteriul înainte să ai nevoie de el. Proiectul a trecut linia când depinde de el altcineva decât tine, când ține date pe care nu le poți reconstrui, când încasează bani sau are o obligație legală, când un client îl va vedea la o oră stabilită sau când trebuie să răspundă în afara programului tău. Oricare dintre ele este suficientă.

Trecerea la un plan plătit elimină pauza: Supabase afirmă că proiectele din planurile plătite nu sunt puse pe pauză pentru inactivitate. Pagina de prețuri listează planul Free la 0 dolari, cu 500 MB de bază de date pe proiect și o limită de două proiecte active, iar Pro de la 25 de dolari pe lună. Abonamentul nu este tot costul: compute-ul se facturează pe proiect, la oră, iar discul și egress-ul au cote incluse și prețuri pe unitate după ele. Decizia nu este gratuit sau 25 de dolari. Este dacă ținerea în viață a unui proiect gratuit costă mai puțin decât o factură care crește cu folosirea.

Cât costă fiecare alegere

• Rămâi pe gratuit și accepți pauza. Fără abonament. Costul este o întrerupere de durată nedeclarată de fiecare dată când proiectul tace, plus o restaurare care poate muta baza de date pe o versiune minoră mai nouă. Timpul tău de recuperare este timpul tău de detectare.
• Rămâi pe gratuit și ții proiectul treaz. Un scheduler, o interogare pe zi și o alertă de monitorizare. Costul este atenția și o piesă mobilă în plus, care poate eșua în tăcere. Bun pentru un demo, firav pentru un serviciu cu utilizatori.
• Treci pe plătit. Un abonament recurent plus compute, disc și egress facturate pe consum. În schimb, pauza dispare, iar planul include backup-uri zilnice păstrate șapte zile, care scurtează un alt tip de întrerupere.

Primelor două nu le-am pune un număr. Se plătesc în ore, la cât te costă o oră de downtime.

Unde ajungem

Pauzarea gratuită este o alegere rezonabilă pentru un proiect care este încă un experiment. Este o potrivire slabă pentru orice a încetat să mai fie unul. Linia se trece mai devreme decât recunosc majoritatea, de obicei în momentul în care o a doua persoană începe să se bazeze pe lucrul acela.

Dacă rămâi pe planul gratuit, fă acum partea plictisitoare: un dump pe care l-ai restaurat o dată, o alertă care ajunge la tine, adresa de avertizare verificată și un criteriu scris pentru trecerea la plătit. Cele patru transformă o pauză dintr-o urgență într-o sarcină de mentenanță. Dacă proiectul contează deja, plătește pentru el și folosește atenția pentru aplicație, nu pentru a împiedica gazda să îl oprească.