Supabase sau Firebase: modelul datelor decide factura înaintea traficului

Pentru o aplicație care leagă clienți, comenzi și produse, Supabase oferă un punct de plecare firesc: fiecare proiect are o bază PostgreSQL dedicată, iar resursele de calcul sunt facturate independent de utilizarea bazei, potrivit regulilor de facturare Supabase. Pentru înregistrări care pot fi citite separat, Cloud Firestore din Firebase poate începe cu o factură mai mică, deoarece costul său urmărește operațiile asupra documentelor.

Diferența apare înainte ca traficul să devină mare: forma unui răspuns stabilește câte documente trebuie citite, iar numărul destinatarilor stabilește câte actualizări sunt livrate. Modelul Firestore Standard taxează 0,30 USD pentru un milion de citiri de documente în regiunea us-central1, după cota gratuită de 50.000 de citiri pe zi; actualizările primite prin ascultători în timp real contează tot ca citiri. Calculele de mai jos sunt scenarii ipotetice, nu facturi observate.

Ce se facturează în fiecare model

Tarifele Supabase includ în Free o bază de 500 MB și 5 GB de transfer, iar Pro pornește de la 25 USD lunar, include 8 GB pentru baza de date și 250 GB de transfer și acordă un credit lunar de 10 USD pentru calcul, suficient pentru o instanță Micro. Apelurile API nu au un preț separat pe cerere, însă interogările solicitante pot impune o instanță mai mare. Proiectele Free pot fi suspendate după o perioadă de inactivitate; această condiție contează pentru un serviciu care trebuie să rămână disponibil permanent.

Grila Firebase separă Spark, fără cost, de Blaze, cu plată după consum: Firestore Standard include 20.000 de scrieri pe zi, 1 GiB de date stocate și 10 GiB de transfer lunar fără cost, în timp ce autentificarea prin telefon se facturează per SMS pe Blaze, iar SQL Connect are propriile unități de facturare și folosește Cloud SQL pentru PostgreSQL. Prin urmare, cifrele pentru Firestore nu reprezintă prețul tuturor serviciilor Firebase. În scenarii sunt presupuse o lună de 30 de zile, prețurile în dolari SUA din us-central1 și absența altor servicii taxabile.

Aplicație relațională mică: aceeași sumă, altă structură

Presupunem un catalog cu clienți, comenzi și produse: 10.000 de afișări și 500 de scrieri zilnic, cu 300 MB ocupați și 3 GB transferați lunar. Dacă fiecare afișare citește în Firestore câte un document pentru comandă, client și produs, rezultă 30.000 de citiri pe zi. În aceste condiții, operațiile și resursele descrise încap atât în Spark, cât și în Supabase Free: costul calculat pentru ele este 0 USD. Scenariul presupune că dimensiunea contabilizată, inclusiv indicii Firestore, rămâne sub cota de stocare.

Egalitatea de pe factură ascunde muncă diferită. În PostgreSQL, entitățile pot sta în tabele legate prin chei, iar un răspuns le poate combina printr-o interogare. În Firestore, păstrarea lor în documente separate produce citirile din calcul; copierea numelui clientului sau a produsului în documentul comenzii poate reduce citirile acelui ecran, dar cere întreținerea copiilor când datele se schimbă. Aceasta este o consecință a schemei alese, nu o limită universală de trei citiri pentru orice comandă.

Dacă produsul va avea filtre și rapoarte care traversează relații, Supabase este alegerea mai ușor de justificat chiar și la același cost inițial. Dacă ecranele folosesc documente aproape autonome, Firestore poate păstra avantajul plății legate de operațiile efective. Valoarea planului gratuit, luată singură, nu surprinde timpul necesar pentru a modela datele și a modifica ulterior interogările.

Sincronizare în timp real: fiecare destinatar contează

Presupunem 20.000 de modificări zilnice ale unor documente, fiecare urmărită de zece clienți. În Firestore Standard, cele 200.000 de livrări zilnice ale documentelor actualizate înseamnă tot atâtea citiri; după cota gratuită rămân 4,5 milioane de citiri taxabile pe lună. La tariful precizat mai sus, acestea costă 1,35 USD pe Blaze. Cele 20.000 de scrieri zilnice se află la limita cotei gratuite. Calculul exclude încărcarea inițială a documentelor, reconectările, citirile suplimentare cerute de regulile de securitate și eventualele costuri de transfer.

În Supabase, contorizarea mesajelor Realtime atribuie unei modificări a bazei câte un mesaj pentru fiecare client care o urmărește; Pro include 5 milioane de mesaje lunar, apoi facturează pachete de un milion la 2,50 USD fiecare. Scenariul produce 6 milioane de mesaje, deci încă un pachet: 27,50 USD împreună cu abonamentul Pro, presupunând că un singur proiect Micro este acoperit de creditul pentru calcul și că celelalte cote nu sunt depășite. Acest rezultat privește distribuirea actualizărilor, nu toate operațiile aplicației.

Tipul mesajului schimbă și el calculul: o actualizare a bazei urmărită de clienți nu are aceeași contorizare ca un mesaj Broadcast trimis de aplicație. Numărul de utilizatori înregistrați nu arată câți ascultă simultan aceeași schimbare. Pentru un produs colaborativ, estimarea utilă pornește de la modificări și destinatari, apoi adaugă datele încărcate la conectare și volumul transmis.

Multe citiri: prețul mic depinde de răspuns

Presupunem un milion de citiri zilnice ale câte unui document, 300 MB stocați și 8 GB transferați într-o lună. În 30 de zile, Firestore înregistrează 30 de milioane de citiri; după cota zilnică gratuită, 28,5 milioane sunt taxabile. Costul calculat al citirilor este 8,55 USD pe Blaze, iar stocarea și transferul din ipoteză rămân în cotele gratuite. Spark nu acoperă consumul peste cota zilnică: pentru această estimare este necesar Blaze.

Același transfer depășește cota Supabase Free. Pe Pro, punctul de plecare este 25 USD lunar dacă instanța Micro poate susține interogările și nu apar alte depășiri. Prețul planului nu este o măsurătoare a capacității Micro: durata interogărilor, indicii și vârfurile de trafic pot schimba resursele necesare. Nici în Firestore un răspuns nu înseamnă automat o singură citire; o listă cu mai multe documente, citirile cerute de regulile de securitate sau anumite interogări peste indici pot mări totalul.

Autentificarea și migrarea schimbă costul alegerii

Autentificarea merită estimată separat de baza de date. Pentru conturi obișnuite, ambele platforme oferă funcții incluse în planurile lor, însă autentificarea prin SMS sau prin furnizori de identitate pentru organizații poate adăuga costuri și condiții proprii. O comparație limitată la citirile Firestore și mesajele Supabase ar lăsa aceste cheltuieli în afara rezultatului, la fel ca funcțiile de server, stocarea fișierelor ori transferul peste cote.

La migrare, portabilitatea datelor și portabilitatea aplicației sunt lucruri distincte. Tabelele PostgreSQL din Supabase oferă o schemă relațională ce poate fi mutată într-un alt mediu PostgreSQL, dar politicile de acces, autentificarea și codul care apelează serviciile Supabase trebuie adaptate. Trecerea de la Firestore la o bază relațională cere proiectarea tabelelor și cheilor din documente, apoi rescrierea interogărilor, a ascultătorilor de actualizări și a regulilor de acces. Migrarea în sens invers cere o nouă structură a documentelor și o decizie despre datele care vor fi copiate.

Pentru date cu multe relații și interogări care se schimbă odată cu produsul, costul de dezvoltare poate cântări mai mult decât diferența dintre facturile ipotetice. Pentru documente independente, citiri simple și distribuirea frecventă a actualizărilor, Firestore poate fi mai ieftin în scenariile calculate. Alegerea depinde de forma răspunsului cerut de aplicație, de câți destinatari primesc fiecare schimbare și de serviciile folosite alături de baza de date.

Citește și:

• Clockify sau Toggl Track: planul gratuit nu decide singur alegerea
• OBS sau Streamlabs: widgeturile pot costa mai mult decât editorul simplu
• Google Meet sau Zoom: limita gratuită schimbă alegerea înaintea funcțiilor IA