Zelfgehoste PostgreSQL op een VPS: ontsnap aan de prijzen van beheerde databases

Rekenkracht. Opslag. Bewaartermijn van back-ups.

De snapshot-export die je vergeten was. De kosten voor uitgaand verkeer van de stagingomgeving die vorige week dinsdag een ‘pg_dump’ draaide.

Niemand opent de factuur van zijn beheerde database in de verwachting dat die goedkoop is.

Maar tjonge.

Het verschil tussen Postgres voor $25 per maand en wat er op je creditcard verschijnt, is groot geworden. Een VPS met 4 GB voor de prijs van één Supabase-add-on draait nu je hele database, met nog genoeg ruimte voor het besturingssysteem om veelgebruikte pagina's te cachen.

Een productiedatabase in Postgres zelf hosten is niet meer de operationele nachtmerrie die het ooit was. De repository van de PostgreSQL Global Development Group (PGDG) is degelijk. Moderne PostgreSQL-installaties (v14+) gebruiken standaard SCRAM-SHA-256 voor wachtwoordversleuteling, en het verouderde MD5 is sinds v18 officieel afgeschaft. De redenen waarom mensen vandaag bij RDS, Supabase of Neon blijven, zijn operationeel, niet technisch.

We hebben het over echte facturen, echte operationele lasten en hoe moderne Postgres-hosting er werkelijk uitziet.

Wat kost het echt om PostgreSQL zelf te hosten op een VPS?

Zelfgehoste PostgreSQL op een VPS met 4 GB kost vaak maar een fractie van een vergelijkbaar abonnement bij RDS, Supabase Pro of Neon Scale, zodra je opslag, back-ups en uitgaand verkeer bij de beheerde factuur optelt.

PostgreSQL is de database die 55,6% van de ontwikkelaars gebruikt, volgens de Developer Survey 2025 van Stack Overflow, en al twee jaar op rij de populairste. Het is ook een database die je prima zelf kunt draaien.

Vergelijking voor een representatieve werklast van een klein team (4 GB RAM, ~100 GB data, lage tot gemiddelde schrijfbelasting, één regio), prijzen per mei 2026:

De on-demandprijs van RDS db.t4g.medium is ongeveer $0,065 per uur, oftewel zo'n $47,45 per maand alleen voor rekenkracht.

Tel daar 100 GB gp3-opslag voor ongeveer $0,115/GB per maand en automatische back-ups bij op, en een Single-AZ-machine komt uit rond $60/maand. Zet je Multi-AZ-failover aan, dan verdubbelen de rekenkosten ongeveer en komt een productiewaardige configuratie op $100/maand of meer uit.

Dat is geen klein verschil.

Zelf hosten is goedkoper omdat jij het werk doet waar de beheerde factuur voor betaalde: discipline in het beheer, bereikbaarheidsdiensten en ingrijpen om 2 uur 's nachts als de schijf volloopt. Het beheerde alternatief waarmee je vergelijkt, kan volgend kwartaal een andere minimumprijs hebben. Reken het dus door met je eigen factuur voordat je beslist.

Wanneer is het zinvol om PostgreSQL zelf te hosten?

Zelf PostgreSQL hosten op een VPS is zinvol als je team basiskennis van Linux heeft, je een stabiele werklast met een voorspelbare werkset hebt en je een echte reden hebt om van de beheerde factuur af te willen.

Het werkt niet als je geen capaciteit voor beheer hebt, als je te maken hebt met wettelijke eisen voor hoge beschikbaarheid (HA) die je niet zelf kunt bouwen, of als je een grillig gebruikspatroon hebt dat baat heeft bij direct opschalen.

Drie dingen bepalen deze beslissing: kosten, privacy en datasoevereiniteit, en controle.

Waar zelf hosten duidelijk wint:

• Stabiel verkeer in één regio met een voorspelbare werkset.
• Kleine tot middelgrote SaaS-apps met één Postgres-database en een team dat vertrouwd is met Linux.
• Privacygevoelige werklasten waarbij de database niet in de omgeving van een ander hoort te staan.
• Kostenbewuste teams waarvan de beheerde factuur ongemerkt is opgelopen tot boven het punt waarop het operationele gedoe de moeite waard wordt.

Waar beheerd duidelijk wint:

• Grillige werklasten die baat hebben bij direct op- en afschalen.
• Opstellingen in meerdere regio's waar wereldwijde replicatie het product is.
• Gereguleerde omgevingen die kant-en-klare HA, compliancecertificeringen en audittrails nodig hebben.
• Teams zonder vrije beheercapaciteit en zonder plan om die op te bouwen.

Het getal van 40% tot 60% kostenbesparing wordt vaak aangehaald. Let goed op de datum.

In 2021 documenteerde AWS-auteur Rupesh Desai dat PostgreSQL op EC2 bij vergelijkbare specificaties 40% tot 60% goedkoper was dan RDS. Die cijfers zijn ouder dan de meeste huidige RDS-instancefamilies.

De actuele versie is de kostenanalyse van byteiota, eind 2025 gepubliceerd, die stelt dat RDS 75% tot 88% duurder is dan vergelijkbare dedicated hardware.

Het eerlijke omslagpunt zit in operationele uren, niet in serverkosten.

Hoe kies je de juiste VPS-grootte voor PostgreSQL?

De meeste productiedatabases van applicaties draaien prima op 4 GB RAM met NVMe-opslag. Grotere datasets, veel gelijktijdige verbindingen of analysewerklasten verhogen de behoefte naar 8 GB, 16 GB of meer.

RAM bepaalt hoeveel van je werkset Postgres in het geheugen kan houden. Zodra veelgebruikte pagina's naar de schijf uitwijken, worden query's trager. NVMe is belangrijk omdat Postgres gevoelig is voor de latentie van willekeurige leesacties bij veelgebruikte pagina's en voor de doorvoersnelheid bij het wegschrijven van de write-ahead log.

Gangbaar advies voor het afstemmen van PostgreSQL begint met:

• shared_buffers op ongeveer 25% van het systeem-RAM.
• effective_cache_size op ongeveer 50%-75% van het systeem-RAM.
• work_mem voorzichtig ingesteld, op basis van de complexiteit van gelijktijdige query's en niet alleen het totale RAM.

Op een VPS met 4 GB betekent dat meestal dat je ongeveer 1 GB aan shared_buffers toewijst en genoeg geheugen overlaat, zodat de paginacache van Linux vaak gebruikte data kan vasthouden. Die balans is een van de redenen waarom een bescheiden machine met 4 GB veel kleine tot middelgrote productiewerklasten prima aankan.

Welk pakket bij welke werklast past:

De VPS-hostingplannen van DreamHost geven je roottoegang, NVMe-opslag en ongelimiteerde bandbreedte voor een voorspelbaar maandbedrag.

Dat zijn precies de vier dingen waar een zelfgehoste Postgres-werklast van afhangt.

Hoe installeer je PostgreSQL op een VPS?

Je installeert PostgreSQL op een VPS in vijf beknopte stappen.

1. Richt de VPS in: Kies een pakket met genoeg RAM voor je werkset (Stack 8/8 GB voor productie). Ubuntu 24.04 LTS is het aanbevolen besturingssysteem. Log in via SSH met sleutelauthenticatie, niet met een wachtwoord.
2. Installeer vanuit de officiële PGDG-repository: Met ‘apt install postgresql’ uit de distributie loop je achter op hoofdversies. Voeg de PGDG-apt-repository toe en voer dan uit: ‘sudo apt install postgresql-18.’ Controleer met: ‘sudo systemctl status postgresql’
3. Stel het postgres-wachtwoord in en maak je app-rol aan: Voer sudo -i -u postgres uit, daarna psql en dan password postgres. Maak een aparte rol met minimale rechten aan: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ en ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Bind de listener correct: Open /etc/postgresql/18/main/postgresql.conf. Stel listen_addresses = ‘localhost’ in als de app en de database op dezelfde machine draaien, of bind aan een privé-IP als de app op een aparte VPS draait. Bind PostgreSQL niet aan 0.0.0.0 op een publiek bereikbare interface. Blootgestelde PostgreSQL-instances worden agressief gescand en met brute force aangevallen door geautomatiseerde bots.
5. Beveilig ‘pg_hba.conf’ en UFW: Pas pg_hba.conf zo aan dat alleen de applicatie-IP's die je echt nodig hebt toegang krijgen, met ‘scram-sha-256’ als authenticatiemethode. Stel UFW zo in dat poort 5432 alleen openstaat voor diezelfde IP's. Gebruik een SSH-tunnel voor beheertools (en zet 5432 alsjeblieft niet open voor het publieke internet).

Probeer dit vanaf een andere machine: psql -h <vps-ip> -U postgres.

Een time-out of geweigerde verbinding vanaf een niet-geautoriseerd IP betekent meestal dat je listener en firewallregels hun werk doen. Krijg je vanaf het publieke internet een wachtwoordprompt, dan is er iets verkeerd ingesteld. Zodra Postgres draait, is de configuratie pas het halve werk.

Hoe beveilig je PostgreSQL op een VPS?

PostgreSQL op een VPS beveilig je op drie lagen, plus goed rollenbeheer en een vast patchritme.

1. Authenticatie: Gebruik scram-sha-256 voor nieuwe installaties en verwijder verouderde md5-regels uit pg_hba.conf. De documentatie van PostgreSQL waarschuwt inmiddels dat de ondersteuning voor MD5-versleutelde wachtwoorden is afgeschaft en in een toekomstige release verdwijnt.
2. Netwerk: Bind PostgreSQL aan ‘localhost’, een privé-IP of een interface die alleen je applicatieservers kunnen bereiken. Bind het niet aan een publiek bereikbare interface. Zet UFW daar bovenop en sta poort 5432 alleen toe vanaf vertrouwde applicatie-IP's.
3. Versleuteling tijdens transport: Zet TLS aan voor elke verbinding die een netwerkgrens passeert. Zet ssl = on in postgresql.conf en gebruik daarna hostssl … scram-sha-256-regels in pg_hba.conf, zodat clients niet ongemerkt terugvallen op verbindingen zonder TLS. Zelfondertekende certificaten zijn prima voor intern verkeer, als clients ze goed verifiëren.
4. Rollen: Applicatieverbindingen horen een rol te gebruiken met minimale rechten, dus alleen de rechten die nodig zijn voor de schema's van die app. De superuser is voor migraties en noodgevallen.
5. Patchen: Gebruik de PGDG-apt-repository voor actuele PostgreSQL-pakketten. Schakel automatische beveiligingsupdates in voor het besturingssysteem, maar plan PostgreSQL-updates bewust, zodat een onverwachte herstart niet je incident van de week wordt.

Je beveiligingschecklist:

• Gebruik alleen scram-sha-256; schakel md5 uit.
• Bind ‘listen_addresses’ aan localhost of een privé-IP.
• UFW-regels staan 5432 alleen toe vanaf vertrouwde IP's.
• SSL/TLS aan voor elke verbinding over het netwerk.
• De app maakt verbinding met een rol met minimale rechten, nooit als ‘postgres’.
• Automatische beveiligingsupdates ingeschakeld.
• Nooit en nergens een regel ‘host all all 0.0.0.0/0 md5’ in ‘pg_hba.conf’.

Dat laatste punt is het waarschuwende voorbeeld.

Een publiek bereikbare poort 5432 met zwakke inloggegevens is een bekend doelwit voor cryptominers en brute-force-aanvallen. Blootgestelde PostgreSQL-instances worden voortdurend gescand door geautomatiseerde bots die zoeken naar standaardaccounts, gelekte wachtwoorden of te ruime pg_hba.conf-regels.

Publiek bereikbare Postgres-instances met zwakke authenticatie worden vaak schrikbarend snel gehackt. Een database die zonder goede netwerkbeveiliging, TLS en rolscheiding direct aan het internet hangt, is het soort fout dat eindigt in een incidentrapport. En ook een goed geconfigureerde database is nog altijd één kapotte schijf verwijderd van dataverlies.

Hoe maak je back-ups en replica's van PostgreSQL op een VPS?

Voor back-ups van PostgreSQL op een VPS gebruik je een van drie mechanismen, afhankelijk van de storing waartegen je je wilt beschermen: logische back-ups via pg_dump voor overdraagbaarheid, fysieke back-ups via pg_basebackup plus WAL-archivering voor herstel naar een specifiek tijdstip, en streamingreplicatie voor hoge beschikbaarheid.

Logische back-ups gebruik je voor migraties, gedeeltelijk herstel en het verversen van ontwikkelomgevingen. Voer pg_dump –format=custom –file=mydb.dump mydb_prod uit vanuit een dagelijkse cron job. Het custom-formaat comprimeert goed en ondersteunt, net als het directory-formaat, de opties van pg_restore voor parallel en selectief herstel. Zet de dump op S3-compatibele objectopslag buiten de VPS.

Fysieke back-ups zijn bedoeld voor herstel van het volledige systeem en herstel naar een specifiek tijdstip. Met pg_basebackup plus continue archivering van de Write-Ahead Log (WAL) kun je herstellen naar elk moment tussen de laatste basisback-up en het meest recente WAL-segment. Dat is de productiewaardige optie als je hooguit seconden aan data mag verliezen, geen uren.

Streamingreplicatie is de derde optie. Een leesreplica op een tweede VPS dient als hot standby voor leesintensieve werklasten of als snel failoverdoel. Deze vorm van databasereplicatie kost een tweede VPS, maar beperkt je ergste storing tot enkele minuten.

Test je restores maandelijks. Beheerde diensten regelen dit allemaal voor je; dat is een deel van wat je opgeeft in ruil voor de besparing van zelf hosten. Zit je al bij een beheerde provider, dan is overstappen eenvoudiger dan het lijkt.

Hoe migreer je van RDS, Supabase of Neon naar een VPS?

Je migreert in vier stappen van een beheerde Postgres-provider naar een VPS.

1. Richt de doel-VPS in: Zorg dat de hoofdversie van Postgres exact overeenkomt met de bron. Installeer PostgreSQL op de nieuwe VPS volgens de stappen hierboven en maak daarna alvast de applicatierol en de database aan.
2. Maak een dump van de bron: Voer pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string> uit. De flags –no-owner en –no-privileges verwijderen providerspecifieke rolrechten die zich op een nieuwe host zelden netjes laten herstellen.
3. Herstel op het doel: Voer pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump uit. Let op waarschuwingen over extensies. RDS, Supabase en Neon schakelen vaak extensies in die in standaard-Postgres mogelijk niet bestaan. Installeer compatibele extensies uit PGDG-pakketten of postgresql-contrib voordat je de restore uitvoert.
4. Verbindingsstring omzetten en controleren: Laat eerst een stagingomgeving naar de nieuwe VPS wijzen, draai je testsuite en valideer daarna representatieve productiequery's en applicatieflows voordat je de verbindingsstring voor productie omzet. Voor applicaties met weinig schrijfacties is een kort onderhoudsvenster tijdens de definitieve overstap vaak eenvoudiger dan replicatie opzetten. Houd de brondatabase nog een aantal dagen online en alleen-lezen, zodat je kunt terugvallen.

Wat verandert er per provider?

1. Vanuit RDS: RDS-specifieke rollen (‘rds_superuser’, ‘rdsadmin’) bestaan niet in standaard-Postgres; –no-owner en –no-privileges vangen het meeste daarvan op. Sommige door RDS beheerde extensies moet je handmatig installeren, en uitgaand verkeer uit AWS tijdens de dump wordt in rekening gebracht.
2. Vanuit Supabase: De Postgres is echte Postgres, maar de auth-, opslag- en edge-lagen van Supabase verhuizen niet mee. Je applicatieschema wel. Vervang die lagen door zelfgehoste alternatieven voordat je overstapt.
3. Vanuit Neon: Na de migratie is branching verdwenen; plan in plaats daarvan back-ups. Dumpen en herstellen is eenvoudig, maar gewoontes zoals directe branches hebben een vervangende werkwijze nodig.

De migratie zelf kost meestal minder tijd dan het kiezen van je VPS-plan. Reken realistisch op enkele minuten downtime bij kleine databases, en langer bij grote databases door het opnieuw afspelen van WAL. De meeste installaties stoppen hier, maar er is één scenario dat je verder duwt…

Wanneer voeg je PgBouncer toe en wanneer blijf je bij standaard Postgres?

De meeste apps op een VPS met 4 GB hebben in het begin geen verbindingspooler nodig. Voeg PgBouncer toe zodra het aantal gelijktijdige verbindingen boven de ongeveer 100 uitkomt, of als je applicatiestack per verzoek een nieuwe verbinding opent.

PostgreSQL-verbindingen zijn zwaar, omdat elke verbinding een volledig besturingssysteemproces is. Met 4 GB RAM wil je geen honderden inactieve verbindingen die geheugen opslokken. De pooler houdt aan de ene kant de dure Postgres-verbindingen vast en deelt aan de andere kant goedkope, kortstondige verbindingen uit aan je app.

Twee poolingmodi zijn belangrijk:

• Sessiepooling: Elke client krijgt voor de hele sessie één serververbinding. Veilig voor elke app en zonder verandering in gedrag, maar met minder doorvoerwinst.
• Transactiepooling: Elke client krijgt een serververbinding voor één transactie. Flinke doorvoerwinst. Je verliest wel functies die op sessiestatus leunen (prepared statements, advisory locks, ‘LISTEN’/‘NOTIFY’), tenzij de app daarop is geschreven.

De meeste kleine SaaS-apps met een ORM die verbindingen pooled, redden zich prima zonder PgBouncer, totdat dat niet meer zo is. Het signaal dat je over de grens bent: foutmeldingen als ‘FATAL: too many connections’ of geheugendruk door inactieve verbindingen.

Installeer het met sudo apt install pgbouncer, stel in /etc/pgbouncer/pgbouncer.ini je lijst met databases en de poolmodus in, en laat de app daarna via poort 6432 met PgBouncer verbinden.

Ja, je merkt vanzelf wanneer je het nodig hebt.

De knoop doorhakken

Het kostenverschil is groot genoeg om het eens door te rekenen met je eigen factuur. Maar de installatie is niet het moeilijke deel.

Het moeilijke deel is het operationele werk waar je met de rekening van je beheerde database voor betaalde. Back-ups, hersteloefeningen, patchen en monitoring.

Hoe dan ook: haal even diep adem voordat je die volgende factuur opent.

Veelgestelde vragen over PostgreSQL op een VPS