Supabase eller Firebase: datamodellen avgjør før gratisnivået

Supabase er et naturlig utgangspunkt når en ny tjeneste må koble kunder, brukere og transaksjoner med SQL. Firebase med Cloud Firestore passer bedre når mobilappen må lagre endringer uten nett og synkronisere dem senere. Datamodellen og kravet til frakoblet bruk bør derfor avklares før gratisnivåene sammenlignes.

For en relasjonell B2B-tjeneste peker valget ofte mot Supabase; for en mobilapp som skal virke ved ustabil dekning, mot Firestore. En RAG-tjeneste kan ha nytte av Supabase når søk i dokumenter må kobles til kundedata og tilgang. Først når disse behovene er kjent, gir det mening å regne på den samme belastningen i begge løsninger.

Relasjonell B2B-tjeneste: når forbindelsene er viktige

Supabase bygger på PostgreSQL. Tenk på en tjeneste der hver kunde har prosjekter, prosjektmedlemmer har ulike roller, og fakturaer skal knyttes til riktig avtale. Tabeller, fremmednøkler og SQL-spørringer gir disse forbindelsene en plass i selve databasen. Det blir særlig nyttig når rapporter og tilgangsregler må følge de samme forholdene mellom kundene og postene deres.

Firestores datamodell lagrer i stedet dokumenter i samlinger, med mulighet for felter og underordnede samlinger. Den passer godt når appen vanligvis henter avgrensede dokumenter, for eksempel en brukers egne registreringer. Hvis produktet stadig skal kombinere kunder, avtaler, hendelser og roller i nye oversikter, må slike lesemønstre planlegges i dokumentstrukturen og i spørringene.

Forskjellen handler om hvilke spørsmål produktet skal svare på. En B2B-tjeneste kan begynne med en enkel kundeside og senere trenge samlet forbruk per avtale eller tilgang på tvers av prosjekter. Da er relasjonene allerede en del av modellen i PostgreSQL. Har appen derimot selvstendige poster som sjelden må kobles sammen, er Firestores dokumenter et rimeligere arkitektonisk utgangspunkt å vurdere.

Mobilapp: frakoblet bruk endrer valget

Cloud Firestore har en konkret fordel når brukeren må kunne lese og endre data på toget eller ute i felt. Firestores støtte for frakoblet bruk omfatter lokal lagring av data appen bruker, lesing og skriving fra denne kopien og synkronisering når forbindelsen kommer tilbake. Støtten gjelder Android, Apple-plattformer og web; på web må vedvarende lokal lagring aktiveres.

Synkronisering løser likevel ikke alle konflikter i produktet. Når flere endringer gjelder samme dokument, bruker Firestore prinsippet om at den siste skrivingen vinner. Hvis to ansatte kan redigere samme ordre mens de er uten dekning, må appen derfor bestemme om en overskrevet endring er akseptabel, eller om arbeidsflyten trenger en egen konfliktregel.

For et team som velger Supabase til en slik mobilapp, blir lokal lagring og synkronisering et eget utviklingsansvar. Det kan være fornuftig dersom den relasjonelle modellen er viktigere for tjenesten, men arbeidet må tas med i sammenligningen. Firebase kan også være et naturlig valg når appen allerede bruker andre Firebase-tjenester; fordelen av en samlet mobilplattform må veies mot hvordan dataene senere skal rapporteres og flyttes.

RAG-tjeneste: søket må følge kundedataene

En RAG-tjeneste henter relevante tekstutdrag før en språkmodell lager et svar. Hvis hvert utdrag tilhører en bestemt kunde eller et prosjekt, må søket også respektere disse grensene. Supabase Vector bruker pgvector til å lagre, indeksere og søke i vektorrepresentasjoner i PostgreSQL, der tjenesten også kan ha øvrige forretningsdata.

Det gjør Supabase til et naturlig utgangspunkt når søket må kobles til relasjoner som kunder, prosjekter og tilganger. En felles kunnskapsbase uten slike koblinger kan gi et annet valg. Datamengde, filtrering og indekser påvirker dessuten hvor godt søket fungerer; muligheten til å lagre vektorer i samme database er ikke i seg selv en ytelsesgaranti.

Supabase kan også driftes på egen infrastruktur. For en tjeneste som vil bevare muligheten til å flytte PostgreSQL-data senere, er det relevant. En flytting omfatter likevel mer enn databasen: autentisering, fillagring, funksjoner og driftsoppsett må vurderes hver for seg.

Pris: beregn én app med to ulike kostnadsmodeller

Supabases prisliste oppgir 500 MB databaseplass på gratisnivået, og gratisprosjekter pauses etter en uke uten aktivitet. Pro starter på 25 dollar i måneden med det første prosjektet inkludert. Abonnementet gir en databaseinstans og inkluderte grenser for blant annet lagring og utgående trafikk; større datakapasitet, mer trafikk eller kraftigere databehandling kan øke kostnaden.

Firebases prisliste skiller mellom gratisplanen Spark og den forbruksbaserte Blaze-planen. For Cloud Firestore Standard er gratisgrensene blant annet 50 000 dokumentlesinger og 20 000 skrivinger per dag, 1 GiB lagring og 10 GiB utgående trafikk per måned. Firebase tilbyr også SQL Connect med Cloud SQL for PostgreSQL, som har en annen prismodell enn Firestore. «Firebase» betyr derfor ikke automatisk dokumentdatabase eller pris per dokumentlesing.

Anta et hypotetisk produkt med 1 200 daglige brukere. Hvis hver bruker åpner tre visninger som leser 20 dokumenter hver gang, gir det 72 000 Firestore-lesinger per dag, før oppdateringer og annen aktivitet. Det er 22 000 over den oppgitte dagskvoten for lesinger. Regnestykket viser hvilke operasjoner som må telles; det er ikke en prognose for hele Firebase-regningen.

Den samme appen på Supabase kan ikke prises ved å oversette dokumentlesingene direkte til SQL-spørringer. En spørring kan hente flere tilknyttede poster, mens kostnaden også avhenger av instansens kapasitet, lagring og data som sendes ut. En sammenlignbar kalkyle bruker derfor de samme skjermbildene, oppdateringene og datamengdene på begge sider. Da blir det synlig om Firestores operasjoner eller Supabases instans og forbruksgrenser er den viktigste kostnadsdriveren.

Tre produktprofiler gir ulike førstevalg

• Relasjonell B2B-tjeneste: Begynn med Supabase når kunder, roller, transaksjoner og rapporter må kobles på tvers. Dersom teamet vil bruke Firebase, bør det sammenligne med SQL Connect så vel som med Firestore.
• Mobilapp med frakoblet bruk: Begynn med Firestore når lokal lesing, skriving og synkronisering er et kjernekrav. Avklar samtidig hva appen skal gjøre når flere endrer samme dokument.
• RAG-tjeneste: Begynn med Supabase når vektorsøk må følge relasjoner og tilgang til separate kundedata. Vurder søkene mot en realistisk datamengde før instansstørrelse og kostnad bestemmes.

Muligheten for senere migrering følger også datamodellen. PostgreSQL-tabeller og SQL gir et kjent grunnlag ved flytting til en annen PostgreSQL-installasjon, selv om tilknyttede tjenester må tilpasses. En flytting fra Firestores dokumenter til tabeller krever i tillegg at felter og forbindelser modelleres på nytt. Den forskjellen er lettest å ta høyde for mens tjenestens datamodell fortsatt er under utforming.

Les også:

• Cal.com eller Calendly: gratisplanen vinner, men oppsettet koster tid
• Power BI eller Looker Studio: gratis deling kan ende i en BigQuery-regning
• ChatGPT Business eller Microsoft 365 Copilot: integrasjonen avgjør