Zelf-gehoste PostgreSQL op een VPS: Ontsnap aan Beheerde DB-prijzen

Rekenen. Opslag. Back-upretentie.

De snapshot-export waar je niet meer aan dacht. De uitgaande kosten van de stagingomgeving die afgelopen dinsdag een ‘pg_dump’ uitvoerde.

Niemand opent zijn factuur voor beheerde databases in de verwachting dat deze goedkoop zal zijn.

Maar, verdorie.

Het verschil tussen “Postgres voor $25 per maand” en wat er op de kaart verschijnt is groot geworden, en een 4 GB VPS voor de prijs van een enkele Supabase add-on kan nu je hele database draaien met nog ruimte over voor het OS om populaire pagina’s te cachen.

Zelf een productie Postgres-database hosten is niet langer de operationele nachtmerrie die het ooit was. De PostgreSQL Global Development Group (PGDG) repo is solide; moderne PostgreSQL-installaties (v14+) gebruiken standaard SCRAM-SHA-256 wachtwoordversleuteling, met de officieel verouderde MD5 vanaf v18. De redenen waarom mensen tegenwoordig bij RDS, Supabase of Neon blijven, zijn operationeel, niet technisch.

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

Wat Kost Het Eigenlijk Om PostgreSQL Zelf Te Hosten Op Een VPS?

Een zelf-gehoste PostgreSQL op een 4 GB VPS draait vaak tegen een fractie van de equivalente RDS, Supabase Pro of Neon Scale-prijzen, zodra opslag, back-ups en uitgaand verkeer zijn opgenomen in de beheerde factuur.

PostgreSQL is de database die 55,6% van de ontwikkelaars gebruikt, volgens de Developer Survey van Stack Overflow uit 2025, de populairste voor het tweede achtereenvolgende jaar. Het is ook de database die je gemakkelijk zelf kunt draaien.

Vergelijking voor een representatieve werklast van een klein team (4 GB RAM, ~100 GB data, lage tot gematigde schrijfbelasting, enkele regio), geprijsd per mei 2026:

Optie	Rekenen	Opslag	Egress voorbij de gratis tier	Beste voor
Zelf gehost op een 4 GB VPS	Vaste planprijs	Gewoonlijk inbegrepen	Meestal ongemeten of hoge capaciteit	Stabiele werklasten, budgetbewuste teams die vertrouwd zijn met Linux
AWS RDS db.t4g.medium	$47.45/maand alleen rekenen	~$0.115/GB-maand gp3	~$0.09/GB internet/buiten-regio	Teams die beheerde back-ups, failover en AWS-native operaties willen
Supabase Pro	$25/maand basis + gebruik	$0.125/GB database schijf voorbij de 8 GB inbegrepen	$0.09/GB voorbij 250 GB	Apps die Postgres, autorisatie, opslag en realtime in één stack nodig hebben
Neon Scale	$0.222 per CU/uur	$0.35 per GB/maand	Gebruiksmeter	Piekerige, preview-zware, branch-zware ontwikkelingsworkflows

De on-demand prijs van RDS db.t4g.medium is ongeveer $0.065 per uur, of ongeveer $47.45 per maand alleen voor rekenen.

Voeg 100 GB aan gp3-opslag toe voor ongeveer $0.115/GB-maand en geautomatiseerde back-ups, en een Single-AZ box kost ongeveer $60/maand. Activeer Multi-AZ failover en de rekenlijn verdubbelt ongeveer, waardoor een productieklare configuratie naar $100/maand en hoger gaat.

Dat is geen kleine kloof.

Self-hosting is goedkoper omdat jij het werk doet waarvoor de beheerde rekening betaalde. Discipline in operations, oproepbaar, om 2 uur ‘s nachts als de schijf vol raakt. Het beheerde-DB alternatief waar je tegen afzet, kan volgend kwartaal een andere ondergrens hebben, dus bereken de kosten tegen je eigen rekening voordat je je vastlegt.

Wanneer Is Zelf-Hosting Van PostgreSQL Zinvol?

PostgreSQL zelf hosten op een VPS is logisch wanneer je basiscomfort met Linux in het team hebt, een stabiele werklast, een voorspelbare werksetgrootte en een echte reden om de beheerde rekening te ontvluchten.

Het werkt niet als je geen operationele capaciteit hebt, gereguleerde HA-vereisten die je zelf niet kunt bouwen, of een bursty patroon dat profiteert van onmiddellijke schaalvergroting.

Drie dingen sturen deze beslissing aan. Kosten, privacy en data-soevereiniteit, en controle.

Waar zelfgehoste oplossingen duidelijk winnen:

• Gestage verkeer in een enkele regio met een voorspelbare werkset.
• Kleine tot middelgrote SaaS-applicaties met één Postgres-database en een team dat vertrouwd is met Linux.
• Privacygevoelige werklasten waarbij de database niet in de tenancy van iemand anders moet staan.
• Kostenbewuste teams wiens beheerde rekening de operationele lastendrempel heeft overschreden.

Waar Beheerd Duidelijk Wint:

• Bursty werklasten die profiteren van onmiddellijke op- en afschaling.
• Multi-regio opstellingen waar wereldwijde replicatie het product is.
• Gereguleerde omgevingen die turnkey HA, compliancecertificaten en audittrajecten nodig hebben.
• Teams zonder extra operationele capaciteit en geen plan om dit op te bouwen.

Het besparingspercentage van 40% tot 60% wordt vaak genoemd. Dateer het zorgvuldig.

Vanaf 2021 documenteerde AWS-auteur Rupesh Desai PostgreSQL op EC2 dat 40% tot 60% goedkoper draait dan RDS bij gelijkwaardige specificaties, ouder dan de meeste huidige RDS instantie families.

De huidige versie is byteiota’s kostenstapelanalyse, gepubliceerd in eind 2025, die zegt dat RDS 75% tot 88% duurder is dan equivalente dedicated hardware.

Het eerlijke break-evenpunt zijn operationele uren, niet de serverkosten.

Hoe Kies Je De Juiste VPS-Grootte Voor PostgreSQL?

De meeste productietoepassingsdatabases draaien comfortabel op 4 GB RAM met NVMe-opslag. Grotere datasets, zware gelijktijdige verbindingen of analytische werklasten verhogen de behoefte naar 8 GB of 16 GB en hoger.

RAM bepaalt hoeveel van je werkset Postgres in het geheugen kan houden; zodra hot pages naar de schijf worden verplaatst, vertragen de queries. NVMe is belangrijk omdat Postgres gevoelig is voor willekeurige-leeslatentie voor hot pages en voor doorvoersnelheid van flush voor het write-ahead logboek.

Algemene PostgreSQL afsteladviezen beginnen met:

• shared_buffers ongeveer 25% van het systeem RAM.
• effective_cache_size ongeveer 50%-75% van het systeem RAM.
• work_mem behoudend ingesteld — gebaseerd op de complexiteit van gelijktijdige queries, niet alleen op het totale RAM.

Op een 4 GB VPS betekent dat meestal het toewijzen van ongeveer 1 GB aan shared_buffers, terwijl er voldoende geheugen overblijft voor de Linux-pagina-cache om vaak geraadpleegde gegevens vast te houden. Die balans is een van de redenen waarom een bescheiden 4 GB box veel kleine tot middelgrote productiewerklasten comfortabel kan draaien.

De plankaart die je moet kennen:

RAM Niveau	Typische Werklast	Aanbevolen Stack Plan
2 GB	Ontwikkelomgevingen, projecten met weinig verkeer	Onder de basislijn
4 GB	De meeste productie applicatiedatabases	Stack 4
8 GB	Grotere datasets, meer gelijktijdige verbindingen	Stack 8
16 GB+	Postgres naast andere zware diensten, analytics	Stack 16

DreamHost’s VPS Hosting-plannen geven je root-toegang, NVMe-opslag en ongemeten bandbreedte op een voorspelbare maandelijkse factuur.

Dat zijn de vier dingen waar een zelf-gehoste Postgres werklast van afhangt.

Hoe Installeer Je PostgreSQL Op Een VPS?

Je installeert PostgreSQL op een VPS in vijf gecomprimeerde stappen.

1. Bereid De VPS Voor: Kies een plan met voldoende RAM voor je werkset (Stack 4/4 GB is de basislijn). Ubuntu 24.04 LTS is het aanbevolen besturingssysteem. Log in via SSH met sleutelgebaseerde authenticatie, niet met een wachtwoord.
2. Installeer vanuit de officiële PGDG-repo: De distro 'apt install postgresql' loopt achter op grote versies. Voeg de PGDG apt repo toe, daarna 'sudo apt install postgresql-18.' Bevestig met 'sudo systemctl status postgresql'
3. Stel het postgres-wachtwoord in en creëer je app-rol: Voer sudo -i -u postgres uit, daarna psql, vervolgens password postgres. Creëer een speciale rol met minimale rechten: 'CREATE ROLE myapp WITH LOGIN PASSWORD '...';' en 'CREATE DATABASE myapp_prod OWNER myapp;'
4. Configureer de listener correct: Open /etc/postgresql/18/main/postgresql.conf. Stel listen_addresses = ‘localhost’ in als de app en database dezelfde box delen, of bind aan een privé-IP als de app op een aparte VPS draait. Vermijd het binden van PostgreSQL aan 0.0.0.0 op een publiek bereikbare interface. Blootgestelde PostgreSQL-instanties worden agressief gescand en brute-force aangevallen door geautomatiseerde bots.
5. Beveilig ‘pg_hba.conf’ en UFW: Bewerk pg_hba.conf om alleen de applicatie-IP’s die je daadwerkelijk nodig hebt toe te staan, met ‘scram-sha-256’ als de auth-methode. Configureer UFW om poort 5432 alleen van diezelfde IP’s toe te laten. Gebruik een SSH-tunnel voor beheertools (en open alsjeblieft 5432 niet naar het openbare internet).

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

Een time-out of geweigerde verbinding van een niet-geautoriseerd IP betekent meestal dat je listener en firewallregels hun werk doen. Een wachtwoordprompt vanaf het openbare internet betekent dat er iets verkeerd is geconfigureerd. Zodra Postgres draait, is de configuratie slechts half het werk.

Hoe Beveilig Je PostgreSQL Op Een VPS?

PostgreSQL op een VPS wordt op drie lagen beveiligd, plus rolhygiëne en patchfrequentie.

1. Authenticatie: Gebruik scram-sha-256 voor nieuwe installaties en verwijder oude md5-regels uit pg_hba.conf. PostgreSQL’s documentatie waarschuwt nu dat ondersteuning voor met MD5-versleutelde wachtwoorden verouderd is en in een toekomstige uitgave zal worden verwijderd.
2. Netwerk: Bind PostgreSQL aan ‘localhost’, een privé IP, of een interface die alleen bereikbaar is door je applicatieservers. Vermijd het te binden aan een publiek bereikbare interface. Leg UFW eroverheen en sta poort 5432 alleen toe van vertrouwde applicatie-IP’s.
3. Encryptie Tijdens Transport: Zet TLS aan voor elke verbinding die een netwerkgrens overschrijdt. Stel ssl = aan in in postgresql.conf, gebruik dan hostssl … scram-sha-256 regels in pg_hba.conf zodat clients niet stilletjes kunnen terugvallen op niet-TLS verbindingen. Zelfondertekende certificaten zijn acceptabel voor intern verkeer als clients deze correct verifiëren.
4. Rollen: Applicatieverbindingen moeten een rol met zo min mogelijk rechten gebruiken, 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 repo voor actuele PostgreSQL pakketten. Schakel onbeheerde beveiligingsupdates in voor het besturingssysteem, maar plan PostgreSQL-updates bewust zodat een verrassende herstart niet je incident van de week wordt. 

Jouw beveiligingschecklist:

• Gebruik alleen scram-sha-256; schakel md5 uit.
• Stel ‘listen_addresses’ in op localhost of een privé IP.
• UFW-regels staan 5432 alleen toe van vertrouwde IP’s.
• SSL/TLS ingeschakeld voor elke verbinding die het netwerk kruist.
• App verbindt als een rol met minimale rechten, nooit als ‘postgres’.
• Beveiligingsupdates zonder toezicht ingeschakeld.
• Geen ‘host all all 0.0.0.0/0 md5’ regels ergens in ‘pg_hba.conf’, nooit.

Die laatste bullet is de waarschuwende boodschap.

Publiek toegankelijke poort 5432 met zwakke inloggegevens is een bekend doelwit voor cryptominers en brute-force aanvallen. Blootgestelde PostgreSQL-instanties worden continu gescand door geautomatiseerde bots die zoeken naar standaardaccounts, gelekte wachtwoorden of permissieve pg_hba.conf-regels.

Publiek toegankelijke Postgres-instanties met zwakke authenticatie worden vaak schrikbarend snel gecompromitteerd. Een database die direct aan het internet is blootgesteld zonder de juiste netwerkcontroles, TLS en rolisolatie is het soort fout dat uitmondt in een incidentrapport. Een goed geconfigureerde database is nog steeds slechts één schijffout verwijderd van gegevensverlies.

Hoe Maak Je Een Back-up En Repliceer Je PostgreSQL Op Een VPS?

PostgreSQL-back-ups op een VPS gebruiken een van de drie mechanismen, gekozen op basis van de storing die je wilt voorkomen. Logische back-ups via pg_dump voor draagbaarheid, fysieke back-ups via pg_basebackup plus WAL-archivering voor herstel naar een specifiek tijdstip, en streamingrepliecatie voor hoge beschikbaarheid.

Logische back-ups behandelen migraties, gedeeltelijke herstellingen en ontwikkelingsverversingen. Voer pg_dump –format=custom –file=mydb.dump mydb_prod uit vanuit een dagelijkse Cron Job. Het aangepaste formaat comprimeert goed en ondersteunt, samen met het directoryformaat, pg_restore’s parallele en selectieve herstelopties. Verplaats de dump naar off-VPS objectopslag (DreamObjects, S3-compatibel).

Fysieke back-ups zorgen voor volledige systeemherstel en herstel op een specifiek tijdstip. pg_basebackup plus continue Write-Ahead Log (WAL) archivering stelt je in staat om te herstellen naar elk moment tussen de laatste basisback-up en het meest recente WAL-segment, de productieklasse optie wanneer de tolerantie voor gegevensverlies seconden is, niet uren.

Streaming replicatie is de derde optie. Een leesreplica op een tweede VPS is een hot standby voor leesintensieve werklasten of een snel failover-doel. De opzet van database-replicatie kost een tweede VPS, maar beperkt je maximale uitvaltijd tot minuten.

Mechanisme	Wat Het Je Biedt	Wat Het Kost
pg_dump + cron + off-VPS opslag	Dagelijkse logische back-up, draagbaar	Herstelvertraging, geen punt-in-tijd herstel
pg_basebackup + WAL-archivering	Fysieke back-up met punt-in-tijd herstel	Opslag en operationele complexiteit
Streaming replicatie	Hot standby, bijna nul Herstelpuntdoelstelling (RPO), leesschaalvergroting	Tweede VPS plus replicatiebeheer

Herstel-test maandelijks. Beheerde diensten nemen dit allemaal op, en dat is een deel van wat de besparingen van zelfhosting terugkopen. Als je al bij een beheerde provider zit, is de weg naar buiten eenvoudiger dan het lijkt.

Hoe Migreer Je Van RDS, Supabase Of Neon Naar Een VPS?

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

1. Configureer de doel-VPS: Stem overeen met de bron Postgres hoofdversie exact. Installeer PostgreSQL op de nieuwe VPS volgens de bovenstaande stappen, en creëer vooraf de applicatierol en database.
2. Dump van de bron: Voer pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string> uit. De –no-owner en –no-privileges vlaggen verwijderen provider-specifieke roltoekenningen die zelden netjes opnieuw gecreëerd worden op een nieuwe host.
3. Herstel naar 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 mogelijk niet bestaan op standaard Postgres. Installeer compatibele extensies uit PGDG-pakketten of postgresql-contrib voordat je herstelt.
4. Verbindingssnaarwissel en verificatie: Wijs een testomgeving eerst naar de nieuwe VPS, voer je testsuite uit, valideer vervolgens representatieve productiequery’s en applicatieflows voordat je de productieverbindingssnaar wisselt. Voor toepassingen met weinig schrijfacties is een kort onderhoudsvenster tijdens de uiteindelijke overgang vaak eenvoudiger dan replicatie instellen. Houd de bron-database online en alleen-lezen voor meerdere dagen als een terugvaldoel.

Wat verandert er per provider?

1. Van RDS: Specifieke RDS-rollen (‘rds_superuser,’ ‘rdsadmin’) bestaan niet in standaard Postgres; –no-owner en –no-privileges regelen het meeste. Sommige door RDS beheerde extensies vereisen een handmatige installatie, en uitgaand verkeer uit AWS tijdens de dump is factureerbaar.
2. Van Supabase: De Postgres is echte Postgres, maar de auth, opslag en edge lagen van Supabase migreren niet. Je applicatieschema doet dat wel. Vervang deze lagen door zelf-gehoste equivalenten voordat je overschakelt.
3. Van Neon: Vertakkingen zijn verdwenen na migratie; plan in plaats daarvan voor back-ups. Dump-en-herstel is eenvoudig, maar operationele gewoonten zoals onmiddellijke vertakkingen hebben een vervangende workflow nodig.

De migratie zelf duurt meestal minder lang dan het kiezen van het VPS-plan. Realistische downtime is enkele minuten voor kleine databases, langer met WAL-replay voor grote databases. De meeste installaties stoppen hier, maar er is één scenario dat je verder duwt…

Wanneer Moet Je PgBouncer Toevoegen of Bij Vanilla Postgres Blijven?

De meeste apps op een 4 GB VPS hebben in het begin geen connection pooler nodig. Voeg PgBouncer toe wanneer het aantal gelijktijdige verbindingen ongeveer 100 overschrijdt, of wanneer je applicatiestack een nieuwe verbinding opent per verzoek.

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

Twee poolingmodi zijn belangrijk:

• Sessie pooling: Elke client krijgt één serververbinding voor de sessie. Veilig voor elke app, geen verandering in semantiek, lagere doorvoerverhoging.
• Transactie pooling: Elke client krijgt een serververbinding voor één transactie. Grote doorvoerverhoging. Je verliest functies die afhankelijk zijn van sessiestatus (voorbereide verklaringen, adviserende sloten, ‘LISTEN’/’NOTIFY’) tenzij de app is geschreven om dit te verwachten.

De meeste kleine SaaS-apps met een connection-pooled ORM zijn prima zonder PgBouncer totdat ze dat niet meer zijn. Het signaal dat je de grens hebt overschreden, zijn ‘FATAL: too many connections’ fouten of geheugendruk van inactieve verbindingen.

Installeer het met sudo apt install pgbouncer, configureer /etc/pgbouncer/pgbouncer.ini met je lijst van databases en poolmodus, en richt de app op PgBouncer op poort 6432.

Ja, je zult het weten wanneer je het nodig hebt.

De Laatste Beslissing Nemen

Het prijsverschil is groot genoeg om het rekenwerk tegen je eigen rekening te rechtvaardigen. Maar de installatie is niet het moeilijkste deel.

Het moeilijke deel is het operationele werk waarvoor de beheerde rekening betaalde. Back-ups, hersteloefeningen, patchen en monitoren.

Hoe dan ook, haal diep adem voordat je de volgende factuur opent.

Veelgestelde Vragen Over PostgreSQL Op Een VPS

Hoeveel RAM Heeft PostgreSQL Nodig Op Een VPS?

PostgreSQL draait op 1 tot 2 GB voor kleine werklasten en comfortabel op 4 GB voor de meeste productie-applicatiedatabases. Zwaardere datasets, meer gelijktijdige verbindingen of analytische werklasten verhogen de vereiste naar 8 GB of meer.

Kan ik PostgreSQL draaien op een 2 GB VPS?

Ja, je kunt PostgreSQL draaien op een 2 GB VPS voor kleine apps, ontwikkelomgevingen en projecten met weinig verkeer. Een 2 GB box laat weinig ruimte voor caching, dus de prestaties van queries nemen af naarmate je data het geheugen overschrijdt. Voor productiewerklasten is 4 GB de veiligere basislijn.

Is Zelfhosting Van PostgreSQL Op Een VPS Goedkoper Dan RDS Of Supabase?

Ja, zelf-hosting PostgreSQL op een VPS is goedkoper dan RDS of Supabase voor de meeste constante werklasten. Een 4 GB VPS draait vaak voor een fractie van de equivalente RDS, Supabase Pro, of Neon Scale specificatie zodra opslag, back-ups en egress erbij komen. De afweging is dat je zelf de database beheert.

Hoe stel ik PostgreSQL veilig bloot op een VPS?

Stel poort 5432 niet bloot aan het openbare internet. Bind PostgreSQL aan localhost of een privé IP, vereis scram-sha-256 authenticatie en gebruik SSH-tunnel admin tools in plaats van 5432 te openen naar je laptop. Openbare 5432 met zwakke authenticatie is een bekend doelwit voor cryptominers.

Moet ik Docker gebruiken voor PostgreSQL op een VPS?

Nee, Docker is niet vereist. De officiële PGDG apt repository installeert PostgreSQL als een native systeemservice, wat de eenvoudigste opstelling voor productiekwaliteit is. Docker is redelijk als je al andere containers uitvoert.

Hoe maak ik een back-up van PostgreSQL op een VPS?

Voer pg_dump –format=custom dagelijks uit op een cron-schema en sla de uitvoer op buiten de VPS in S3-compatibele objectopslag. Gebruik pg_basebackup plus WAL-archivering voor herstel op een specifiek tijdstip wanneer seconden van gegevensverlies belangrijk zijn. Test maandelijks het herstel.

Welk plan moet ik kiezen voor het zelf hosten van PostgreSQL op DreamHost?

Het VPS Stack 4 plan (4 GB RAM) van DreamHost is de aanbevolen basis voor de meeste productie-applicatiedatabases. Kies Stack 8 (8 GB) voor grotere datasets of hoge gelijktijdigheid, en Stack 16 voor Postgres naast andere bronintensieve diensten.

Moet Ik PgBouncer Gebruiken Met PostgreSQL Op Een Kleine VPS?

De meeste apps op een 4 GB VPS hebben aan het begin geen PgBouncer nodig. Voeg een connection pooler toe wanneer het aantal gelijktijdige verbindingen de 100 nadert, of wanneer je app bij elke aanvraag een nieuwe verbinding opent.