Wat kost Supabase als je groeit, en wanneer is een server goedkoper?

Zolang je project op één Micro-instance past en binnen de inbegrepen quota blijft, zorgt het computetegoed ervoor dat je alleen de abonnementsprijs betaalt. Een stagingproject, een grotere instance en verkeer boven de inbegrepen quota voegen elk een eigen regel toe. In ons grootste voorbeeld was de vergoeding voor maandelijks actieve gebruikers de grootste afzonderlijke post. Die blijft stijgen zodra je boven de 100.000 gebruikers uitkomt die bij Pro zijn inbegrepen.

Waar je voor betaalt bij Supabase Pro

Boven de inbegrepen quota hebben gebruikers, uitgaand verkeer, schijfruimte, bestanden en functieaanroepen elk een eigen tarief, volgens de prijspagina van Supabase.

De factureringsdocumentatie van Supabase noemt vier regels waardoor de rekening stijgt zodra je app groeit:

• Het computetegoed betaalt alleen compute. Je krijgt $10 per maand, volgens de compute-documentatie van Supabase. Dat is genoeg voor één Micro-instance. Niets ervan gaat naar uitgaand verkeer, gebruikers of schijfruimte.
• Elk project krijgt een eigen compute-instance. Een stagingkopie van productie voegt dus een tweede compute-regel toe die het ene tegoed niet dekt.
• Je betaalt voor de schijfgrootte die Supabase je geeft. Volgens de documentatie over databasegrootte groeit de schijf met 50% telkens als je database 90% ervan vult. Een database van 20 GB komt zo op een schijf van 27 GB te staan. Je betaalt voor die 27 GB, min de 8 GB die bij Pro zijn inbegrepen.
• Pro omvat 8 GB schijfruimte per project, en elke GB daarboven kost $0,125 per maand.

Wil je je eigen maand berekenen? Open de gebruikspagina en tel deze posten in deze volgorde op:

1. Begin met $25 voor het abonnement.
2. Tel de compute van elk project op tegen de afgeronde maandprijzen van Supabase ($10 Micro, $15 Small, $60 Medium, $110 Large) en trek het tegoed van $10 er één keer van af. Compute wordt per uur gefactureerd. Een project dat maar een deel van de maand draaide, kost dus minder.
3. Tel $0,00325 op voor elke maandelijks actieve gebruiker boven de 100.000. Dat is $32,50 per 10.000.
4. Tel $0,09 op voor elke GB uitgaand verkeer boven de 250 GB, plus $0,03 voor elke GB gecachet uitgaand verkeer boven de eigen 250 GB daarvan.
5. Tel $0,125 op voor elke GB schijfruimte boven de 8 GB per project. Gebruik daarvoor de schijfgrootte die bij het project staat.
6. Tel $0,0213 op voor elke GB aan bestanden boven de 100 GB, en $2 voor elk miljoen Edge Function-aanroepen boven de 2 miljoen.
7. Tel $2,50 op voor elk miljoen Realtime-berichten boven de 5 miljoen, en $10 voor elke 1.000 piekverbindingen boven de 500.
8. Tel alle add-ons op die je hebt ingeschakeld, zoals $100 per maand voor 7 dagen point-in-time-herstel.

Waarom projecten het Free-abonnement verlaten

Free omvat maximaal 2 actieve projecten, elk met 50.000 maandelijks actieve gebruikers, een database van 500 MB, 5 GB uitgaand verkeer en 1 GB bestandsopslag, volgens de prijspagina van Supabase. Is je project na een rustige week in slaap gevallen? Dan ben je tegen een van de limieten van Free aangelopen. Een Free-project wordt gepauzeerd na een week zonder activiteit, en de database wordt alleen-lezen zodra die groter is dan 500 MB. Er zijn ook geen automatische back-ups. Supabase raadt Free-gebruikers daarom aan hun data zelf te exporteren met de CLI en kopieën ergens anders te bewaren.

Betaalde projecten worden niet gepauzeerd bij inactiviteit, en Pro bewaart dagelijkse back-ups zeven dagen lang.

Zo werkt de uitgavenlimiet bij een groeiende app

Stel dat je uitgaande verkeer op de 20e van de maand de 250 GB passeert. De uitgavenlimiet staat bij Pro standaard aan. Vanaf de 20e tot de volgende factureringsperiode wordt uitgaand verkeer boven 250 GB dus geblokkeerd. Hetzelfde geldt voor elk gedekt onderdeel boven zijn quotum, volgens de documentatie van Supabase over hoe de uitgavenlimiet werkt.

Met de limiet aan groeit een Pro-schijf ook niet verder dan 8 GB. Je kunt met de uitgavenlimiet geen budget of melding voor één post instellen, en je kunt de limiet niet voor sommige posten aanzetten en voor andere uit.

Drie app-groottes, regel voor regel doorgerekend

Elk voorbeeld gaat uit van Supabase Pro met maandelijkse facturering, in Amerikaanse dollars exclusief btw, met de afgeronde maandprijzen voor compute van Supabase. Het gebruik is onze aanname, dus vul gerust je eigen cijfers in:

• Niet-gecachet uitgaand verkeer groeit met ongeveer 10 MB per gebruiker per maand. Dat is ons afgeronde cijfer voor een lichte app; op je gebruikspagina zie je je eigen cijfer. De drukkere app levert daarnaast 500 GB uit de cache van Supabase.
• De schijfgroottes zijn onze schatting op basis van de groeiregel van Supabase: eerst 8 GB, daarna telkens de helft erbij zodra de database 90% van de schijf vult. Supabase rondt mogelijk af.
• De twee grotere apps draaien een stagingproject op Micro-compute. Het zijproject niet.
• Point-in-time-herstel (PITR) is een extra optie van $100 per maand voor zeven dagen geschiedenis, en vereist minimaal Small-compute.

Een zijproject dat net van Free af is

Stel dat je 5.000 gebruikers hebt, een database van 2 GB, 50 GB uitgaand verkeer en 5 GB aan geüploade bestanden. Dan blijft elke meter ruim binnen het Pro-quotum, en het computetegoed heft de Micro-instance op.

Je hoeft de uitgavenlimiet niet uit te zetten. Point-in-time-herstel maakt de rekening hoger: het heeft een eigen prijs en je moet van de Micro-instance af die het tegoed betaalt.

Een groeiende SaaS met 40.000 gebruikers

Dit voorbeeld voegt een stagingproject toe, zodat niemand een schemawijziging eerst op productie uitprobeert. De app heeft 40.000 maandelijkse gebruikers, een database van 20 GB, 400 GB uitgaand verkeer, 60 GB aan bestanden en een miljoen Edge Function-aanroepen.

Van wat er ten opzichte van het zijproject bijkomt, komt ongeveer de helft van staging en een grotere productie-instance, en de rest van overschrijding van schijfruimte en uitgaand verkeer. Door die overschrijding is dit ook de eerste rekening waarbij de uitgavenlimiet uit moet.

Een drukkere app met 200.000 gebruikers

Bij 200.000 gebruikers zit je op bijna elke post die meegroeit met het aantal mensen boven het Pro-quotum. Dit voorbeeld gaat uit van 2 TB gewoon uitgaand verkeer plus 500 GB uit de cache van Supabase. Daarvoor geldt een eigen quotum en een lager tarief. We gaan ervan uit dat productie op Large-compute draait, met 2 dedicated vCPU's en 8 GB RAM.

Een kleinere instance zou deze rekening nauwelijks verlagen, want compute is na aftrek van het tegoed minder dan een vijfde van het totaal. De gebruikerskosten blijven stijgen met elke nieuwe actieve gebruiker boven de 100.000.

Supabase naast één server

De tabel zet de drie Supabase-rekeningen naast één zelfbeheerde server met Supabase voorgeïnstalleerd. De server heeft geen kosten per gebruiker en de bandbreedte is bij elk pakket ongelimiteerd (fair use is van toepassing), dus je hoeft geen post voor dataverkeer in de gaten te houden. De prijs verandert wanneer de introductieprijs na 3 maanden afloopt, of als je het pakket ontgroeit en overstapt naar een groter pakket.

De serverkolom toont de introductieprijs en de prijs na verlenging. We gebruiken de verlengingsprijs voor elk omslagpunt in deze gids. Zelfs voordat je je eigen tijd meetelt, betaalt de groeiende SaaS Supabase al meer dan dat. In de tabel staat Stack 16, omdat dat ons kleinste abonnement is dat aan alle aanbevolen vereisten voor zelf hosten van Supabase voldoet. Stack 8 heeft genoeg RAM en schijfruimte, maar de 2 vCPU's halen alleen het minimum van Supabase. De 4 vCPU's van Stack 16 sluiten aan bij de 4 cores die Supabase aanbeveelt:

Volgens Supabase is het minimum geschikt voor ontwikkeling en kleine tot middelgrote productie-apps, en daar past Stack 8 bij.

Wat de stack gebruikt voordat je gebruikers er zijn

De prijsvergelijking klopt alleen als de stack op het abonnement past. Daarom hebben we de eigen zelfgehoste Docker-opstelling van Supabase, release v0.8.3, op twee testmachines gedraaid en het geheugengebruik gemeten zodra alles stabiel was. Beide hadden 2 vCPU's. De ene had 8 GB geheugen en de andere 4 GB, het formaat van het minimum van Supabase en van Stack 4.

De images voor die 11 containers namen ongeveer 9,7 GB schijfruimte in. Het geheugen van de stack zelf is maar een klein deel van de 16 GB van Stack 16, dus bijna alles blijft over voor de cache van je database en voor je gebruikers. De test met 4 GB laat zien dat de stack ook start en stabiel draait op een testmachine zo groot als ons kleinste abonnement. Bij geen van beide tests was er verkeer, dus ze zeggen niets over hoeveel gebruikers een abonnement aankan. De keuze voor het abonnement blijft gebaseerd op de 4 cores die Supabase aanbeveelt. Met de belastingstest in de stappen verderop controleer je dat voor je eigen app.

Op Cloud heeft de Large-compute-instance van de drukkere app 8 GB RAM. Op je eigen server deelt Postgres de 16 GB met Auth, Storage, Realtime en de rest van de stack.

Wat de serverprijs niet meeneemt

Voor de prijs van het pakket krijg je een server waarop de Supabase-stack draait, en de pagina over zelf hosten van Supabase somt op wat er niet bij zit. Branching, beheerde back-ups, PITR, geavanceerde statistieken, analytics- en vectorbuckets, ETL en de beheer-API zijn allemaal alleen in Cloud beschikbaar.

De kostentabel laat ook e-mail en opslag voor back-ups buiten beschouwing. Volgens de handleiding voor zelf hosten met Docker van Supabase heb je een productieklare SMTP-server nodig om e-mails voor registratie en wachtwoorden te versturen, dus reken op een transactionele e-maildienst. Je back-ups horen ergens anders dan op de server zelf, bijvoorbeeld in S3-compatibele opslag. Aan de serverkant betaal je voor allebei bovenop het pakket. We hebben ze niet geprijsd, omdat ze afhangen van hoeveel e-mail je verstuurt, hoeveel je opslaat en hoelang je back-ups bewaart.

De database van 60 GB en de 120 GB aan bestanden van de drukkere app passen op 250 GB schijfruimte, al houd je minder ruimte over dan het lijkt: het besturingssysteem, Docker-images (in onze test ongeveer 9,7 GB voor die van Supabase), logs en een lopende restore nemen ook ruimte in. Bewaar back-ups ergens anders en stel bij het inrichten van de server een melding in voor vrije schijfruimte.

Staging ontbreekt ook aan de serverkant, omdat zelfgehoste Supabase één project per stack draait. Een stagingkopie betekent dus een tweede stack, op dezelfde server of op een tweede. Twee stacks op één server hebben we niet getest. Laat je staging voor de vergelijking ook aan de Cloud-kant weg, dan daalt de rekening van de SaaS met $10 naar $45,88 en die van de drukkere app naar $627,82. Ook zonder staging blijft de SaaS onder het omslagpunt dat je in de volgende sectie ziet, en zit de drukkere app er ruim boven.

Waar de server wint als je je tijd meetelt

Routineonderhoud aan je eigen server betekent updates van het besturingssysteem, nieuwe Docker-images, een blik op de logs en controleren of de back-up van afgelopen nacht is gelukt. Alles bij elkaar kost dat één à twee uur per maand, volgens de schatting in onze gids over hoe je Supabase zelf host, en wat je daarvoor inlevert. Het mediane uurloon in de VS voor softwareontwikkelaars, QA-analisten en testers was in 2025 $64,44, volgens het Bureau of Labor Statistics. Die uren kosten je dus $64,44 tot $128,88 per maand.

Tel die uren op bij de verlengingsprijs van de server uit de tabel hierboven. Dit is het Supabase-bedrag waarbij de server plus onderhoud goedkoper wordt. De voorbeeldmaanden zijn onze eigen inschatting van wanneer je zoveel onderhoud hebt:

De rekening van de drukkere app gaat zelfs over de grens van acht uur heen. Elk uur verschuift de grens met wat jouw uur waard is: is jouw uur $100 waard, dan schuift de grens voor één uur op naar ongeveer $135. Tel aan de serverkant ook opslag voor back-ups, een e-maildienst en een eenmalige migratie mee.

Met PITR valt de rekening van $155,88 van de groeiende SaaS binnen de bandbreedte voor één à twee uur, van ongeveer $100 tot $164, maar een zelfgehoste server heeft geen beheerde point-in-time recovery. Dat herstel bouw en beheer je dan zelf. Ook lever je de dagelijkse back-ups in die Cloud Pro zeven dagen voor je bewaart. Betaal je voor PITR vanwege het herstel, blijf dan, of trek tijd uit om je eigen back-ups te bouwen en te testen voordat je overstapt. De drukkere app betaalt Supabase elke maand een paar honderd dollar meer dan de server en twee uur van jouw tijd samen, maar die besparing geldt alleen als één server je belasting aankan. Doe dus eerst een belastingtest voordat je erop rekent.

Gebruikt je app alleen de database, dan rekent de gids over wat alleen beheerde Postgres kost naast één server dat scenario door. Twijfel je nog of je de volledige Supabase-stack überhaupt nodig hebt, dan vergelijkt onze gids over Supabase of gewone PostgreSQL de twee op één server.

Voordat je productie verhuist

In de GitHub-discussie van Supabase over zelf hosten verwoordde een ontwikkelaar de zorg zo:

Doe dit in deze volgorde, op een kopie van je data, terwijl het Cloud-project nog gewoon je gebruikers bedient:

1. Zet een recente back-up terug op de server

   Maak een back-up van de database met de Supabase CLI en zet die terug op de server, met de dumpstappen uit de gids voor back-up en restore van Supabase. Meet hoelang de restore duurt, want dat is het databasedeel van je hersteltijd als de server uitvalt. Oefen ook één keer een volledige herbouw.

2. Verhuis de onderdelen buiten de database

   Auth-gebruikers, Storage-bestanden en Edge Functions hebben elk hun eigen migratiepad, dus controleer ze allemaal. Registreer daarna een testgebruiker en controleer of de e-mail via je SMTP-server aankomt.

3. Belast de server zoals in productie

   Draai je zwaarste query's en open net zoveel Realtime-verbindingen als je gebruikspagina op het piekmoment laat zien. Houd ondertussen het geheugen in de gaten.

4. Stel back-ups in die buiten de server worden bewaard

   Stuur elke nacht back-ups van de server af, bijvoorbeeld naar S3-compatibele opslag. Zet er daarna één terug.

5. Plan de overstap en de weg terug

   Kies een rustig uur. Houd het Cloud-project aan tot de server een volledige factuurperiode heeft gedraaid, en schrijf op hoe je terug zou schakelen.

Blijven of overstappen

Tel je eigen uren voordat je de knoop doorhakt. Meet hoelang de restore en de belastingtest hierboven duren om te zien wat de migratie je kost, en houd in de eerste maand je onderhoud bij, zodat je onze schatting van één à twee uur in het omslagpunt kunt vervangen.

Hoe we dit hebben doorgerekend en getest

De Cloud-bedragen zijn berekeningen van DreamHost op basis van de prijslijst en de factureringsdocumentatie van Supabase, gelezen op 28 september 2026. Op 21 oktober hebben we de prijslijst opnieuw bekeken en alle tarieven in de tabellen waren ongewijzigd. Het gebruik in elk voorbeeld is onze aanname; we hebben geen Supabase Cloud-account aangemaakt om het te testen.

De servercijfers heeft DreamHost gemeten op een test-VM (arm64), niet op een server van DreamHost. De tests zijn gedaan voor onze gids over Supabase of gewone PostgreSQL, en deze pagina gebruikt ze opnieuw. Ze draaiden op een Mac onder Colima met Ubuntu 24.04 en 2 vCPU's: met 8 GB geheugen op 19 oktober 2026 en met 4 GB op 20 oktober. De Docker-map van Supabase v0.8.3 draaide zoals gepubliceerd. Elk geheugencijfer is de mediaan van 12 metingen met docker stats, met 5 seconden ertussen, 10 minuten na de start. Onze pakketten draaien op x86-processors van AMD EPYC, dus de grootte van images op je server zal afwijken.

Wat we niet hebben getest: verkeer of belasting, een week lang draaien, 4 vCPU's, de add-on Logs & Analytics, een restore en twee Supabase-stacks op één server. Elke opstelling hebben we één keer gedraaid.

Veelgestelde vragen over de prijzen van Supabase