Questo però non è un concetto universale. Supabase e Aurabase, che forniscono istanze Postgres dedicate, non espongono lo stesso meccanismo nello stesso modo. Questo articolo descrive in dettaglio ciò che Neon effettivamente documenta durante il suo avvio a freddo, come si confrontano Vercel Postgres e Supabase e dove si adatta il modello Aurabase, verificato direttamente nel codice del provisioner anziché dedotto da una pagina di marketing.
L'essenziale
- L'avvio a freddo serverless si riferisce al ritardo aggiunto quando un database sospeso deve riattivare il proprio calcolo prima di rispondere alla prima richiesta.
- Neon separa archiviazione e calcolo: il calcolo va in sospensione dopo un periodo di inattività documentato (5 minuti di default sul piano gratuito, configurabile sui piani a pagamento).
- Neon documenta un riavvio tipicamente dell'ordine di poche centinaia di millisecondi o pochi secondi, una cifra pubblicata dall'editore, misurabile in tempo reale tramite lo strumento della community neon-latency-benchmarks.vercel.app.
- Vercel Postgres si affida all'infrastruttura Neon: il comportamento di risveglio segue la stessa meccanica, sotto un marchio diverso.
- Supabase fornisce un database dedicato per progetto, senza avvio a freddo per connessione. Solo il piano gratuito mette in pausa i progetti inattivi, con ripristino manuale.
- Aurabase fornisce un database Postgres dedicato per progetto, cluster CNPG dedicato o base dedicata su un cluster condiviso: questo non è un modello serverless Neon, verificato nel codice del provisioner.
Che cos'è un avvio a freddo per un database Postgres serverless?
Un avvio a freddo si verifica quando il computer che esegue il database è stato messo in stato di sospensione per inattività e una nuova query deve essere riavviata prima dell'esecuzione. Questa non è la solita latenza di rete di una tipica connessione TCP/TLS: è il momento di avviare un nuovo processo Postgres e ripristinarne lo stato, anche prima che la prima richiesta inizi l'esecuzione.
Il termine deriva dal serverless computing in generale, in cui un ambiente di esecuzione azzerato deve essere riavviato prima di elaborare una richiesta, sia che si tratti di una funzione server o di un runtime WebAssembly sul perimetro. Descriviamo in dettaglio questo meccanismo dal lato delle funzioni edge nel nostro articolo su avvio a freddo WebAssembly rivolto ai contenitori. Per un database, la meccanica è diversa: non si avvia un binario compilato, ma un server Postgres completo che deve riaprire i suoi file, convalidare il suo stato, quindi accettare nuove connessioni.
1. Accesso cliente
Arriva una richiesta su un progetto il cui calcolo è sospeso.
2. Rilevamento del sonno
La piattaforma rileva che il calcolo non è più attivo.
3. Riavvio del calcolo
Il processo Postgres si riavvia, lo stato necessario viene ripristinato.
4. Richiesta elaborata
La connessione ha esito positivo, la richiesta viene eseguita normalmente.
Illustrazione del meccanismo di avviamento a freddo, sequenza semplificata, senza valore temporale misurato.
Perché Neon mette in stop il suo computer e a quale velocità
Neon separa l'architettura del database in due livelli distinti: archiviazione persistente che conserva i dati e calcolo del processo Postgres stesso, che può essere arrestato e riavviato in modo indipendente. Questa separazione consente a Neon di sospendere il calcolo di un progetto inattivo senza toccare i dati, quindi riavviarlo su richiesta, secondo la sua documentazione ufficiale.
Nel piano gratuito, Neon documenta un timeout di inattività predefinito di 5 minuti prima di mettere il computer in modalità di sospensione. I piani a pagamento ti consentono di configurare questa soglia o addirittura di aumentarla in modo significativo per l'utilizzo con traffico costante. Questo tipo di default cambia con gli aggiornamenti del prodotto: controlla la documentazione Neon aggiornata al momento della lettura piuttosto che questa figura isolata.
Questo design ha uno scopo specifico, ambienti effimeri. Un database per ramo Git, un ambiente di anteprima tramite richiesta pull, un database di test che viene utilizzato solo per pochi minuti al giorno: eseguire un calcolo in modo continuo per questi usi è costoso senza alcun vantaggio reale. Sospendere il calcolo tra due utilizzi riduce la bolletta senza cancellare i dati, questo è l'argomento centrale del modello serverless di Neon.
Quanto dura una sveglia al neon e come controllarla tu stesso
Neon indica nella sua documentazione un riavvio del calcolo in genere dell'ordine di poche centinaia di millisecondi fino a pochi secondi, a seconda delle dimensioni del progetto e del volume dei log delle transazioni da riprodurre prima che il calcolo sia pronto. Si tratta di un dato pubblicato dall'editore stesso, non di un audit indipendente: trattatelo come un ordine di grandezza documentato, non come una garanzia contrattuale.
Per la misurazione nel mondo reale, uno strumento della community pubblica, neon-latency-benchmarks.vercel.app, esegue sondaggi sui progetti Neon sospesi a intervalli regolari e visualizza la latenza di riattivazione osservata. Questo è il tipo di metodologia che conta più di una semplice documentazione: le condizioni del test rimangono visibili, non nascoste dietro una media di marketing. Applichiamo lo stesso principio nella nostra metodologia di benchmark backend : pubblicare il protocollo prima di pubblicare una figura.
| Dimensioni del progetto | Più relazioni e volume WAL da convalidare rendono il riavvio più lungo. |
|---|---|
| Regione e distanza di rete | Aggiunge alla latenza della connessione, indipendentemente dall'avvio a freddo stesso. |
| Piano tariffario | I piani a pagamento ti consentono di configurare o estendere la soglia di inattività. |
| Frequenza delle connessioni | Un calcolo che rimane richiesto regolarmente non subisce mai questo ritardo. |
Vercel Postgres e Neon: lo stesso motore sotto un altro marchio?
Vercel ha costruito la sua offerta di database Postgres basata sull'infrastruttura Neon, una partnership resa pubblica nel 2024. Al momento in cui scrivo, questa integrazione Postgres è offerta nel Marketplace Vercel come opzione di archiviazione insieme ad altri fornitori. Controlla la pagina prodotto Vercel aggiornata: questo tipo di partnership si evolve rapidamente in un mercato che cambia ogni trimestre.
Concretamente, il comportamento di sonno e risveglio di un database Postgres fornito tramite Vercel segue direttamente la stessa meccanica descritta sopra per Neon. Non è un motore separato con un proprio modello di avvio a freddo, è la stessa infrastruttura esposta dietro un'integrazione Vercel.
Supabase ha un avvio a freddo paragonabile?
No, non allo stesso modo. Supabase fornisce un'istanza Postgres dedicata per progetto anziché un'elaborazione serverless sospesa per connessione. Non viene quindi aggiunto alcun ritardo di risveglio ad ogni nuova sessione dopo qualche minuto di inattività, a differenza del modello Neon.
Un meccanismo diverso, tuttavia, esiste nel piano gratuito: Supabase documenta una pausa automatica dei progetti inattivi dopo un periodo prolungato, dell'ordine di una settimana secondo la sua documentazione, con ripristino manuale dalla dashboard anziché un risveglio automatico alla prima richiesta. È una soglia misurata in giorni, non in minuti, e un'azione esplicita più che una ripresa trasparente: due differenze strutturali con l'avviamento a freddo del Neon, non una semplice variazione dello stesso meccanismo. Per un confronto completo dell'architettura, il nostro confronto dettagliato Aurabase vs Supabase documenta altre discrepanze.
E il modello Aurabase: perché il confronto non vale così com'è
Aurabase non offre un modello serverless come Neon. Verificato nel codice del provisioner (aura-provisioner, open source su github.com/daylami555/aurabase): ogni progetto riceve o un cluster Postgres dedicato gestito da CloudNativePG, l'operatore CNPG di Kubernetes, oppure una base dedicata su un cluster CNPG condiviso tra più progetti della stessa organizzazione, a seconda del piano scelto. In entrambi i casi, non si tratta di un singolo calcolo che si sospende e si riattiva ad ogni connessione: si tratta di un cluster Postgres completo, con repliche primarie e possibili.
Sul lato Aurabase esiste un meccanismo di ibernazione, ma ha uno scopo diverso. In caso di inattività prolungata, 7 giorni per impostazione predefinita e configurabile tramite una variabile d'ambiente, soglia verificata nel codice, il provisioner mette in modalità sleep le istanze inattive per liberare risorse, non per ottimizzare la latenza di utilizzo intermittente. Il risveglio di un cluster CNPG dormiente ricrea i suoi pod da volumi persistenti, un meccanismo strutturalmente più pesante di un semplice riavvio di un processo serverless.
Aurabase non ha rilasciato finora alcun dato sulla latenza di sveglia, né per affermare un tempo di sveglia veloce, né per confrontarlo con Neon. Non è lo stesso prodotto e sarebbe disonesto spacciarlo per tale senza le misurazioni pubblicate.
Questa architettura dedicata ha una controparte diretta in termini di isolamento e prevedibilità delle prestazioni: un progetto non condivide il proprio calcolo con un altro progetto, a differenza di un cluster condiviso di piccole dimensioni. Descriviamo in dettaglio questo arbitrato in un articolo dedicato: base dedicata vs condivisa, impatto reale su prestazioni e isolamento.
Scegli in base al tuo caso d'uso
Il modello serverless Neon serve un caso d'uso specifico: molti ambienti effimeri o ambienti con traffico molto intermittente, dove pagare per un computer che funziona continuamente non ha senso economico. Un database per ramo Git, un ambiente di anteprima tramite pull request, un prototipo testato qualche volta a settimana: il cold start occasionale diventa un compromesso accettabile a fronte di una fattura proporzionale all'effettivo utilizzo.
Al contrario, un'architettura Postgres dedicata e sempre attiva diventa preferibile ogni volta che la latenza della prima connessione deve rimanere prevedibile: un'API di produzione con traffico regolare, un backend che non può permettersi un picco di latenza occasionale su richiesta dell'utente o un sistema in cui p99 conta più del costo di un ramo di test isolato.
| Fornitore | Modello di calcolo | Trigger del sonno | Tipica sveglia |
|---|---|---|---|
| Neon | Elaborazione serverless separata dallo storage | Inattività, da 5 minuti (piano gratuito) | Automatico, da sub-secondi a secondi (editor dichiarato) |
| Vercel Postgres | Neon Infrastruttura (partnership) | Lo stesso di Neon | Lo stesso di Neon |
| Supabase | Ente dedicato per progetto | Inattività prolungata, solo piano gratuito | Manuale, ripristino dal dashboard |
| Aurabase | Cluster CNPG dedicato o condiviso | Inattività prolungata, 7 giorni per impostazione predefinita | Non inteso come sub-secondo, non pubblicato |
Sveglia al neon: ordine di grandezza documentato dall'editore, non sottoposto a verifica indipendente. Soglia di ibernazione Aurabase: controllata in aura-provisioner, variabile HIBERNATE_INACTIVITY_DAYS, valore predefinito 7 giorni.
Domande frequenti
Cosa ricordare
Il cold start serverless di Postgres non è un concetto universale: è una diretta conseguenza dell'architettura Neon, che separa storage e calcolo per sospendere quest'ultimo tra due utilizzi. Vercel Postgres lo eredita direttamente attraverso la partnership con Neon. Supabase e Aurabase, che forniscono istanze Postgres dedicate, espongono un meccanismo diverso, misurato in giorni anziché in minuti, non progettato per lo stesso scopo.
Prima di scegliere un fornitore solo in base a questo criterio, controlla tre cose: l'effettiva soglia di inattività documentata dal fornitore, se è configurabile sul tuo piano e se il traffico della tua applicazione giustifica la sospensione del calcolo. Per l'utilizzo con traffico intermittente reale, diramazioni di prova o anteprime, il modello serverless presenta un chiaro vantaggio economico. Per la produzione con traffico regolare, un'architettura dedicata elimina semplicemente il problema.