Dit is echter geen universeel concept. Supabase en Aurabase, die speciale Postgres-instanties leveren, stellen ditzelfde mechanisme niet op dezelfde manier bloot. Dit artikel beschrijft wat Neon feitelijk documenteert over zijn eigen koude start, hoe Vercel Postgres en Supabase zich met elkaar vergelijken, en waar het Aurabase-model past, rechtstreeks geverifieerd in de provisioner-code in plaats van afgeleid van een marketingpagina.
De essentie
- Serverloze koude start verwijst naar de vertraging die wordt toegevoegd wanneer een opgeschorte database zijn rekenkracht moet ontwaken voordat hij op het eerste verzoek reageert.
- Neon scheidt opslag en berekening: de computer gaat in de slaapstand na een gedocumenteerde periode van inactiviteit (standaard 5 minuten bij het gratis abonnement, configureerbaar bij de betaalde abonnementen).
- Neon documenteert een herstart die doorgaans in de orde van een paar honderd milliseconden tot een paar seconden ligt, een cijfer gepubliceerd door de uitgever, live meetbaar via de communitytool neon-latency-benchmarks.vercel.app.
- Vercel Postgres vertrouwt op de Neon-infrastructuur: het ontwaakgedrag volgt dezelfde mechanismen, onder een ander merk.
- Supabase biedt een dedicated database per project, zonder koude start per verbinding. Alleen het gratis abonnement pauzeert inactieve projecten, met handmatig herstel.
- Aurabase levert een speciale Postgres-database per project, een speciaal CNPG-cluster of een speciale basis op een gedeeld cluster: dit is geen Neon-serverloos model, geverifieerd in de provisioner-code.
Wat is een koude start voor een serverloze Postgres-database?
Er vindt een koude start plaats wanneer de computer waarop uw database wordt uitgevoerd, door inactiviteit in de sluimerstand is gezet en een nieuwe query deze eerst opnieuw moet opstarten voordat deze wordt uitgevoerd. Dit is niet de gebruikelijke netwerklatentie van een typische TCP/TLS-verbinding: dit is het moment om een nieuw Postgres-proces op te starten en de status ervan te herstellen, zelfs voordat het eerste verzoek wordt uitgevoerd.
De term komt in grote lijnen uit serverless computing, waarbij een op nul gebaseerde uitvoeringsomgeving opnieuw moet opstarten voordat een verzoek wordt verwerkt, of het nu een serverfunctie is of een WebAssembly-runtime aan de rand. We beschrijven dit mechanisme aan de kant van de randfuncties in ons artikel over koude start WebAssembly tegenovercontainers. Voor een database zijn de mechanismen verschillend: het is niet een gecompileerd binair bestand dat start, maar een complete Postgres-server die de bestanden moet heropenen, de status ervan moet valideren en vervolgens nieuwe verbindingen moet accepteren.
1. Klantaanmelding
Er komt een aanvraag binnen voor een project waarvan de rekenkracht is opgeschort.
2. Slaapdetectie
Het platform merkt dat de rekenkracht niet langer actief is.
3. De computer opnieuw starten
Het Postgres-proces wordt opnieuw gestart, de noodzakelijke status wordt hersteld.
4. Aanvraag verwerkt
De verbinding is succesvol, het verzoek wordt normaal uitgevoerd.
Illustratie van het koudestartmechanisme, vereenvoudigde volgorde, zonder gemeten tijdswaarde.
Waarom Neon zijn computer in de slaapstand zet, en in welk tempo
Neon verdeelt zijn databasearchitectuur in twee verschillende lagen: permanente opslag die de gegevens bewaart, en rekenkracht, het Postgres-proces zelf, dat onafhankelijk kan worden gestopt en opnieuw gestart. Door deze scheiding kan Neon de rekenkracht van een inactief project opschorten zonder de gegevens aan te raken, en het vervolgens op verzoek opnieuw opstarten, volgens de officiële documentatie.
Bij het gratis abonnement documenteert Neon een standaard inactiviteitstime-out van 5 minuten voordat de computer in de sluimerstand wordt gezet. Met betaalde abonnementen kunt u deze drempel configureren of zelfs aanzienlijk verhogen voor gebruik met constant verkeer. Dit type standaard verandert met productupdates: controleer de Neon-documentatie up-to-date op het moment van lezen in plaats van dit geïsoleerde cijfer.
Dit ontwerp dient een specifiek doel, kortstondige omgevingen. Een database per Git-branch, een preview-omgeving via pull-request, een testdatabase die slechts een paar minuten per dag wordt gebruikt: het continu draaien van een computer voor dit gebruik is duur en levert geen echt voordeel op. Door de rekenkracht tussen twee toepassingen op te schorten, wordt de rekening verlaagd zonder dat de gegevens worden verwijderd. Dit is het centrale argument van het serverloze model van Neon.
Hoe lang gaat een Neon wekker mee en hoe controleer je dit zelf?
Neon geeft in de documentatie aan dat de computer opnieuw moet worden opgestart, doorgaans in de orde van een paar honderd milliseconden tot een paar seconden, afhankelijk van de grootte van het project en het aantal transactielogboeken dat moet worden afgespeeld voordat de computer gereed is. Dit is een cijfer dat door de uitgever zelf is gepubliceerd, en geen onafhankelijke audit: behandel het als een gedocumenteerde orde van grootte, niet als een contractuele garantie.
Voor metingen in de echte wereld peilt een openbare gemeenschapstool, neon-latency-benchmarks.vercel.app, met regelmatige tussenpozen opgeschorte Neon-projecten en geeft de waargenomen ontwaaklatentie weer. Dit is het type methodologie dat belangrijker is dan een naakt documentatiecijfer: de testomstandigheden blijven zichtbaar en niet verborgen achter een marketinggemiddelde. We passen hetzelfde principe toe in onze eigen backend benchmark-methodologie: publiceer het protocol voordat u een cijfer publiceert.
| Projectgrootte | Meer relaties en WAL-volume om te valideren maken de herstart langer. |
|---|---|
| Regio en netwerkafstand | Verhoogt de verbindingslatentie, onafhankelijk van de koude start zelf. |
| Prijsplan | Met betaalde abonnementen kunt u de inactiviteitsdrempel configureren of verlengen. |
| Frequentie van verbindingen | Een computer die regelmatig wordt aangevraagd, ervaart deze vertraging nooit. |
Vercel Postgres en Neon: dezelfde motor onder een ander merk?
Vercel heeft zijn Postgres-databaseaanbod gebouwd op basis van de Neon-infrastructuur, een partnerschap dat in 2024 openbaar werd gemaakt. Op het moment van schrijven wordt deze Postgres-integratie in de Vercel Marketplace aangeboden als opslagoptie naast andere providers. Bekijk de vernieuwde Vercel-productpagina: dit soort samenwerking evolueert snel in een markt die elk kwartaal verandert.
Concreet volgt het slaap- en ontwaakgedrag van een Postgres-database die via Vercel wordt ingericht hetzelfde mechanisme als hierboven beschreven voor Neon rechtstreeks. Het is geen aparte motor met een eigen koudestartmodel, het is dezelfde infrastructuur die achter een Vercel-integratie wordt blootgelegd.
Heeft Supabase een vergelijkbare koude start?
Nee, niet op dezelfde manier. Supabase voorziet in een speciale Postgres-instantie per project in plaats van een serverloze rekenkracht die per verbinding wordt opgeschort. Er wordt dus geen wekvertraging toegevoegd aan elke nieuwe sessie na een paar minuten inactiviteit, in tegenstelling tot het Neon-model.
Er bestaat echter een ander mechanisme bij het gratis abonnement: Supabase documenteert een automatische pauze van inactieve projecten na een langere periode, in de orde van grootte van een week volgens de documentatie, met handmatig herstel vanaf het dashboard in plaats van een automatisch ontwaken op het eerste verzoek. Het is een drempel gemeten in dagen, niet in minuten, en een expliciete actie in plaats van een transparant herstel: twee structurele verschillen met de koude start van Neon, niet een simpele variatie op hetzelfde mechanisme. Voor een volledige architectuurvergelijking documenteert onze gedetailleerde Aurabase versus Supabase vergelijking andere discrepanties.
En het Aurabase-model: waarom de vergelijking niet geldt zoals ze is
Aurabase biedt geen serverloos model zoals Neon. Geverifieerd in de provisionercode (aura-provisioner, open source op github.com/daylami555/aurabase): elk project ontvangt een speciaal Postgres-cluster beheerd door CloudNativePG, de Kubernetes CNPG-operator, of een speciale basis op een CNPG-cluster dat wordt gedeeld tussen verschillende projecten van dezelfde organisatie, afhankelijk van het gekozen plan. In beide gevallen is het niet één enkele computer die bij elke verbinding opschort en ontwaakt: het is een compleet Postgres-cluster, met primaire en mogelijke replica's.
Aan de Aurabase-kant bestaat er wel een slaapstandmechanisme, maar het dient een ander doel. Bij langdurige inactiviteit, standaard 7 dagen en configureerbaar via een omgevingsvariabele, drempelwaarde geverifieerd in de code, zet de provisioner inactieve instanties in de sluimerstand om bronnen vrij te maken, niet om de latentie van intermitterend gebruik te optimaliseren. Door een slapend CNPG-cluster wakker te maken, worden de pods opnieuw gemaakt van persistente volumes, een structureel zwaarder mechanisme dan een eenvoudige serverloze herstart van processen.
Aurabase heeft tot nu toe geen cijfers over de ontwaaklatentie vrijgegeven, noch om een snelle ontwaaktijd te claimen, noch om deze te vergelijken met Neon. Het is niet hetzelfde product, en het zou oneerlijk zijn om het als zodanig door te geven zonder gepubliceerde afmetingen.
Deze specifieke architectuur heeft een directe tegenhanger in termen van isolatie en prestatievoorspelbaarheid: een project deelt zijn rekenkracht niet met een ander project, in tegenstelling tot een gedeeld cluster van geringe omvang. We beschrijven deze arbitrage in een speciaal artikel: dedicated versus gedeelde basis, echte impact op prestaties en isolatie.
Kies op basis van uw gebruiksscenario
Het Neon-serverloze model dient een specifiek gebruiksscenario: veel kortstondige omgevingen of omgevingen met zeer intermitterend verkeer, waar betalen voor een computer die continu draait economisch gezien niet zinvol is. Een database per Git-tak, een preview-omgeving via pull-request, een prototype dat een paar keer per week wordt getest: zo nu en dan een koude start wordt een acceptabel compromis tegen een factuur die proportioneel is aan het daadwerkelijke gebruik.
Omgekeerd krijgt een specifieke, altijd actieve Postgres-architectuur de voorkeur wanneer de latentie van de eerste verbinding voorspelbaar moet blijven: een productie-API met regelmatig verkeer, een backend die zich niet zo nu en dan een latentiepiek kan veroorloven op een gebruikersverzoek, of een systeem waarbij p99 belangrijker is dan de kosten van een geïsoleerde testvertakking.
| Leverancier | Rekenmodel | Slaaptrigger | Typische wekker |
|---|---|---|---|
| Neon | Serverloos computergebruik gescheiden van opslag | Inactiviteit, vanaf 5 min (gratis abonnement) | Automatisch, van minder dan een seconde tot seconden (geclaimde editor) |
| Vercel Postgres | Neon Infrastructuur (partnerschap) | Hetzelfde als Neon | Hetzelfde als Neon |
| Supabasis | Specifieke instantie per project | Langdurige inactiviteit, alleen gratis abonnement | Handmatig, herstellen vanaf dashboard |
| Aurabase | Toegewijd of gedeeld CNPG-cluster | Langdurige inactiviteit, standaard 7 dagen | Niet bedoeld als sub-seconde, niet gepubliceerd |
Neonwekker: orde van grootte gedocumenteerd door de uitgever, niet onafhankelijk gecontroleerd. Aurabase-slaapstanddrempel: gecontroleerd in aura-provisioner, variabele HIBERNATE_INACTIVITY_DAYS, standaard 7 dagen.
Veelgestelde vragen
Wat te onthouden
De serverloze koude start van Postgres is geen universeel concept: het is een direct gevolg van de Neon-architectuur, die opslag en berekening scheidt om de laatste tussen twee toepassingen op te schorten. Vercel Postgres erft het rechtstreeks via zijn partnerschap met Neon. Supabase en Aurabase, die speciale Postgres-instanties leveren, leggen een ander mechanisme bloot, gemeten in dagen in plaats van minuten, en niet ontworpen voor hetzelfde doel.
Voordat u alleen op basis van dit criterium een provider kiest, moet u drie dingen controleren: de daadwerkelijke inactiviteitsdrempel die door de provider is gedocumenteerd, of deze in uw abonnement kan worden geconfigureerd en of uw applicatieverkeer een computeronderbreking rechtvaardigt. Voor gebruik met echt intermitterend verkeer, testvertakkingen of previews heeft het serverloze model een duidelijk economisch voordeel. Voor productie met regelmatig verkeer elimineert een speciale architectuur eenvoudigweg de vraag.