Approfondimento del fornitore di cloud:PostgreSQL su AWS Aurora

Quanto in profondità dovremmo andare con questo? Inizierò dicendo che al momento della stesura di questo articolo, sono stato in grado di individuare solo 3 libri su Amazon su PostgreSQL nel cloud e 117 discussioni sulle mailing list di PostgreSQL su Aurora PostgreSQL. Non sembra molto e lascia a me, il curioso utente finale di PostgreSQL, la documentazione ufficiale come l'unico posto in cui potrei davvero imparare qualcosa in più. Dato che non ho la capacità, né la conoscenza per avventurarmi molto più a fondo, c'è AWS re:Invent 2018 per coloro che cercano quel tipo di brivido. Posso accontentarmi dell'articolo di Werner sui quorum.

Per riscaldarmi, sono partito dalla homepage di Aurora PostgreSQL dove ho notato che il benchmark che mostra che Aurora PostgreSQL è tre volte più veloce di un PostgreSQL standard in esecuzione sullo stesso hardware risale a PostgreSQL 9.6. Come ho appreso in seguito, 9.6.9 è attualmente l'opzione predefinita quando si configura un nuovo cluster. Questa è un'ottima notizia per coloro che non vogliono o non possono aggiornare immediatamente. E perché solo il 99,99% di disponibilità? Una spiegazione può essere trovata nell'articolo di Bruce Momjian.

Compatibilità

Secondo AWS, Aurora PostgreSQL è un sostituto drop-in di PostgreSQL e la documentazione afferma:

Il codice, gli strumenti e le applicazioni che utilizzi oggi con i database MySQL e PostgreSQL esistenti possono essere utilizzati con Aurora.

Ciò è rafforzato dalle FAQ di Aurora:

Significa che la maggior parte del codice, delle applicazioni, dei driver e degli strumenti che già utilizzi oggi con i tuoi database PostgreSQL possono essere utilizzati con Aurora con poche o nessuna modifica. Il motore di database Amazon Aurora è progettato per essere compatibile con i cavi con PostgreSQL 9.6 e 10 e supporta lo stesso set di estensioni PostgreSQL supportate con RDS per PostgreSQL 9.6 e 10, semplificando lo spostamento delle applicazioni tra i due motori.

"la maggior parte" nel testo precedente suggerisce che non esiste una garanzia del 100%, nel qual caso coloro che cercano certezza dovrebbero prendere in considerazione l'acquisto di supporto tecnico da AWS Professional Services o dai partner di Amazon Aurora. Come nota a margine, ho notato che nessuno dei provider di hosting professionali PostgreSQL che impiegano i contributori della community principale è in quell'elenco.

Dalla pagina delle FAQ di Aurora apprendiamo anche che Aurora PostgreSQL supporta le stesse estensioni di RDS, che a sua volta elenca la maggior parte delle estensioni della community e alcuni extra.

Concetti

Come parte di Amazon RDS, Aurora PostgreSQL include una propria terminologia:

• Cluster:un'istanza database primaria in modalità di lettura/scrittura e zero o più repliche Aurora. Il DB principale è spesso etichettato come Master in `AWS diagrams`_ o Writer nella Console AWS. Sulla base del diagramma di riferimento possiamo fare un'osservazione interessante:Aurora scrive tre volte. Poiché la latenza tra le AZ è in genere superiore a quella all'interno della stessa AZ, la transazione viene considerata impegnata non appena viene scritta sulla copia dei dati all'interno della stessa AZ, altrimenti la latenza e le potenziali interruzioni tra le AZ.
• Volume cluster:volume di archiviazione del database virtuale che si estende su più zone di disponibilità.
• URL Aurora:una coppia `host:porta`.
• Endpoint cluster:URL Aurora per il database primario. Esiste un endpoint cluster.
• Endpoint del lettore:URL Aurora per il set di repliche. Per fare un'analogia con DNS è un alias (CNAME). Le richieste di lettura sono bilanciate nel carico tra le repliche disponibili.
• Endpoint personalizzato:URL Aurora a un gruppo costituito da una o più istanze database.
• Endpoint istanza:URL Aurora a un'istanza database specifica.
• Versione Aurora:versione del prodotto restituita da `SELECT AURORA_VERSION();`.

Prestazioni e monitoraggio di PostgreSQL su AWS Aurora

Dimensioni

Aurora PostgreSQL applica una configurazione best guess basata sulla dimensione dell'istanza database e sulla capacità di archiviazione, lasciando un'ulteriore ottimizzazione del database tramite l'uso di gruppi di parametri database.

Quando selezioni l'istanza database, basa la tua selezione sul valore desiderato per max_connections.

Ridimensionamento

Aurora PostgreSQL offre ridimensionamento automatico e manuale. Il ridimensionamento orizzontale delle repliche di lettura è automatizzato tramite l'uso di metriche delle prestazioni. Il ridimensionamento verticale può essere automatizzato tramite le API.

Il ridimensionamento orizzontale porta offline per alcuni minuti durante la sostituzione del motore di calcolo e l'esecuzione di qualsiasi operazione di manutenzione (aggiornamenti, patch). Pertanto AWS consiglia di eseguire tali operazioni durante le finestre di manutenzione.

Il ridimensionamento in entrambe le direzioni è un gioco da ragazzi:

A livello di archiviazione, lo spazio viene aggiunto con incrementi di 10G. Lo spazio di archiviazione allocato non viene mai recuperato, vedi sotto per come affrontare questa limitazione.

Stoccaggio

Come accennato in precedenza, Aurora PostgreSQL è stata progettata per sfruttare i quorum al fine di migliorare la coerenza delle prestazioni.

Poiché lo storage sottostante è condiviso da tutte le istanze database all'interno dello stesso cluster, non sono necessarie scritture aggiuntive sui nodi standby. Inoltre, l'aggiunta o la rimozione di istanze database non modifica i dati sottostanti.

Mi chiedo cosa siano quegli IOs unità significano sulla bolletta mensile? Le FAQ di Aurora vengono nuovamente in soccorso per spiegare cos'è un IO è, nel contesto del monitoraggio e della fatturazione. Un I/O di lettura come l'equivalente di una pagina di database da 8 KiB letta e un I/O di scrittura come l'equivalente di 4 KiB scritti sul livello di archiviazione.

Alta concorrenza

Per sfruttare appieno il design ad alta concorrenza di Aurora, si consiglia di configurare le applicazioni per guidare un gran numero di query e transazioni simultanee.

Le applicazioni progettate per indirizzare le query di lettura e scrittura rispettivamente ai nodi del database standby e primario trarranno vantaggio dall'endpoint di replica del lettore Aurora PostgreSQL.

Le connessioni sono bilanciate nel carico tra le repliche di lettura.

Utilizzando gli endpoint personalizzati, le istanze del database con maggiore capacità possono essere raggruppate per eseguire un carico di lavoro intensivo come l'analisi.

Gli endpoint dell'istanza database possono essere utilizzati per il bilanciamento del carico a grana fine o il failover rapido.

Tieni presente che per consentire agli endpoint di lettura di bilanciare il carico delle singole query, ciascuna query deve essere inviata come una nuova connessione.

Memorizzazione nella cache

Aurora PostgreSQL utilizza una tecnica di Survivable Cache Warming che assicura che la data nella cache del buffer venga preservata, eliminando la necessità di ripopolare o riscaldare la cache dopo il riavvio del database.

Replica

Il tempo di ritardo della replica tra le repliche viene mantenuto entro millisecondi a una cifra. Sebbene non sia disponibile per PostgreSQL, è bene sapere che il ritardo di replica tra regioni viene mantenuto entro 10 secondi di millisecondi.

Secondo la documentazione, il ritardo della replica aumenta durante i periodi di richieste di scrittura pesanti.

Piani di esecuzione delle query

Partendo dal presupposto che le prestazioni delle query diminuiscono nel tempo a causa di varie modifiche al database, il ruolo di questo componente Aurora PostgreSQL è quello di mantenere un elenco di piani di esecuzione delle query approvati o rifiutati.

I piani vengono approvati o rifiutati utilizzando metodi proattivi o reattivi.

Quando un piano di esecuzione viene contrassegnato come rifiutato, il piano di esecuzione della query sovrascrive le decisioni dell'ottimizzatore PostgreSQL e impedisce l'esecuzione del piano "cattivo".

Questa funzione richiede Aurora 2.1.0 o successiva.

Alta disponibilità e replica PostgreSQL su AWS Aurora

A livello di storage, Aurora PostgreSQL garantisce la durabilità replicando ogni 10 GB di volume di storage, sei volte su 3 AZ (ogni regione è composta in genere da 3 AZ) utilizzando la replica fisica sincrona. Ciò consente alle scritture del database di continuare a funzionare anche quando vengono perse 2 copie di dati. La disponibilità in lettura sopravvive alla perdita di 3 copie di dati.

Le repliche di lettura assicurano che un'istanza primaria non riuscita possa essere sostituita rapidamente promuovendo una delle 15 repliche disponibili. Quando si seleziona una distribuzione multi-AZ, viene creata automaticamente una replica di lettura. Il failover non richiede l'intervento dell'utente e le operazioni del database riprendono in meno di 30 secondi.

Per le distribuzioni single-AZ, la procedura di ripristino include un ripristino dall'ultimo backup valido noto. Secondo le FAQ di Aurora, il processo viene completato in meno di 15 minuti se il database deve essere ripristinato in una diversa AZ. La documentazione non è così specifica, affermando che occorrono meno di 10 minuti per completare il processo di ripristino.

Non è richiesta alcuna modifica sul lato applicazione per connettersi alla nuova istanza database poiché l'endpoint del cluster non cambia durante una promozione della replica o un ripristino dell'istanza.

Passaggio 1:elimina l'istanza primaria per forzare un failover:

Passaggio 2:failover automatico completato

Per i database occupati, il tempo di ripristino dopo un riavvio o un arresto anomalo è notevolmente ridotto poiché Aurora PostgreSQL non ha bisogno di riprodurre i registri delle transazioni.

Nell'ambito del servizio completamente gestito, i blocchi di dati e i dischi danneggiati vengono sostituiti automaticamente.

Il failover in presenza di repliche richiede fino a 120 secondi con un tempo spesso inferiore a 60 secondi. Tempi di ripristino più rapidi possono essere raggiunti quando le condizioni di failover sono predeterminate, nel qual caso alle repliche possono essere assegnate priorità di failover.

Aurora PostgreSQL funziona bene con Amazon RDS:un'istanza Aurora può fungere da replica di lettura per un'istanza RDS primaria.

Aurora PostgreSQL supporta la replica logica che, proprio come nella versione community, può essere utilizzata per superare i limiti di replica incorporati. Non c'è automazione o interfaccia della console AWS.

Sicurezza per PostgreSQL su AWS Aurora

A livello di rete, Aurora PostgreSQL sfrutta i componenti principali di AWS, il VPC per l'isolamento della rete cloud e i gruppi di sicurezza per il controllo dell'accesso alla rete.

Non c'è accesso come superutente. Durante la creazione di un cluster, Aurora PostgreSQL crea un account master con un sottoinsieme di autorizzazioni di superutente:

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

Per proteggere i dati in transito, Aurora PostgreSQL fornisce il supporto SSL/TLS nativo che può essere configurato per istanza database.

Tutti i dati inattivi possono essere crittografati con un impatto minimo sulle prestazioni. Questo vale anche per backup, snapshot e repliche.

L'autenticazione è controllata dalle policy IAM e il tagging consente un ulteriore controllo su ciò che gli utenti possono fare e su quali risorse.

Le chiamate API utilizzate da tutti i servizi cloud vengono registrate in CloudTrail.

La gestione delle password con restrizioni lato client è disponibile tramite il parametro rds.restrict_password_commands.

Backup e ripristino PostgreSQL su AWS Aurora

I backup sono abilitati per impostazione predefinita e non possono essere disabilitati. Forniscono un ripristino point-in-time utilizzando uno snapshot giornaliero completo come backup di base.

Il ripristino da un backup automatico presenta un paio di svantaggi:il tempo di ripristino può essere di diverse ore e la perdita di dati può arrivare fino a 5 minuti prima dell'interruzione. Le distribuzioni Amazon RDS Multi-AZ risolvono questo problema promuovendo una replica di lettura su primaria, senza perdita di dati.

Gli snapshot del database sono veloci e non influiscono sulle prestazioni del cluster. Possono essere copiati o condivisi con altri utenti.

Scattare uno snapshot è quasi istantaneo:

Anche il ripristino di uno snapshot è veloce. Confronta con PITR:

Backup e snapshot sono archiviati in S3, che offre undici 9 di durabilità.

Oltre a backup e snapshot, Aurora PostgreSQL consente la clonazione dei database. Questo è un metodo efficiente per creare copie di set di dati di grandi dimensioni. Ad esempio, la clonazione di più terabyte di dati richiede solo pochi minuti e non vi è alcun impatto sulle prestazioni.

Aurora PostgreSQL - Demo di ripristino point-in-time

Connessione al cluster:

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Popolare una tabella con i dati:

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

Avvia il ripristino:

Una volta completato il ripristino, accedi e controlla:

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

Migliori pratiche

Monitoraggio e controllo

• Integra i flussi di attività del database con il monitoraggio di terze parti per monitorare l'attività del database per la conformità e i requisiti normativi.
• Un servizio di database completamente gestito non significa mancanza di responsabilità:definisci le metriche per monitorare la CPU, la RAM, lo spazio su disco, la rete e le connessioni al database.
• Aurora PostgreSQL si integra con lo strumento di monitoraggio standard di AWS CloudWatch, oltre a fornire monitor aggiuntivi per Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication e anche per RDS Metrics che possono essere ulteriormente raggruppati per RDS Dimensions.
• Monitoraggio del carico medio delle sessioni attive del database per attesa per segni di sovraccarico delle connessioni, query SQL che necessitano di ottimizzazione, conflitto di risorse o una classe di istanza database sottodimensionata.
• Imposta le notifiche degli eventi.
• Configura i parametri del registro degli errori.
• Monitoraggio delle modifiche alla configurazione dei componenti del cluster di database:istanze, gruppi di sottoreti, snapshot, gruppi di sicurezza.

Replica

• Utilizza il partizionamento della tabella nativa per i carichi di lavoro che superano la classe massima dell'istanza database e la capacità di archiviazione

Crittografia

• Il database crittografato deve avere i backup abilitati per garantire il ripristino dei dati in caso di revoca della chiave di crittografia.

Conto principale

• Non utilizzare psql per modificare la password dell'utente principale.

Dimensioni

• Considera l'utilizzo di classi di istanza diverse in un cluster per ridurre i costi.

Gruppi di parametri

• Perfeziona utilizzando i gruppi di parametri per risparmiare $$$.

Demo dei gruppi di parametri

Impostazioni attuali:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

Crea un nuovo gruppo di parametri e imposta il nuovo valore a livello di cluster:

Associa il gruppo di parametri personalizzati al cluster:

Riavvia lo scrittore e controlla il valore:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)

• Imposta il fuso orario locale

Per impostazione predefinita, il fuso orario è in UTC:

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

Impostazione del nuovo fuso orario:

E poi controlla:

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Tieni presente che l'elenco dei valori di fuso orario accettati da Amazon Aurora non sono i set di fusi orari trovati in PostgreSQL a monte.

• Esamina i parametri dell'istanza che sono sovrascritti dai parametri del cluster
• Utilizzare lo strumento di confronto dei gruppi di parametri.

Istantanee

• Evita costi di archiviazione aggiuntivi condividendo gli snapshot con un altro account per consentire il ripristino nei rispettivi ambienti.

Manutenzione

• Modifica la finestra di manutenzione predefinita in base alla pianificazione dell'organizzazione.

Failover

• Migliora i tempi di ripristino configurando Cluster Cache Management.
• Riduci i valori keepalive TCP del kernel sul client e configura la cache DNS dell'applicazione e le stringhe di connessione TTL e PostgreSQL.

Attenzione al DBA!

Oltre alle limitazioni note, evita o tieni presente quanto segue:

Crittografia

• Una volta creato un database, lo stato di crittografia non può essere modificato.

Aurora senza server

• Al momento, la versione PostgreSQL di Aurora Serverless è disponibile solo in anteprima limitata.

Query parallela

• Amazon Parallel Query non è disponibile, sebbene la funzionalità con lo stesso nome sia disponibile da PostgreSQL 9.6.

Endpoint

Da Amazon Connection Management:

• 5 endpoint personalizzati per cluster
• I nomi degli endpoint personalizzati non possono superare i 63 caratteri
• I nomi degli endpoint del cluster sono univoci all'interno della stessa regione
• Come mostrato nello screenshot sopra (aurora-custom-endpoint-details) READER e QUALSIASI tipo di endpoint personalizzato non sono disponibili, usa la CLI
• Gli endpoint personalizzati non sono a conoscenza del fatto che le repliche diventino temporaneamente non disponibili

Replica

• Quando si promuove una replica a primaria, le connessioni tramite l'endpoint di lettura possono continuare a essere dirette per un breve periodo alla replica promossa.
• Le repliche in più regioni non sono supportate
• Sebbene sia stata rilasciata alla fine di novembre 2017, l'anteprima Amazon Aurora Multi-Master non è ancora disponibile per PostgreSQL
• Guarda il degrado delle prestazioni quando la replica logica è abilitata sul cluster.
• La replica logica richiede un motore PostgreSQL in esecuzione pubblicato 10.6 o successivo.

Stoccaggio

• Lo spazio di archiviazione allocato massimo non si riduce quando i dati vengono eliminati, né lo spazio viene recuperato mediante il ripristino dagli snapshot. L'unico modo per recuperare spazio è eseguire un dump logico in un nuovo cluster.

Backup e ripristino

• La conservazione dei backup non viene estesa durante l'arresto del cluster.
• Il periodo di conservazione massimo è di 35 giorni:utilizza gli snapshot manuali per un periodo di conservazione più lungo.
• ripristino point-in-time su un nuovo cluster di database.
• breve interruzione delle letture durante il failover sulle repliche.
• Gli scenari di ripristino di emergenza non sono disponibili in più regioni.

Istantanee

• Il ripristino da snapshot crea un nuovo endpoint (gli snapshot possono essere ripristinati solo su un nuovo cluster).
• Dopo il ripristino di uno snapshot, è necessario ricreare gli endpoint personalizzati.
• Il ripristino dalle istantanee reimposta il fuso orario locale su UTC.
• Il ripristino dagli snapshot non preserva i gruppi di sicurezza personalizzati.
• Gli snapshot possono essere condivisi con un massimo di 20 ID account AWS.
• Le istantanee non possono essere condivise tra regioni.
• Gli snapshot incrementali vengono sempre copiati come snapshot completi, tra regioni e all'interno della stessa regione.
• La copia di snapshot tra regioni non preserva i gruppi di parametri non predefiniti.

Fatturazione

• La fattura di 10 minuti si applica alle nuove istanze, nonché a seguito di una modifica della capacità (elaborazione o archiviazione).

Autenticazione

• L'utilizzo dell'autenticazione del database IAM impone un limite al numero di connessioni al secondo.
• L'account principale ha alcuni privilegi di superutente revocati.

Avvio e arresto

Dalla panoramica sull'arresto e l'avvio di un cluster di database Aurora:

• I cluster non possono essere lasciati interrotti a tempo indeterminato poiché vengono avviati automaticamente dopo 7 giorni.
• Le singole istanze database non possono essere arrestate.

Aggiornamenti

• Gli aggiornamenti delle versioni principali sul posto non sono supportati.
• La propagazione delle modifiche al gruppo di parametri sia per l'istanza database che per il cluster di database richiede almeno 5 minuti.

Clonazione

• 15 cloni per database (originale o copia).
• I cloni non vengono rimossi quando si elimina il database di origine.

Ridimensionamento

• Il ridimensionamento automatico richiede che tutte le repliche siano disponibili.
• Può esserci solo `una politica di scalabilità automatica`_ per metrica per cluster.
• Il ridimensionamento orizzontale dell'istanza database principale (classe di istanza) non è completamente automatico. Prima di ridimensionare il cluster, viene attivato un failover automatico su una delle repliche. Al termine del ridimensionamento, la nuova istanza deve essere promossa manualmente da lettore a scrittore:Nuova istanza rimasta in modalità lettore dopo la modifica della classe dell'istanza database.

Monitoraggio

• La pubblicazione dei log PostgreSQL su CloudWatch richiede una versione minima del motore di database 9.6.6 e 10.4.
• Solo alcune metriche Aurora sono disponibili nella console RDS e altre metriche hanno nomi e unità di misura diversi.
• Per impostazione predefinita, i log di monitoraggio avanzato vengono conservati in CloudWatch per 30 giorni.
• Le metriche di Cloudwatch e Enhanced Monitoring saranno diverse, poiché raccolgono dati dall'hypervisor e rispettivamente dall'agente in esecuzione sull'istanza.
• Performance Insights_ aggrega le metriche di tutti i database all'interno di un'istanza database.
• Le istruzioni SQL sono limitate a 500 caratteri se visualizzate con la CLI e l'API di AWS Performance Insights.

Migrazione

• Solo gli snapshot DB non crittografati RDS possono essere crittografati a riposo.
• Le migrazioni che utilizzano la tecnica Aurora Read Replica richiedono diverse ore per TiB.

Dimensioni

• La classe di istanza più piccola disponibile è db.t3.medium e la più grande db.r5.24xlarge. Per fare un confronto, il motore MySQL offre db.t2.small e db.t2.medium, tuttavia nessun db.r5.24xlarge nella gamma superiore.
• Il limite massimo di max_connections è 262.143.

Gestione del piano di query

• Le istruzioni all'interno delle funzioni PL/pgSQL non sono supportate.

Migrazione

Aurora PostgreSQL non fornisce servizi di migrazione diretta, ma l'attività viene scaricata su un prodotto AWS specializzato, ovvero AWS DMS.

Conclusione

Come sostituto drop-in completamente gestito per PostgreSQL upstream, Amazon Aurora PostgreSQL sfrutta le tecnologie che alimentano il cloud AWS per rimuovere la complessità richiesta per configurare servizi come scalabilità automatica, bilanciamento del carico delle query e dati di basso livello replica, backup incrementali e crittografia.

L'architettura e un approccio conservativo per l'aggiornamento del motore PostgreSQL forniscono le prestazioni e la stabilità che le organizzazioni di piccole e grandi dimensioni stanno cercando.

I limiti intrinseci sono solo una prova del fatto che la creazione di un Database as a Service su larga scala è un compito complesso, lasciando i provider di hosting PostgreSQL altamente specializzati con un mercato di nicchia a cui attingere.