Supabase eller Firebase? Datamodellen påvirker prisen

Vælg Supabase, hvis produktet bygger på mange relationer mellem brugere, teams og projekter. Vælg Firebase med Cloud Firestore, hvis appen især skal synkronisere dokumenter mellem klienter, og hosting og andre app-tjenester skal indgå i samme økosystem. Zapiers sammenligning beskriver forskellen mellem Supabases relationelle PostgreSQL-database, Firestores dokumentmodel og Firebases bredere udvalg af tjenester.

Regningen afhænger derfor af, hvordan produktet organiserer og henter data, før gratisgrænserne overhovedet kan sammenlignes. Den samme projektoversigt kan kræve en forespørgsel på forbundne tabeller eller læsning af flere dokumenter. Forbruget bestemmes også af, hvor ofte data ændres, hvor mange klienter der modtager ændringerne, og hvor meget der sendes ud.

Relationer og dokumenter giver forskellige læsemønstre

I en relationel SaaS-tjeneste kan en bruger høre til flere teams, mens hvert team ejer projekter med opgaver. PostgreSQL kan forbinde tabellerne i en forespørgsel, og en fælles oplysning kan opdateres ét sted. Det kræver, at relationer og adgangsregler er tænkt ind i modellen, men gør sammenhængene mellem data eksplicitte.

Cloud Firestore organiserer data som dokumenter i samlinger. En visning kan hentes med få læsninger, hvis de nødvendige oplysninger ligger i få dokumenter. Skal den vise oplysninger fra mange projekter, ejere og medlemskaber, kan den kræve flere dokumentlæsninger. Alternativt kan nogle oplysninger kopieres ind i andre dokumenter, hvilket øger arbejdet med at holde kopierne ajour. Antallet af læsninger kan derfor ikke udledes af brugertallet alene.

Sammenligningen bruger Cloud Firestore som Firebase-database. Firebase tilbyder også SQL Connect med PostgreSQL, men den løsning har andre drifts- og prisposter. Firestores læsekvote beskriver ikke forbruget i en app bygget med SQL Connect.

Kvoterne måler forskellige ting

Supabases prisoversigt angiver på Free-niveauet 50.000 månedligt aktive brugere, 500 MB databaseplads, 5 GB almindelig udgående trafik, 5 GB cachelagret udgående trafik, 1 GB fillager, 200 samtidige Realtime-forbindelser og 2 millioner Realtime-beskeder om måneden; Pro begynder ved 25 dollar om måneden og omfatter blandt andet 8 GB databaseplads, 100 GB fillager og 250 GB i hver af de to trafikkategorier. En databaseforespørgsel har ikke en særskilt pris pr. dokumentlæsning som i Firestore, men den kan bruge trafik og regnekraft. Free-projekter kan desuden blive sat på pause efter inaktivitet.

Firebases prisoversigt angiver for Cloud Firestore Standard 1 GiB lagrede data, 50.000 dokumentlæsninger og 20.000 skrivninger pr. dag samt 10 GiB udgående trafik om måneden uden betaling; for nye Cloud Storage-buckets på Blaze viser den 5 GB-måneder lager, 100 GB downloads, 5.000 uploads og 50.000 downloadoperationer pr. måned uden forbrugsbetaling. Hosting har sine egne poster. En ledig kvote i én tjeneste kan altså ikke dække et overforbrug i en anden, og en dagsgrænse kan overskrides, selv om månedens gennemsnit virker lavt.

Regneeksempel: En relationel SaaS-tjeneste

Antag en tjeneste med 10.000 månedligt aktive brugere, 400 MB databaseforbrug og 4 GB almindelig udgående trafik om måneden. Antag, at en udgave med Cloud Firestore bruger 20.000 dokumentlæsninger og 5.000 skrivninger hver dag, mens dens samlede databaseforbrug inklusive indeks og metadata er 400 MB. Med de antagelser ligger de nævnte database- og trafikmål inden for begge platformes gratis kvoter. Webhosting, fillager og andre tjenester er ikke med i eksemplet.

Forskellen opstår, når en projektoversigt skal vise ejere, medlemskaber og opgaver. I PostgreSQL kan visningen hente forbundne rækker; i Firestore afhænger læsetallet af, hvor mange dokumenter visningen henter, og hvilke oplysninger der er kopieret ind i dem. Kopier kan spare læsninger i én visning, men kræve flere skrivninger, når oplysninger ændres. En prognose for denne tjeneste må derfor beskrive de vigtigste visninger og deres faktiske læse- og skrivemønstre, ikke blot antallet af brugere.

Regneeksempel: Mange samtidige læsere

Antag 100 klienter, som lytter til den samme oplysning i én time hver dag, mens den ændres 10 gange i minuttet. Over 30 dage giver det 600 ændringer dagligt og 1,8 millioner leveringer til klienterne i alt. Hvis hver ændring i Supabase sendes som én Realtime-besked til hver klient, ligger det beregnede antal leveringer under Free-kvoten. Der er dog kun begrænset plads til andre beskeder i samme måned, og forbindelser, trafik samt øvrigt forbrug skal også holde sig inden for deres grænser.

Firestores faktureringsregler tæller en dokumentlæsning, hver gang et dokument i en aktiv lytters resultat tilføjes eller opdateres. Med ét dokument og de antagne klienter giver ændringerne mindst 60.000 læsninger om dagen, altså mindst 10.000 over gratisgrænsen for Cloud Firestore Standard. Første hentning, genforbindelser og eventuelle læsninger til sikkerhedsregler kan øge tallet. Samme opdateringsrytme giver kun 600 skrivninger dagligt på det fælles dokument: her er det antallet af modtagere ganget med ændringer, der først flytter regnestykket.

Regneeksempel: Filer med høj trafik

Antag 2 GB brugerfiler, 120 GB downloads, 40.000 downloadoperationer og 1.000 uploads på en måned. I Supabase overskrider både lageret og downloadtrafikken Free-grænserne. De antagne mængder ligger inden for Pro-planens inkluderede fillager og trafik, men Pro-abonnementet bliver en del af regningen, og database, Realtime og andre ressourcer skal fortsat vurderes særskilt.

For en ny Firebase Storage-bucket giver de angivne gratismængder et overskud på 20 GB downloads, mens lager og antal operationer holder sig under deres respektive grænser. Den beregning forudsætter en bucket i en region, hvor Googles gratisniveau gælder: Firebases regler for Storage-buckets kræver Blaze-planen og knytter gratisniveauet for nye buckets til US-CENTRAL1, US-EAST1 og US-WEST1. Vælges en europæisk region, kan de amerikanske gratismængder ikke bruges som prisestimat for en dansk tjeneste.

Filer, der downloades fra Cloud Storage, bruger ikke en ledig Hosting-kvote. Det samme skel er nødvendigt på Supabase, hvor almindelig og cachelagret udgående trafik har hver sin kvote. Downloadmønster og placering betyder derfor mere for dette eksempel end antallet af filer alene.

Hosting og en senere flytning

Firebase kan samle database, synkronisering, webhosting og appanalyse i samme produktopsætning. Supabase leverer database, login og fillager, mens webappen normalt skal hostes andetsteds. Den hostingpost hører med i et samlet budget, også når databasen passer inden for gratisniveauet.

Valget påvirker også arbejdet ved en senere migration. Fra Firestore til PostgreSQL skal dokumenter og eventuelle kopierede felter omsættes til tabeller, relationer og nye forespørgsler. I den anden retning skal relationelle visninger planlægges som dokumentlæsninger og opdateringer. Hvor omfattende arbejdet bliver, afhænger af adgangsreglerne, klienterne og hvor mange funktioner der bygger på den oprindelige datamodel. Det mest brugbare sammenligningsgrundlag er derfor produktets datarelationer sammen med et budget for læsninger, skrivninger, lyttere, lager og udgående trafik.

Læs også: