Supabase of Firebase: datamodel bepaalt de kostenmeter

Kies Supabase met PostgreSQL als je app veel relaties tussen gegevens moet verwerken en je de kosten vooral via capaciteit en planquota wilt begroten. De tariefstructuur van Supabase combineert een planprijs met quota voor onder meer actieve gebruikers, dataverkeer en Realtime. Hoeveel databasecapaciteit je nodig hebt, hangt vervolgens af van de belasting van je app.

Kies Firebase met Cloud Firestore als je gegevens goed in documenten passen en je de kosten per documentlezing en schrijfbewerking wilt volgen. De Firebase-prijstabel onderscheidt het gratis Spark-plan van Blaze, waarop het verbruik per product wordt afgerekend. Daardoor zegt het aantal gebruikers op zichzelf weinig over de Firestore-rekening: vooral het aantal opgehaalde documenten en afgeleverde wijzigingen telt.

Welke database zit in de vergelijking?

Bij Supabase staan klanten, bestellingen en orderregels bijvoorbeeld in gekoppelde PostgreSQL-tabellen. Een relationele query kan gegevens uit die tabellen samenbrengen. Firestore Standard edition bewaart documenten in collecties. Als een scherm gegevens uit verschillende documenten nodig heeft, levert dat meerdere documentlezingen op. De keuze om gegevens samen of apart op te slaan verandert dus zowel de queries als de kostenmeter.

Firebase heeft daarnaast Realtime Database, waarvan opslag en gedownloade gegevens de voornaamste tariefmeters zijn. Firestore-lezingen zijn daarvoor geen bruikbare rekeneenheid. Ook SQL Connect hoort apart te worden begroot: die relationele Firebase-route gebruikt Cloud SQL voor PostgreSQL en brengt kosten voor de database-instantie en uitgevoerde clientbewerkingen met zich mee. De berekeningen hieronder gaan uitsluitend over Firestore Standard edition tegenover Supabase.

Vier appprofielen, dezelfde belasting per platform

Een Cloud Firestore-document wordt herhaaldelijk gelezen, waardoor de leesmeter oploopt.

Deze voorwaardelijke voorbeelden gebruiken telkens een maand van dertig dagen, met gelijkmatig gebruik over die dagen. Voor Firestore betekent dat een inbegrepen ruimte van 50.000 documentlezingen en 20.000 schrijfbewerkingen per dag voor de gratis database van een project. De tarieven voor Firestore Standard edition noemen voor us-central1 vervolgens $0,30 per miljoen lezingen en $0,90 per miljoen schrijfbewerkingen. Een piek op één dag kan een andere uitkomst geven dan dezelfde maandtotalen bij gelijkmatige spreiding.

Voor Supabase reken ik met één Pro-project op een Micro-instantie: $25 per maand, waarbij de compute credits die instantie dekken. Pro omvat 100.000 maandelijkse actieve gebruikers, 5 miljoen Realtime-berichten en 500 piekverbindingen; daarboven kosten extra actieve gebruikers $0,00325 per stuk en berichten $2,50 per miljoen. De profielen veronderstellen dat databaseomvang, dataverkeer en de capaciteit van Micro volstaan. Hosting, bestandsopslag, functies, extra Firestore-indexlezingen en andere diensten zijn niet meegerekend.

Kleine app. Stel: 10.000 maandelijks actieve gebruikers, 300.000 lezingen en 30.000 schrijfbewerkingen, zonder realtimeverkeer. Gelijkmatig verdeeld blijven de Firestore-bewerkingen binnen de dagelijkse gratis quota en kosten ze $0. Supabase Pro kost in deze aanname $25. Supabase Free kan eveneens $0 kosten zolang alle quota passen, maar een inactief gratis project wordt na een week gepauzeerd.
Leesintensieve catalogus. Bij 20.000 actieve gebruikers, 20 miljoen lezingen en 300.000 schrijfbewerkingen blijven de schrijfbewerkingen onder het gratis dagquotum. Van de lezingen vallen 1,5 miljoen binnen de gratis ruimte; de overige 18,5 miljoen kosten in us-central1 ongeveer $5,55. Supabase Pro blijft onder de genoemde aannames op $25. Het prijsverschil zegt nog niet welke implementatie efficiënter is: een PostgreSQL-query en een Firestore-scherm hoeven niet dezelfde hoeveelheid gegevens op te halen.
Schrijfintensieve activiteit. Bij 20.000 actieve gebruikers, 2 miljoen lezingen en 5 miljoen schrijfbewerkingen komen de Firestore-bewerkingen uit op ongeveer $0,15 voor lezingen en $3,96 voor schrijfbewerkingen, samen $4,11 in us-central1. Voor Supabase blijft de aangenomen basisprijs $25, zolang de beschikbare capaciteit volstaat. Veel schrijfbewerkingen kunnen daar wel aanleiding zijn om meer rekenkracht of opslag te begroten.
Drukke realtime-app. Stel: 120.000 actieve gebruikers, 2 miljoen gewone lezingen, 300.000 schrijfbewerkingen, 10 miljoen bij luisteraars afgeleverde updates en maximaal 400 gelijktijdige verbindingen. Als iedere afgeleverde Firestore-update één documentlezing oplevert, zijn er 12 miljoen lezingen in totaal. Na het gratis quotum kost dat ongeveer $3,15 in us-central1. Bij Supabase tellen 20.000 gebruikers boven het Pro-quotum voor $65 en 5 miljoen berichten boven het Realtime-quotum voor $12,50 mee: samen $102,50 inclusief het basisplan, mits meerverbruik is toegestaan.

De dollarbedragen voor Firestore zijn voorbeelden voor een Amerikaanse locatie, geen voorspelling van een factuur voor een Europese databaselocatie. De bedragen vergelijken bovendien alleen de opgegeven meters. Met name in het realtime-profiel kan het eerste resultaat van een listener extra Firestore-lezingen opleveren.

Realtime hangt af van het aantal ontvangers

Eén PostgreSQL-wijziging bereikt meerdere Supabase Realtime-abonnees en levert meer berichten op.

Eén gewijzigde record is niet noodzakelijk één gefactureerde gebeurtenis. Bij Supabase Postgres Changes telt een wijziging per client die het bericht ontvangt; ook piekverbindingen hebben een eigen quotum. Bij Firestore wordt een documentlezing gerekend wanneer een document aan het resultaat van een listener wordt toegevoegd of daarin wordt bijgewerkt. De uitleg over Firestore-listeners beschrijft daarnaast nieuwe lezingen na herverbindingen, afhankelijk van de instelling voor offline opslag.

Het drukke profiel stelt afgeleverde updates aan beide kanten gelijk om de tariefmeters zichtbaar te maken. In een echte app bepalen het aantal luisteraars per wijziging, de omvang van hun eerste queryresultaat en het patroon van herverbinden hoeveel werk elk platform verricht. Een scherm dat bij het openen een grote collectie volgt, kan daardoor meer Firestore-lezingen veroorzaken dan alleen het aantal latere wijzigingen doet vermoeden.

Authenticatie is een afzonderlijke keuze

De Supabase-berekening voor het drukke profiel stijgt vooral door maandelijkse actieve gebruikers boven de inbegrepen grens. Een geregistreerd account dat die maand niet actief is, telt niet als zo’n actieve gebruiker. Voor een app met veel accounts maar weinig terugkerend gebruik maakt dat onderscheid verschil.

Bij Firebase heeft gewone Authentication in de prijstabel geen afzonderlijke gebruiksprijs. Telefoonauthenticatie wordt per verzonden sms afgerekend; met Identity Platform gelden bovendien aparte grenzen voor actieve gebruikers en voor SAML/OIDC. Wie die functies nodig heeft, kan de Firestore-bedragen uit de profielen dus niet als totale authenticatiekosten lezen. Aan beide kanten staan aanmeldmethode en databaseverbruik los van elkaar.

Migratie en kostenplafonds

Een migratie van Firestore naar PostgreSQL vraagt om keuzes over tabellen, relaties en queries: gegevens die samen in een document stonden, kunnen over gekoppelde tabellen worden verdeeld. In de omgekeerde richting moet je bepalen welke gegevens je in een document samenbrengt en welke schermen meerdere documenten zullen lezen. Toegangsregels, listeners en de koppeling met gebruikersaccounts moeten daarbij opnieuw worden ingericht. Alleen de opgeslagen data overzetten geeft nog geen gelijkwaardige app.

Supabase Pro heeft standaard een bestedingslimiet voor gebruik boven de inbegrepen quota. Voor de extra gebruikers en berichten in het drukke profiel moet die limiet uitgeschakeld zijn; met de limiet aan kan overschrijding de beschikbare dienst beperken. Bij Firebase Blaze stoppen gewone budgetmeldingen het gebruik niet. De Firebase-regels voor uitgavenlimieten bieden zulke limieten momenteel voor een beperkte groep diensten, waar Firestore niet bij staat. Dat verschil maakt het verwachte lees- en realtimegedrag ook een keuze over kostenrisico.