Next Steps with PGD
===================

Going further with your PGD cluster
-----------------------------------

Architecture
^^^^^^^^^^^^

In this quick start, we created a single region cluster of high
availability Postgres databases. This is the, Always On Single Location
architecture, one of a range of available PGD architectures. Other
architectures include Always On Multi-Location, with clusters in
multiple data centers working together, and variations of both with
witness nodes enhancing resilience. Read more in :ref:`Architectural options and performance <Architectural options and performance>`  .

Postgres versions
^^^^^^^^^^^^^^^^^

In this quick start, we deployed EDB Postgres Advanced Server (EPAS) to
the database nodes. PGD is able to deploy a three different kinds of
Postgres distributions, EPAS, EDB Postgres Extended Server and
open-source PostgreSQL. The selection of database affects PGD, offering
 :ref:`different capabilities <Choosing a Postgres distribution>`  dependant on server.

-  Open-source PostgreSQL does not support CAMO

-  EDB Postgres Extended Server supports CAMO, but does not offer Oracle
   compatibility

-  EDB Postgres Advanced Server supports CAMO and offers optional Oracle
   compatibility

Read On
^^^^^^^

-  Learn PGD’s :ref:`Terminology <Terminology>`  - from Asynchronous Replication to Write
   Scalability

-  Find out how :ref:`applications work <../appusage/>`  with PGD and how common Postgres features
   like :ref:`bdr.sequences <bdr.sequences>`  are globally distributed

-  Discover how PGD supports :ref:`rolling upgrades <../upgrades/>`  of your clusters

-  Take control of :ref:`Connection routing <Connection routing>`  and use SQL to control the PGD Proxies

-  Engage with the :ref:`Using PGD CLI <Using PGD CLI>`  to manage and monitor your cluster

Deprovisioning the cluster
--------------------------

When you’re done testing the cluster, you’ll want to deprovision it.

.. code:: shell

   tpaexec deprovision democluster

-  With a Docker deployment, deprovisioning tears down the Docker
   containers, network, and other local configuration.

-  With an AWS deployment, it will remove the EC2 instances, VPC
   configuration and other associated resources. Note that it will leave
   the S3 bucket it create; this will have to be manually removed.