Supabase of alleen PostgreSQL op je eigen server

De zelfgehoste Docker-setup van Supabase, release v0.8.3 van 16 oktober 2026, start 11 containers. Eén daarvan is PostgreSQL 17. De andere tien zijn een gateway, inloggen, een REST API, bestandsopslag, het schalen van afbeeldingen, live-updates, serverfuncties, een verbindingspooler, een beheer-API voor de database en het Studio-dashboard. Op een x86-server zijn de 11 images samen ongeveer 2,15 GB om te downloaden. Dat is onze optelsom van de x86-groottes op Docker Hub voor de image-tags in het compose-bestand. Het officiële PostgreSQL 17-image is ongeveer 161 MB.

De API-documentatie van Supabase beschrijft twee manieren om het te gebruiken: je kunt de API's aanroepen – directly from the browser (two-tier architecture), or as a complement to your own API server (three-tier architecture). Praat een browser- of telefoonapp met je database, dan zijn die tien services de backend die je anders zelf zou schrijven. Zit er een eigen server tussen, dan is PostgreSQL het deel dat je app gebruikt.

Wat Supabase toevoegt aan PostgreSQL

Voor elke taak hieronder noemt de middelste kolom de Supabase-service die het werk doet. Die gegevens komen van de architectuurpagina van Supabase en de README voor zelf hosten bij v0.8.3.

Onze keuze voor een veelvoorkomend geval: een Next.js-, React- of mobiele app die nog geen servercode heeft, haalt het meeste uit Supabase. Zonder Supabase is dat allemaal code die je vóór de lancering zou schrijven. Een team dat al een backend in Rails, Django of Express heeft, heeft weinig aan de tien extra services.

DreamHost verkoopt beide als servers met de software al geïnstalleerd, Supabase VPS Hosting en PostgreSQL VPS Hosting, op dezelfde Stack-abonnementen voor dezelfde prijzen. Zit je nu op Supabase Cloud en vraag je je af of een server goedkoper zou zijn? Begin dan met wat Supabase Cloud kost als je groeit. Twijfel je tussen een beheerde PostgreSQL-service en gewone PostgreSQL op een server, lees dan wat beheerde Postgres kost naast één server.

Wat op dag één werkte

We probeerden elke taak op Supabase direct na de installatie, zonder eigen code behalve testscripts, en alle zeven werkten.

• Een gebruiker laten inloggen en een token krijgen. We maakten de gebruiker aan via de admin-API, omdat de standaardsetup geen mailserver heeft voor bevestigingsmails.
• Een tabel lezen en schrijven via HTTP onder een beleidsregel voor beveiliging op rijniveau. De ingelogde gebruiker zag zijn ene rij, en een verzoek zonder ingelogde gebruiker kreeg 0 rijen.
• Een bestand uploaden en dezelfde bytes downloaden. We gebruikten een privébucket, en de download kwam byte voor byte overeen.
• Een afbeelding schalen. De imgproxy-service maakte van een PNG van 800x600 een versie van 200 pixels breed.
• Een serverfunctie aanroepen. De meegeleverde hello-functie gaf antwoord.
• Een event krijgen als er een rij wordt toegevoegd. Een supabase-js-client kreeg de nieuwe rij 283 ms na de insert.
• Een webdashboard openen. Studio vroeg eerst om in te loggen.

Op gewone PostgreSQL 17 voerden we de twee taken uit die de database zelf doet. Dezelfde beleidsregel voor beveiliging op rijniveau werkte in SQL, en LISTEN en NOTIFY brachten een event over tussen twee SQL-sessies. Voor de rest heb je software naast de database nodig: een HTTP-API, inloggen, bestandsopslag, serverfuncties, een browserverbinding voor live-updates en een dashboard.

Realtime liet onze eerste run struikelen: de supabase-js-client meldde na 35 ms dat hij geabonneerd was, en de rij die we direct daarna invoegden kwam nooit aan. Bij de tweede run logden we de systeemevents van het kanaal: de client meldde subscribed na 32 ms, en het eigen bericht Subscribed to PostgreSQL van Realtime kwam ongeveer 2,4 seconden later. Schrijft je app een rij direct na het abonneren, luister dan naar het system-event van het kanaal en wacht op dat bericht voordat je iets invoegt.

Wat elk van je server vraagt

Supabase publiceert groottes voor zijn stack. PostgreSQL doet dat niet, dus vullen onze metingen het gat. In de tabel staat Supabase voor de zelfgehoste v0.8.3-setup en PostgreSQL voor gewone PostgreSQL 17.

De rijen van geheugen in rust tot en met extensies zijn onze eigen metingen, van 19 oktober (VM van 8 GB) en 20 oktober 2026 (VM van 4 GB), beschreven onder hoe we hebben gemeten. De tijden gelden met de images al gedownload. Aantallen komen uit het compose-bestand van Supabase bij tag self-hosted/v0.8.3, downloadgroottes uit de tag-gegevens van Docker Hub en vereisten uit de documentatie van elke maker, allemaal geraadpleegd op 16 oktober 2026.

Logs & Analytics staan in de standaardsetup van Supabase uit om het geheugengebruik te beperken. Je zet ze aan met een override-bestand dat Logflare en Vector toevoegt en verhoogt wat de stack nodig heeft.

Stack 4 voldoet aan het minimum van Supabase. Stack 8 voegt het aanbevolen RAM en de aanbevolen schijfruimte toe, maar houdt 2 vCPU. Stack 16 is het kleinste abonnement dat aan alle aanbevolen waarden van Supabase voldoet, met 4 vCPU, 16 GB RAM en 250 GB NVMe-opslag volgens de Supabase VPS-pagina. Daarom is dat onze keuze voor productie, en past Stack 8 bij een kleine app of een stagingkopie.

Onze run op 4 GB laat zien dat de standaardstack in rust op Stack 4 past. Alle 11 containers bleven draaien zonder herstart, en hun geheugen stabiliseerde op iets meer dan een derde van de 3.904 MiB van de VM. De images namen ongeveer 9,7 GB schijfruimte in, ruim binnen de 75 GB van Stack 4.

Dezelfde stack gebruikte op de VM van 4 GB ongeveer anderhalf keer zoveel geheugen als op die van 8 GB. Studio, Realtime en de pooler stegen met 16 tot 22%, en vijf kleine services werden twee tot zeven keer zo groot, imgproxy van ongeveer 13 MiB naar 94 MiB. We hebben elke setup één keer gedraaid en kunnen het verschil niet verklaren. Reken daarom op 1 tot 1,5 GB voor Supabase in rust, met daarbovenop ruimte voor het verkeer van je app.

Voor PostgreSQL op zichzelf zouden we een productiedatabase op Stack 8 zetten, het abonnement dat op de PostgreSQL VPS-pagina het label Voor apps die in productie draaien. heeft. Stack 4, met het label Voor lichte apps en soloprojecten, is genoeg om te beginnen. Volgens de pagina is overstappen van Stack 4 naar Stack 32 eenvoudig, en je omgeving verhuist mee. Wil je de server afstemmen op alles wat je er nog meer op draait, bekijk dan welk VPS-abonnement je nodig hebt.

Wat je met alleen PostgreSQL zelf regelt

Je backend regelt die taken, en Rails en Django leveren daar veel van mee. Rails heeft een authenticatiegenerator, Active Storage regelt uploads en afbeeldingsvarianten, en Action Cable geeft de browser WebSockets. Django heeft een ingebouwd systeem voor gebruikersauthenticatie, en Channels voegt WebSockets toe. Een Express-app voegt deze toe als bibliotheken, bijvoorbeeld Socket.IO voor een live tweerichtingsverbinding tussen de browser en je server.

PostgreSQL zelf dekt een deel van de lijst. De beleidsregels voor rijbeveiliging beperken per gebruiker welke rijen een query teruggeeft of wijzigt, en de toegangsregels van Supabase zijn precies die beleidsregels. LISTEN en NOTIFY sturen een event naar elke databasesessie die luistert, zodat een worker in je backend kan reageren op nieuwe rijen. Een browser opent geen databasesessies, dus live-updates in de browser lopen via een eigen WebSocket-server, zoals Action Cable, Channels of Socket.IO. Extensies zoals pgvector en PostGIS installeer je op onze PostgreSQL-server met volledige root.

Is de automatische API het onderdeel dat je zou missen, dan kun je PostgREST los draaien. Het is de webserver achter de REST API van Supabase, en volgens de README serves a fully RESTful API from any existing PostgreSQL database.

Zelfgehoste Supabase in de dagelijkse praktijk

De pagina over zelf hosten van Supabase somt op wat je op je neemt als je het zelf draait: serveronderhoud, het besturingssysteem en de services up-to-date houden, Postgres-onderhoud, hoge beschikbaarheid, en back-ups en herstel.

• HTTPS. De eigen Docker-setup van Supabase antwoordt via gewone HTTP, wat prima is op een testmachine. Voor productie zet de proxyhandleiding van Supabase Caddy of Nginx met Let’s Encrypt vóór de gateway.
• E-mail. De Docker-standaardinstellingen van Supabase zetten registratie via e-mail met bevestiging aan en sturen mail naar een container die alleen in het ontwikkelbestand van Supabase bestaat. Voeg je eigen SMTP-server toe voordat echte gebruikers zich registreren, anders worden bevestigingsmails en e-mails voor wachtwoordherstel niet verstuurd.
• Updates. Volgens de Docker-handleiding van Supabase verschijnt er ongeveer één keer per maand een stabiele snapshot. Het updatescript voegt de instellingen van de nieuwe release samen met de jouwe. Daarna haal je de nieuwe images op en maak je de containers opnieuw aan. Maak een back-up voordat je het uitvoert.
• Projecten. Eén installatie draait één project. Zelfgehoste Studio kan niet meerdere organisaties of projecten bevatten, dus een tweede app krijgt een eigen installatie.

In de stapsgewijze uitleg over zelf hosten vind je de installatiestappen, en de Docker-handleiding van Supabase is het naslagwerk voor elke instelling.

Hoe we hebben gemeten

DreamHost draaide beide stacks op 19 oktober 2026 op een lokale test-VM met 2 vCPU's en 7.922 MiB geheugen: Ubuntu 24.04.4 op arm64, onder Colima op een Mac met Apple silicon. Onze pakketten draaien op x86-processors van het type AMD EPYC, dus dit was geen server van DreamHost. Omdat de grootte van images per processor verschilt, vermeldt de tabel ook de download voor x86.

Supabase draaide vanuit de Docker-map van v0.8.3 zoals die is gepubliceerd, met secrets uit de eigen sleutelscripts. PostgreSQL draaide vanuit het voorbeeld-composebestand van Docker Hub, vastgezet op postgres:17.11, zonder de Adminer-service. Elk geheugencijfer is de middelste waarde van 12 metingen met docker stats, één per 5 seconden, vanaf 10 minuten na de start. De images waren al gedownload voordat we de starttijden maten.

Op 20 oktober draaiden we Supabase opnieuw op een tweede VM met de omvang van Stack 4: 2 vCPU's, 3.904 MiB geheugen en geen swap, met dezelfde versies van Ubuntu en Docker. Daarvoor gebruikten we een verse kopie van dezelfde v0.8.3-map, nieuwe secrets en dezelfde 12 metingen na 10 minuten. Op die VM draaide ook een kleine testapp van ongeveer 180 MiB die er los van stond. Die telt niet mee in de cijfers over Supabase die we noemen.

We hebben elke opstelling één keer gedraaid, dus er is geen spreiding te melden. De metingen gaan over een stack in rust en over wat direct werkt. Ze gaan niet over een app onder belasting of over een week draaien, en we hebben Logs & Analytics niet ingeschakeld getest.

Veelgestelde vragen over Supabase of alleen PostgreSQL