Cloud Vendor Deep-Dive:PostgreSQL på AWS Aurora

Hvor dybt skal vi gå med dette? Jeg vil starte med at sige, at når dette skrives, kunne jeg kun finde 3 bøger på Amazon om PostgreSQL i skyen og 117 diskussioner på PostgreSQL-mailinglister om Aurora PostgreSQL. Det ser ikke ud af meget, og det efterlader mig, den nysgerrige PostgreSQL-slutbruger, med den officielle dokumentation som det eneste sted, hvor jeg virkelig kunne lære noget mere. Da jeg ikke har evnen eller viden til at eventyre mig meget dybere, er der AWS re:Invent 2018 for dem, der leder efter den slags spænding. Jeg kan nøjes med Werners artikel om kvorummer.

For at blive varmet op startede jeg fra Aurora PostgreSQL-hjemmesiden, hvor jeg bemærkede, at benchmark, der viser, at Aurora PostgreSQL er tre gange hurtigere end en standard PostgreSQL, der kører på den samme hardware, går tilbage til PostgreSQL 9.6. Som jeg har lært senere, er 9.6.9 i øjeblikket standardindstillingen ved opsætning af en ny klynge. Det er meget gode nyheder for dem, der ikke vil eller ikke kan opgradere med det samme. Og hvorfor kun 99,99% tilgængelighed? En forklaring kan findes i Bruce Momjians artikel.

Kompatibilitet

Ifølge AWS er Aurora PostgreSQL en drop-in erstatning for PostgreSQL, og dokumentationen siger:

Koden, værktøjerne og applikationerne, du bruger i dag med dine eksisterende MySQL- og PostgreSQL-databaser, kan bruges med Aurora.

Det forstærkes af Aurora ofte stillede spørgsmål:

Det betyder, at det meste af den kode, applikationer, drivere og værktøjer, du allerede bruger i dag med dine PostgreSQL-databaser, kan bruges med Aurora med ringe eller ingen ændringer. Amazon Aurora-databasemotoren er designet til at være wire-kompatibel med PostgreSQL 9.6 og 10 og understøtter det samme sæt PostgreSQL-udvidelser, der understøttes med RDS til PostgreSQL 9.6 og 10, hvilket gør det nemt at flytte applikationer mellem de to motorer.

"de fleste" i ovenstående tekst tyder på, at der ikke er en 100 % garanti, i hvilket tilfælde de, der søger sikkerhed, bør overveje at købe teknisk support fra enten AWS Professional Services eller Aamazon Aurora-partnere. Som en sidebemærkning bemærkede jeg, at ingen af de professionelle PostgreSQL-hostingudbydere, der beskæftiger kernefællesskabsbidragydere, er på denne liste.

Fra siden med ofte stillede spørgsmål om Aurora lærer vi også, at Aurora PostgreSQL understøtter de samme udvidelser som RDS, som igen viser de fleste af fællesskabsudvidelserne og et par ekstramateriale.

Koncepter

Som en del af Amazon RDS kommer Aurora PostgreSQL med sin egen terminologi:

Klynge:En primær DB-instans i læse-/skrivetilstand og nul eller flere Aurora-replikaer. Den primære DB er ofte mærket som en Master i `AWS-diagrammer`_ eller Writer i AWS-konsollen. Ud fra referencediagrammet kan vi lave en interessant observation:Aurora skriver tre gange. Da latensen mellem AZ'erne typisk er højere end inden for samme AZ, anses transaktionen for at være begået, så snart den er skrevet på datakopien inden for samme AZ, ellers ventetiden og potentielle udfald mellem AZ'erne.
Klyngevolumen:Virtuel databaselagervolumen, der spænder over flere AZ'er.
Aurora URL:Et `host:port`-par.
Klyngeslutpunkt:Aurora-URL for den primære DB. Der er ét Cluster Endpoint.
Læserendepunkt:Aurora-URL for replikasættet. For at lave en analogi med DNS er det et alias (CNAME). Læseanmodninger er belastningsbalanceret mellem tilgængelige replikaer.
Tilpasset slutpunkt:Aurora URL til en gruppe bestående af en eller flere DB-instanser.
Forekomstslutpunkt:Aurora-URL til en specifik DB-instans.
Aurora-version:Produktversion returneret af `SELECT AURORA_VERSION();`.

PostgreSQL-ydelse og overvågning på AWS Aurora

Størrelse

Aurora PostgreSQL anvender en bedste gæt-konfiguration, som er baseret på DB-forekomststørrelsen og lagerkapaciteten, hvilket efterlader yderligere tuning til DBA ved brug af DB-parametergrupper.

Når du vælger DB-forekomsten, skal du basere dit valg på den ønskede værdi for max_connections.

Skalering

Aurora PostgreSQL har automatisk og manuel skalering. Horisontal skalering af læste replikaer automatiseres ved brug af ydeevnemålinger. Vertikal skalering kan automatiseres via API'er.

Horisontal skalering tager offline i et par minutter, mens den udskifter computeren og udfører vedligeholdelsesoperationer (opgraderinger, patching). Derfor anbefaler AWS at udføre sådanne operationer under vedligeholdelsesvinduer.

Skalering i begge retninger er en leg:

Lodret skalering:ændring af forekomstklasse

Horisontal skalering:tilføjelse af læserreplika.

På lagerniveau tilføjes plads i trin på 10G. Tildelt lagerplads genvindes aldrig. Se nedenfor for, hvordan du løser denne begrænsning.

Opbevaring

Som nævnt ovenfor blev Aurora PostgreSQL udviklet til at drage fordel af kvorummer for at forbedre præstationskonsistensen.

Da det underliggende lager deles af alle DB-instanser inden for samme klynge, kræves der ikke yderligere skrivninger på standby-knudepunkter. Tilføjelse eller fjernelse af DB-forekomster ændrer heller ikke de underliggende data.

Gad vide, hvad de IO'er enheder betyder på den månedlige regning? Aurora FAQs kommer til undsætning igen for at forklare, hvad en IO er i forbindelse med overvågning og fakturering. En Read IO som ækvivalent med en 8KiB databaseside læst, og en Write IO som ækvivalent med 4KiB skrevet til lagerlaget.

Høj samtidighed

For at drage fuld fordel af Auroras design med høj samtidighed, anbefales det, at applikationer konfigureres til at drive et stort antal samtidige forespørgsler og transaktioner.

Applikationer designet til at dirigere læse- og skriveforespørgsler til henholdsvis standby- og primære databasenoder vil drage fordel af Aurora PostgreSQL-læserreplika-slutpunkt.

Forbindelser er belastningsbalanceret mellem læste replikaer.

Ved at bruge brugerdefinerede slutpunkter kan databaseinstanser med mere kapacitet grupperes sammen for at køre en intensiv arbejdsbyrde, såsom analyse.

DB Instance Endpoints kan bruges til finkornet belastningsbalancering eller hurtig failover.

Bemærk, at for at Reader Endpoints kan indlæse individuelle forespørgsler, skal hver forespørgsel sendes som en ny forbindelse.

Caching

Aurora PostgreSQL bruger en Survivable Cache Warming-teknik, som sikrer, at datoen i buffercachen bevares, hvilket eliminerer behovet for genudfyldning eller opvarmning af cachen efter en databasegenstart.

Replikering

Replikationsforsinkelsestid mellem replikaer holdes inden for et enkelt ciffer millisekund. Selvom det ikke er tilgængeligt for PostgreSQL, er det godt at vide, at replikationsforsinkelse på tværs af regioner holdes inden for 10s af millisekunder.

Ifølge dokumentationen stiger replika-forsinkelsen i perioder med store skriveanmodninger.

Forespørgselsudførelsesplaner

Baseret på den antagelse, at forespørgselsydeevne forringes over tid på grund af forskellige databaseændringer, er denne Aurora PostgreSQL-komponents rolle at vedligeholde en liste over godkendte eller afviste forespørgselsudførelsesplaner.

Planer godkendes eller afvises ved hjælp af enten proaktive eller reaktive metoder.

Når en eksekveringsplan er markeret som afvist, tilsidesætter forespørgselsudførelsesplanen PostgreSQL-optimeringsbeslutningerne og forhindrer den "dårlige" plan i at blive eksekveret.

Denne funktion kræver Aurora 2.1.0 eller nyere.

PostgreSQL høj tilgængelighed og replikering på AWS Aurora

På lagerlaget sikrer Aurora PostgreSQL holdbarhed ved at replikere hver 10 GB lagervolumen seks gange på tværs af 3 AZ'er (hver region består typisk af 3 AZ'er) ved hjælp af fysisk synkron replikering. Det gør det muligt for databaseskrivninger at fortsætte med at fungere, selv når 2 kopier af data går tabt. Læs tilgængelighed overlever tabet af 3 kopier af data.

Læs replikaer sikrer, at en mislykket primær forekomst hurtigt kan erstattes ved at promovere en af de 15 tilgængelige replikaer. Når du vælger en multi-AZ-implementering, oprettes der automatisk én læst replika. Failover kræver ingen brugerindgriben, og databaseoperationer genoptages på mindre end 30 sekunder.

For enkelt-AZ-implementeringer inkluderer gendannelsesproceduren en gendannelse fra den sidst kendte gode backup. Ifølge Aurora FAQs afsluttes processen på under 15 minutter, hvis databasen skal gendannes i en anden AZ. Dokumentationen er ikke så specifik og hævder, at det tager mindre end 10 minutter at fuldføre gendannelsesprocessen.

Der kræves ingen ændring på applikationssiden for at oprette forbindelse til den nye DB-instans, da klyngeslutpunktet ikke ændres under en replika-promovering eller gendannelse af instanser.

Trin 1:slet den primære forekomst for at gennemtvinge en failover:

Automatisk failover Trin 1:slet primær

Trin 2:automatisk failover fuldført

Automatisk failover Trin 2:failover gennemført.

For travle databaser reduceres genoprettelsestiden efter en genstart eller nedbrud dramatisk, da Aurora PostgreSQL ikke behøver at afspille transaktionsloggene igen.

Som en del af fuld-administreret service udskiftes dårlige datablokke og diske automatisk.

Failover, når der findes replikaer, tager op til 120 sekunder, ofte under 60 sekunder. Hurtigere gendannelsestider kan opnås, når failover-betingelser er forudbestemt, i hvilket tilfælde replikaer kan tildeles failover-prioriteter.

Aurora PostgreSQL spiller godt med Amazon RDS – en Aurora-instans kan fungere som en læsereplika for en primær RDS-instans.

Aurora PostgreSQL understøtter logisk replikering, der ligesom i fællesskabsversionen kan bruges til at overvinde indbyggede replikeringsbegrænsninger. Der er ingen automatisering eller AWS-konsolgrænseflade.

Sikkerhed for PostgreSQL på AWS Aurora

På netværksniveau udnytter Aurora PostgreSQL AWS-kernekomponenter, VPC til cloud-netværksisolering og sikkerhedsgrupper til netværksadgangskontrol.

Der er ingen superbrugeradgang. Når du opretter en klynge, opretter Aurora PostgreSQL en masterkonto med et undersæt af superbrugertilladelser:

[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  |                 |

For at sikre data i transit, tilbyder Aurora PostgreSQL indbygget SSL/TLS-understøttelse, som kan konfigureres pr. DB-instans.

Alle data i hvile kan krypteres med minimal præstationspåvirkning. Dette gælder også for sikkerhedskopier, snapshots og replikaer.

Kryptering i hvile.

Godkendelse styres af IAM-politikker, og tagging giver mulighed for yderligere kontrol over, hvad brugere må gøre, og på hvilke ressourcer.

API-kald, der bruges af alle cloud-tjenester, logges i CloudTrail.

Begrænset adgangskodestyring på klientsiden er tilgængelig via parameteren rds.restrict_password_commands.

PostgreSQL backup og gendannelse på AWS Aurora

Sikkerhedskopier er aktiveret som standard og kan ikke deaktiveres. De giver punkt-i-tids-gendannelse ved hjælp af et fuldt dagligt øjebliksbillede som en basis backup.

Gendannelse fra en automatiseret sikkerhedskopi har et par ulemper:Gendannelsestiden kan være flere timer, og datatab kan være op til 5 minutter før afbrydelsen. Amazon RDS Multi-AZ-implementeringer løser dette problem ved at promovere en læsereplika til primær uden datatab.

Database-snapshots er hurtige og påvirker ikke klyngens ydeevne. De kan kopieres eller deles med andre brugere.

At tage et øjebliksbillede er næsten øjeblikkeligt:

Snapshottid.

Gendannelse af et snapshot er også hurtigt. Sammenlign med PITR:

Sikkerhedskopier og snapshots gemmes i S3, som tilbyder elleve 9'ere holdbarhed.

Bortset fra sikkerhedskopier og snapshots tillader Aurora PostgreSQL, at databaser klones. Dette er en effektiv metode til at lave kopier af store datasæt. For eksempel tager kloning af multi-terabytes af data kun minutter, og der er ingen præstationspåvirkning.

Aurora PostgreSQL - Point-in-Time Recovery Demo

Opretter forbindelse til klynge:

~ $ 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.

Udfyld en tabel med data:

[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)

Start gendannelsen:

Point-in-Time-gendannelse:start gendannelse.

Når gendannelsen er fuldført, skal du logge ind og kontrollere:

~ $ 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)

Bedste praksis

Overvågning og revision

Integrer databaseaktivitetsstrømme med tredjepartsovervågning for at overvåge databaseaktivitet for overholdelse og lovkrav.
En fuldt administreret databasetjeneste betyder ikke mangel på ansvar – definer målinger til at overvåge CPU, RAM, diskplads, netværk og databaseforbindelser.
Aurora PostgreSQL integreres med AWS-standardovervågningsværktøjet CloudWatch, samt leverer yderligere skærme til Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL-replikering og også til RDS-metrics, der kan grupperes yderligere efter RDS-dimensioner.
Overvåg gennemsnitlige aktive sessioner DB Indlæs af Vent for tegn på forbindelsesoverhead, SQL-forespørgsler, der skal tunes, ressourcekonflikt eller en understørrelse DB-instansklasse.
Konfigurer hændelsesmeddelelser.
Konfigurer fejllogparametre.
Overvåg konfigurationsændringer af databaseklyngekomponenter:forekomster, undernetgrupper, snapshots, sikkerhedsgrupper.

Replikering

Brug indbygget tabelpartitionering til arbejdsbelastninger, der overstiger den maksimale DB-instansklasse og lagerkapacitet

Kryptering

Krypteret database skal have sikkerhedskopier aktiveret for at sikre, at data kan gendannes i tilfælde af, at krypteringsnøglen tilbagekaldes.

Hovedkonto

Brug ikke psql til at ændre hovedbrugeradgangskoden.

Størrelse

Overvej at bruge forskellige instansklasser i en klynge for at reducere omkostningerne.

Parametergrupper

Finjuster ved hjælp af parametergrupper for at spare $$$.

Demo af parametergrupper

Aktuelle indstillinger:

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

Opret en ny parametergruppe og indstil den nye klynge brede værdi:

Opdatering af shared_buffers-klynge bred.

Knyt den tilpassede parametergruppe til klyngen:

Genstart forfatteren og kontroller værdien:

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

Indstil den lokale tidszone

Som standard er tidszonen i UTC:

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

Indstilling af den nye tidszone:

Konfiguration af tidszone

Og tjek derefter:

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

Bemærk, at listen over tidszoneværdier, der accepteres af Amazon Aurora, ikke er de tidszonesæt, der findes i opstrøms PostgreSQL.

Gennemgå forekomstparametre, der tilsidesættes af klyngeparametre
Brug værktøjet til sammenligning af parametergrupper.

Snapshots

Undgå yderligere lageromkostninger ved at dele øjebliksbillederne med andre konti for at tillade gendannelse i deres respektive miljøer.

Vedligeholdelse

Skift standardvedligeholdelsesvinduet i henhold til organisationens tidsplan.

Failover

Forbedre gendannelsestiden ved at konfigurere Cluster Cache Management.
Sænk kerne-TCP Keepalive-værdierne på klienten, og konfigurer applikationens DNS-cache og TTL- og PostgreSQL-forbindelsesstrenge.

DBA Pas på!

Ud over de kendte begrænsninger undgå eller vær opmærksom på følgende:

Kryptering

Når først en database er oprettet, kan krypteringstilstanden ikke ændres.

Aurora-serverløs

På nuværende tidspunkt er PostgreSQL-versionen af Aurora Serverless kun tilgængelig i begrænset forhåndsvisning.

Parallel forespørgsel

Amazon Parallel Query er ikke tilgængelig, selvom funktionen med samme navn er tilgængelig siden PostgreSQL 9.6.

Endpunkter

Fra Amazon Connection Management:

5 tilpassede slutpunkter pr. klynge
Tilpassede slutpunktnavne må ikke overstige 63 tegn
Klyngeslutpunktsnavne er unikke inden for samme region
Som det ses på ovenstående skærmbillede (aurora-custom-endpoint-details) READER og ALLE tilpassede slutpunktstyper er ikke tilgængelige, brug CLI
Tilpassede slutpunkter er ikke klar over, at replikaer bliver midlertidigt utilgængelige

Replikering

Når du promoverer en replika til Primary, kan forbindelser via Reader Endpoint fortsætte med at blive dirigeret i en kort periode til den promoverede replika.
Replikaer på tværs af regioner understøttes ikke
Mens den blev udgivet i slutningen af november 2017, er Amazon Aurora Multi-Master preview stadig ikke tilgængelig for PostgreSQL
Hold øje med ydeevneforringelse, når logisk replikering er aktiveret på klyngen.
Logisk replikering kræver en publiceret, kørende PostgreSQL-motor 10.6 eller nyere.

Opbevaring

Maksimal tildelt lagerplads formindskes ikke, når data slettes, og pladsen genvindes heller ikke ved gendannelse fra snapshots. Den eneste måde at genvinde plads på er ved at udføre en logisk dump ind i en ny klynge.

Sikkerhedskopiering og gendannelse

Opbevaring af sikkerhedskopier forlænges ikke, mens klyngen er stoppet.
Maksimal opbevaringsperiode er 35 dage – brug manuelle snapshots for en længere opbevaringsperiode.
punkt-i-tidsgendannelse gendanner til en ny DB-klynge.
kort afbrydelse af læsninger under failover til replikaer.
Scenarier for gendannelse efter katastrofe er ikke tilgængelige på tværs af regioner.

Snapshots

Gendannelse fra snapshot opretter et nyt slutpunkt (snapshots kan kun gendannes til en ny klynge).
Efter en snapshotgendannelse skal tilpassede slutpunkter genskabes.
Gendannelse fra snapshots nulstiller den lokale tidszone til UTC.
Gendannelse fra snapshots bevarer ikke de tilpassede sikkerhedsgrupper.
Snapshots kan deles med maksimalt 20 AWS-konto-id'er.
Snapshots kan ikke deles mellem regioner.
Inkrementelle snapshots kopieres altid som hele snapshots, mellem regioner og inden for samme region.
Kopiering af snapshots på tværs af regioner bevarer ikke ikke-standardparametergrupperne.

Fakturering

10 minutters regning gælder for nye tilfælde såvel som efter en kapacitetsændring (beregning eller lagring).

Godkendelse

Brug af IAM-databasegodkendelse pålægger en grænse for antallet af forbindelser pr. sekund.
Hovedkontoen har visse superbrugerrettigheder tilbagekaldt.

Start og stop

Fra oversigt over stop og stirring af en Aurora DB-klynge:

Klynger kan ikke efterlades stoppet på ubestemt tid, da de startes automatisk efter 7 dage.
Individuelle DB-instanser kan ikke stoppes.

Opgraderinger

Større versionsopgraderinger på stedet understøttes ikke.
Parametergruppeændringer for både DB-forekomst og DB-klynge tager mindst 5 minutter at udbrede.

Kloning

15 kloner pr. database (original eller kopi).
Kloner fjernes ikke, når kildedatabasen slettes.

Skalering

Automatisk skalering kræver, at alle replikaer er tilgængelige.
Der kan kun være `én auto-skaleringspolitik`_ pr. metric pr. klynge.
Horisontal skalering af den primære DB-instans (instansklasse) er ikke fuldautomatisk. Før skalering udløser klyngen en automatisk failover til en af replikaerne. Når skaleringen er fuldført, skal den nye forekomst manuelt forfremmes fra læser til forfatter:Ny forekomst tilbage i læsetilstand efter ændring af DB-forekomstklasse.

Overvågning

Udgivelse af PostgreSQL-logfiler til CloudWatch kræver en minimumsversion af databasemotoren på 9.6.6 og 10.4.
Kun nogle Aurora-målinger er tilgængelige i RDS-konsollen, og andre målinger har forskellige navne og måleenheder.
Som standard opbevares logfiler for udvidet overvågning i CloudWatch i 30 dage.
Cloudwatch og Enhanced Monitoring-metrics vil være forskellige, da de indsamler data fra hypervisoren og henholdsvis den agent, der kører på instansen.
Performance Insights_ samler metrics på tværs af alle databaser i en DB-instans.
SQL-sætninger er begrænset til 500 tegn, når de ses med AWS Performance Insights CLI og API.

Migrering

Kun RDS ukrypterede DB Snapshots kan krypteres i hvile.
Migrationer ved hjælp af Aurora Read Replica-teknikken tager flere timer pr. TiB.

Størrelse

Den mindste tilgængelige forekomstklasse er db.t3.medium og den største db.r5.24xlarge. Til sammenligning tilbyder MySQL-motoren db.t2.small og db.t2.medium, dog ingen db.r5.24xlarge i det øvre område.
max_connections øvre grænse er 262.143.

Forespørgselsplanstyring

Udsagn i PL/pgSQL-funktioner understøttes ikke.

Migrering

Aurora PostgreSQL leverer ikke direkte migreringstjenester, men opgaven overføres til et specialiseret AWS-produkt, nemlig AWS DMS.

Konklusion

Som en fuldt administreret drop-in-erstatning for opstrøms PostgreSQL, udnytter Amazon Aurora PostgreSQL de teknologier, der driver AWS-skyen til at fjerne den kompleksitet, der kræves til opsætning af tjenester såsom automatisk skalering, forespørgselsbelastningsbalancering, data på lavt niveau replikering, trinvise sikkerhedskopier og kryptering.

Arkitekturen og en konservativ tilgang til opgradering af PostgreSQL-motoren giver ydeevnen og stabiliteten, som organisationer fra små til store leder efter.

De iboende begrænsninger er blot et bevis på, at opbygning af en database som en tjeneste i stor skala er en kompleks opgave, der efterlader de højt specialiserede PostgreSQL-hostingudbydere med et nichemarked, de kan benytte sig af.