Che cos'è PostgreSQL serverless?

Serverless PostgreSQL (Postgres) è un modello di database cloud completamente gestito che disaccoppia le risorse di calcolo (compute) e di archiviazione (storage). Questo consente a ciascuna di esse di scalare in modo indipendente e automatico in base alla domanda. Invece di gestire direttamente i server di database, le applicazioni interagiscono con sistemi che allocano automaticamente le risorse di calcolo in risposta al carico di lavoro, ridimensionandole quando sono inattive.

Al contrario, negli ambienti Postgres tradizionali, i team devono dimensionare l'infrastruttura in anticipo, stimare i requisiti di capacità e gestire la scalabilità nel tempo. Ciò si traduce spesso in un sovradimensionamento (overprovisioning), nello spreco di costi per risorse inattive e in colli di bottiglia delle prestazioni quando la domanda supera la capacità disponibile.

Serverless Postgres elimina gran parte di questo sovraccarico operativo:

• Eliminando il provisioning dei server e la gestione dell'infrastruttura
• Rimuovendo la necessità di una pianificazione manuale della capacità
• Addebitando i costi solo per l'utilizzo attivo anziché per le risorse di calcolo inattive

Il termine "serverless" può essere fuorviante, poiché non significa che le applicazioni vengano eseguite senza server o infrastruttura. I sistemi sottostanti esistono ancora, ma sono astratti e completamente gestiti dal cloud provider. Attività come la configurazione dei server, la scalabilità e la manutenzione sono in gran parte invisibili agli utenti e non devono essere configurate o gestite direttamente.

PostgreSQL tradizionale vs. serverless

Le architetture PostgreSQL si sono evolute nel tempo, passando da modelli di infrastruttura con provisioning a progetti più dinamici e nativi del cloud.

Le distribuzioni di Postgres tradizionale eseguono continuamente risorse di calcolo fisse, indipendentemente dal carico di lavoro. La scalabilità richiede un intervento manuale o soglie preconfigurate, con costi sempre attivi anche quando il database è inattivo.

Serverless Postgres ha introdotto un modello diverso. Le risorse di calcolo vengono allocate su richiesta, scalando automaticamente con l'attività del carico di lavoro e riducendosi a zero quando non sono in uso. La fatturazione si basa sul consumo effettivo anziché sulla capacità riservata.

Serverless Postgres può essere utilizzato anche insieme a piattaforme di calcolo serverless come Databricks SQL, consentendo l'esecuzione indipendente di query analitiche pur continuando ad accedere agli stessi dati sottostanti all'interno di un'architettura lakehouse unificata.

Questo cambiamento è reso possibile da evoluzioni architetturali come i livelli di archiviazione disaccoppiati e l'orchestrazione del calcolo su richiesta, che consentono alle risorse di scalare in modo indipendente e di rispondere dinamicamente all'attività del carico di lavoro.

Le differenze principali includono:

La prossima evoluzione: l'architettura lakebase

Con l'evolversi delle architetture di database, sta emergendo un terzo modello che si basa su serverless Postgres affrontandone al contempo i limiti. Questo approccio viene talvolta definito architettura lakebase.

Serverless Postgres migliora la scalabilità e riduce il sovraccarico operativo, ma in genere rimane separato dai sistemi analitici. Questa separazione richiede spesso lo spostamento, la duplicazione o la sincronizzazione dei dati tra i database operativi e le piattaforme di analisi.

Le architetture lakebase stanno cambiando il modo in cui pensiamo all'archiviazione e all'elaborazione dei dati. Combinano la potenza dei database transazionali con la flessibilità di una base lakehouse, creando un'unica piattaforma in cui i carichi di lavoro operativi e analitici possono essere eseguiti insieme. Ciò significa che invece di avere sistemi separati per compiti diversi, tutto può essere fatto su un'unica piattaforma dati condivisa. Il risultato è una minore duplicazione dei dati e un modo molto più semplice di accedere e utilizzare i dati. Riunendo tutto, le architetture lakebase semplificano la gestione e l'analisi dei dati, il che può portare a decisioni migliori e a operazioni più efficienti.

Come funziona l'architettura lakebase

Le architetture lakebase si basano sui pattern di serverless Postgres introducendo al contempo una maggiore integrazione con lo storage cloud e le piattaforme dati.

I componenti chiave includono:

• Risorse di calcolo e archiviazione disaccoppiate
  Il calcolo è stateless e scala in modo indipendente, mentre l'archiviazione rimane persistente e distribuita.
• Risorse di calcolo temporanee
  Le risorse di calcolo si attivano per elaborare le query e si riducono quando sono inattive, consentendo l'elasticità senza mantenere un'infrastruttura sempre attiva.
• Sistemi di archiviazione basati su log
  Le modifiche ai dati vengono acquisite come un log continuo, che può essere utilizzato per ricostruire lo stato del database e supportare funzionalità come branching, ripristino e accesso basato sul tempo.
• Object storage come base
  I dati durevoli sono archiviati in un object storage cloud, consentendo scalabilità, durabilità e allineamento con le architetture lakehouse.
• Control plane e orchestrazione
  Un livello di controllo gestisce la scalabilità, il routing e gli eventi del ciclo di vita, coordinando dinamicamente calcolo e archiviazione.

Perché è importante

Combinando funzionalità transazionali e analitiche su una base condivisa, le architetture lakebase possono:

• Ridurre o eliminare la duplicazione dei dati tra i sistemi
• Abilitare l'analisi quasi in tempo reale sui dati operativi
• Semplificare l'architettura dei dati consolidando l'infrastruttura
• Supportare i carichi di lavoro emergenti, comprese le applicazioni di AI che richiedono un accesso sia transazionale che analitico

Questo cambiamento riflette il passaggio dall'ottimizzazione dei singoli sistemi alla loro unificazione all'interno di un'unica architettura dati.

Come funziona l'architettura serverless Postgres

Serverless Postgres si basa su un'architettura nativa del cloud che separa le risorse di calcolo e di archiviazione in livelli indipendenti. Questo principio di progettazione fondamentale migliora l'efficienza e la flessibilità consentendo a ciascun componente di scalare in modo indipendente.

Una caratteristica chiave di questa architettura è il comportamento "scale-to-zero" (scalabilità a zero). Quando non ci sono query in esecuzione, il sistema sospende automaticamente le risorse di calcolo. Quando viene inviata una nuova query, il calcolo viene riattivato. Questo introduce un breve ritardo noto come latenza di avvio a freddo (cold start), che può variare da millisecondi a diversi secondi a seconda del provider e della configurazione.

Un'altra importante funzionalità è il branching del database, spesso implementato utilizzando tecniche copy-on-write. Il branching consente ai team di creare ambienti di database isolati per lo sviluppo, il test o lo staging senza duplicare i dati. Le modifiche apportate in un branch non influiscono sul database originale, consentendo iterazioni più rapide e una sperimentazione più sicura.

I principali provider di serverless Postgres

Le offerte di serverless Postgres riflettono diverse fasi dell'evoluzione dai database con provisioning ad architetture completamente native del cloud. I primi servizi gestiti hanno introdotto la scalabilità automatica all'interno delle architetture di database esistenti. I progetti nativi del cloud più recenti sono creati per supportare agenti di AI, applicazioni in tempo reale e carichi di lavoro operativi moderni. Questi sistemi disaccoppiano completamente calcolo e archiviazione e introducono funzionalità difficili da ottenere nei modelli precedenti, come la scalabilità rapida, il branching e una gestione delle risorse più flessibile. Neon e Databricks Lakebase si basano su queste fondamenta, progettati per le esigenze delle applicazioni orientate all'AI e dei sistemi basati su agenti.

• Databricks Lakebase
  Un database operativo basato sull'architettura lakebase che estende serverless Postgres integrando database transazionali con una base lakehouse. Progettato per le esigenze degli agenti di AI, delle applicazioni in tempo reale e dei moderni carichi di lavoro operativi, Databricks Lakebase consente ai carichi di lavoro operativi e analitici di condividere una piattaforma dati comune. I casi d'uso includono la memorizzazione dello stato degli agenti di AI, l'alimentazione di applicazioni transazionali e la fornitura di insight analitici direttamente in app e flussi di lavoro. Il risultato è un minor movimento di dati e un accesso più coerente tra i vari casi d'uso.
• Amazon Aurora Serverless v2
  Un servizio gestito compatibile con Postgres all'interno di AWS che fornisce un autoscaling granulare senza richiedere il riavvio del database. Aurora Serverless v2 è progettato per carichi di lavoro aziendali e si integra strettamente con i servizi AWS per la rete, la sicurezza e il monitoraggio. Sebbene riduca il sovraccarico operativo, il comportamento di scalabilità e l'isolamento delle risorse potrebbero riflettere ancora i vincoli dell'infrastruttura sottostante.
• Neon
  Un'architettura lakebase basata su un modello di elaborazione e archiviazione completamente disaccoppiato con storage basato su log. Neon supporta il ridimensionamento a zero e il branching del database, consentendo una creazione rapida degli ambienti e flussi di lavoro di sviluppo più dinamici.

Per i carichi di lavoro di analisi e data processing, l'elaborazione serverless è disponibile anche in piattaforme come Databricks SQL. Pur non essendo un database transazionale (OLTP), questi sistemi offrono l'esecuzione di query serverless per l'analisi e possono operare insieme a sistemi basati su Postgres.

Radici open-source e opzioni cloud-native

Postgres è un sistema di database relazionale open-source ampiamente utilizzato. Le offerte Postgres serverless sono create su questa base e mantengono la piena compatibilità con il più ampio ecosistema Postgres, che include estensioni, strumenti da riga di comando come psql, ORM comuni e altro ancora.

Le implementazioni differiscono in base a quanto il sistema sottostante sia aperto o proprietario. Alcuni provider, come Neon, sono basati su un'infrastruttura open-source e mostrano una parte maggiore della loro architettura alla community. Altri, come Amazon Aurora Serverless, sono servizi gestiti proprietari che astraggono gran parte dell'implementazione sottostante.

Indipendentemente dall'approccio, la maggior parte delle soluzioni Postgres serverless mira a mantenere la piena compatibilità con Postgres, aggiungendo al contempo funzionalità cloud-native come la scalabilità automatica, il branching del database e le operazioni gestite.

Queste differenze possono influenzare il livello di visibilità e controllo che i team hanno su prestazioni e costi. I sistemi basati su open-source possono offrire maggiore trasparenza e flessibilità, mentre i servizi gestiti proprietari spesso danno priorità alla facilità d'uso e alla semplicità operativa.

Modelli di prezzo e compromessi sulle prestazioni

Quando si valuta Postgres serverless per i carichi di lavoro di produzione, è importante comprendere come i modelli di prezzo e le caratteristiche prestazionali influenzino i costi, la latenza e il comportamento generale del sistema.

Prezzi basati sul consumo: cosa stai effettivamente pagando

La maggior parte dei provider Postgres serverless addebita i costi in base a tre dimensioni principali:

• Compute: in genere misurato in base alle risorse utilizzate durante l'esecuzione delle query, come il tempo di vCPU o i secondi di ACU
• Storage: fatturato in base alla quantità di dati archiviati, solitamente in GB al mese
• Trasferimento dati: costi per lo spostamento dei dati in entrata e in uscita dal database, a seconda della regione e della configurazione di rete

Poiché le risorse di calcolo vengono allocate su richiesta, i costi variano in base all'attività del carico di lavoro. Ciò rende i prezzi serverless particolarmente adatti per applicazioni con traffico variabile o imprevedibile.

Molti provider offrono piani gratuiti utili per lo sviluppo, i test e i carichi di lavoro su piccola scala. Questi piani in genere includono limiti sull'uso delle risorse di calcolo, sullo storage o sul runtime attivo, il che li rende meno adatti per carichi di lavoro di produzione o applicazioni con traffico costante.

Sebbene i prezzi serverless possano essere efficienti per carichi di lavoro variabili, non rappresentano sempre l'opzione più economica. In caso di carichi di lavoro ad alto traffico, sempre attivi o query a esecuzione prolungata, i costi totali possono superare quelli di un'istanza di database con capacità allocata fissa.

Cold start, scalabilità e affidabilità in produzione

Una delle principali considerazioni sulle prestazioni in Postgres serverless è la latenza di cold start. Quando un database è stato ridimensionato a zero, le risorse di calcolo devono essere riattivate prima che le query possano essere eseguite. Ciò introduce un ritardo che può variare da circa 100 millisecondi a diversi secondi, a seconda del provider e della configurazione.

Diverse opzioni di mitigazione possono ridurre l'impatto dei cold start:

• Invio di ping periodici "keep-alive" per evitare la sospensione completa
• Configurazione di una soglia minima di calcolo per mantenere le risorse parzialmente attive
• Scelta di provider che riducono al minimo o eliminano i cold start grazie al design architetturale

I sistemi serverless si affidano anche alla scalabilità automatica per gestire la variazione dei carichi di lavoro. Le risorse di calcolo possono scalare verso l'alto in risposta all'aumento del volume delle query e, in alcuni casi, scalare le repliche di lettura in modo indipendente per supportare l'accesso simultaneo. Questa elasticità è particolarmente utile per le applicazioni con picchi di traffico imprevedibili.

Per i carichi di lavoro di produzione, la disponibilità e la tolleranza ai guasti sono considerazioni critiche. La maggior parte dei provider Postgres serverless gestiti replica i dati su più zone di disponibilità e offre funzionalità integrate di backup e ripristino. Tuttavia, le garanzie sul livello di servizio e il comportamento di ripristino variano a seconda del provider, quindi è importante esaminare e verificare la copertura SLA prima dell'uso in produzione.

Funzionalità come il comportamento di cold start e l'autoscaling rendono Postgres serverless particolarmente adatto a carichi di lavoro con traffico variabile, ma possono introdurre compromessi per le applicazioni sensibili alla latenza o sempre attive.

Casi d'uso e limitazioni di Postgres serverless

Postgres serverless e l'architettura lakebase rispondono a diverse esigenze di carico di lavoro. Comprendere quale modello si adatta al tuo caso d'uso può aiutare a evitare complessità e costi non necessari.

Le seguenti linee guida possono aiutare a determinare se Postgres serverless o l'architettura lakebase sia la soluzione ideale per il tuo carico di lavoro.

Ideale per Postgres serverless

• La maggior parte dei carichi di lavoro OLTP

Ideale per l'architettura lakebase:

• Sviluppo e deployment di agenti IA
• Carichi di lavoro variabili o con picchi improvvisi (bursty)
• Ambienti di sviluppo, test e staging
• Startup che ottimizzano i costi e riducono il sovraccarico operativo
• Applicazioni serverless o basate su edge
• Flussi di lavoro CI/CD con creazione rapida degli ambienti
• Applicazioni SaaS multi-tenant (branching e autoscaling)

Per i carichi di lavoro che richiedono prestazioni più costanti o disponibilità sempre attiva, l'architettura lakebase risponde a queste esigenze ripensando il modo in cui l'elaborazione e l'archiviazione sono coordinate su una piattaforma dati condivisa.

Come iniziare con Postgres serverless

Iniziare con Postgres serverless comporta in genere un processo di configurazione semplice:

1. Scegli un provider in base ai requisiti del tuo carico di lavoro, al comportamento di scalabilità e alle preferenze dell'ecosistema
2. Crea un'istanza di database tramite la console o l'API del provider
3. Configura una stringa di connessione con credenziali, regione e impostazioni di accesso
4. Connettiti utilizzando un client Postgres standard, un ORM o lo strumento da riga di comando psql

Sebbene la configurazione sia relativamente semplice, le scelte iniziali possono avere un impatto profondo sulle prestazioni complessive e sulla durabilità. Le considerazioni per il primo deployment dovrebbero includere:

• Impostazione di un livello minimo di calcolo se la latenza di cold start rappresenta un problema
• Configurazione di un connection pooler per gestire le connessioni simultanee in ambienti serverless o edge
• Abilitazione dei backup e del point-in-time recovery per proteggersi dalla perdita di dati
• Verifica delle impostazioni di scalabilità e timeout per assicurarsi che siano in linea con i pattern di traffico previsti

Postgres serverless può essere utilizzato insieme a piattaforme di elaborazione serverless come Databricks SQL per l'analisi e il data engineering. Questa separazione consente di eseguire query analitiche in modo indipendente dall'elaborazione transazionale, pur operando sugli stessi dati sottostanti.

Per i team che gestiscono dati operativi insieme all'analisi, le architetture emergenti come Databricks Lakebase estendono questo approccio unificando i carichi di lavoro transazionali e analitici su una piattaforma dati condivisa. Ciò riduce lo spostamento dei dati e semplifica l'accesso ai dati tra i sistemi.

L'architettura lakebase è il Postgres serverless adatto a te?

Postgres serverless semplifica le operazioni del database rimuovendo gran parte della gestione dell'infrastruttura e allineando i costi in modo più preciso all'utilizzo effettivo. Poiché l'elaborazione e l'archiviazione sono disaccoppiate, le risorse si adattano alla domanda. Per i team con carichi di lavoro più impegnativi, l'architettura lakebase estende ulteriormente questa base.

È importante valutare attentamente questi compromessi. La prevedibilità delle prestazioni, i costi su scala e fattori come la latenza di cold start e la gestione delle connessioni variano in base al carico di lavoro.

La scelta del provider è fondamentale. Le differenze nel comportamento di avvio a freddo, nei modelli di pricing, nella granularità di scalabilità e nell'integrazione con l'ecosistema possono influire in modo significativo sui risultati. Per i carichi di lavoro di analytics e data engineering, piattaforme come Databricks SQL offrono l'esecuzione di query serverless. I team possono anche scoprire come questo modello si estenda ai carichi di lavoro operativi tramite il tour del prodotto Databricks Lakebase.

Con la continua evoluzione delle architetture di database, l'architettura lakebase unifica i carichi di lavoro operativi e analitici su una base di dati condivisa.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale