In the last posts (1, 2, 3, 4, 5) I looked at PostgreSQL in Amazon RDS. Another option you have if you want to go to the cloud is to use the The Postgres Plus® Cloud Database offered by EnterpriseDB.

I will not go through the whole setup here as this is described in detail here.

So once you went through the registration and setup process you should be able to login. The login URL is depending on the region you selected so this link will not work for you if you not selected a region in the EU (Ireland, in my case):

edb_cloud_1

You’ll land at the EnterpriseDB console after a successful login:
edb_cloud_2

Obviously we want to bring up our first cluster, so lets go. You’ll have the choice between community PostgreSQL and Postgres Plus Advanced Server. The other values are more or less the same than those of the Amazon RDS service:

edb_cloud_3

edb_cloud_4
edb_cloud_5
edb_cloud_6

As soon as you choose continuous archiving a storage container for holding all the archived wal files will be created automatically:

edb_cloud_7

As soon as the creation of the storage finished an email should arrive in your inbox:

From: [email protected]
To: "daniel westermann" 
Sent: Wednesday, January 13, 2016 2:16:18 PM
Subject: WAL Archive Storage Container Created

A storage container (bucket) named xxxxx-ppcd has been created. All Postgres Plus Cloud Database clusters configured for Continuous Archiving (Point-in-Time Recovery) will use this location to store archived WAL files. This container should not be deleted once created as it will cause WAL archiving to stop functioning.

edb_cloud_8

Waiting a few minutes for the process to complete and the new PostgreSQL cluster will be ready:

edb_cloud_9
edb_cloud_10

As with the storage container you’ll receive notification emails once an instance is ready:

From: [email protected]
To: "daniel westermann" 
Sent: Wednesday, January 13, 2016 2:32:09 PM
Subject: Database State Changed to RUNNING i-7ce1b6f1 t2.micro

The Master database server ec2-52-18-219-36.eu-west-1.compute.amazonaws.com in cluster pgclust1 is now RUNNING in location eu-west-1a using port 1234.
From: [email protected]
To: "daniel westermann" 
Sent: Wednesday, January 13, 2016 2:40:44 PM
Subject: Database State Changed to RUNNING i-9e4c7d15 t2.micro

The Replica database server ec2-52-48-111-239.eu-west-1.compute.amazonaws.com t2.micro in cluster pgclust1 is now RUNNING in location eu-west-1c.

Quite easy. A very good features is that a load balances will be added automatically which listens on port 9999:

edb_cloud_11

Lets see if we can connect to the load balancer:

dwe@dwe:~$ psql -h ec2-52-18-219-36.eu-west-1.compute.amazonaws.com -p 9999 -U postgres postgres
Password for user postgres: 
psql (9.3.10, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
         Some psql features might not work.
Type "help" for help.

postgres=# \l
                                 List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges   
-----------+----------+----------+------------+------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF8 | en_US.UTF8 | 
 template0 | postgres | UTF8     | en_US.UTF8 | en_US.UTF8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF8 | en_US.UTF8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
(3 rows)

postgres=# 

In contrast to the Amazon RDS service we have full control over the cluster as we are able to connect with the postgres superuser.
When the cluster was created an initial backup was created automatically:

edb_cloud_12

Another interesting feature is auto scaling:

edb_cloud_13

You have two options there: Auto scale the cluster when a specified threshold for storage usage is reached or auto scale the cluster when a specified threshold on concurrent connections is reached. But keep in mind that this will increase costs as well.

You even can choose what happens when there is a major issue on the master:
edb_cloud_14

Do you want to replace the master with a new master or do you want to promote to a replica? Promoting to a replica is faster but you might loose transactions as replication in this case is asynchronous. In case the master is replaced with a new master the storage volumes are switch to the new master so no transaction will be lost but this will take longer than promoting a replica.

Configuring the instances is almost the same as in Amazon RDS. You’ll have to create a new configuration and then attach it to a running instance. Additionally you may configure pgpool, which is the load balancer from above:

edb_cloud_15

The monitoring part is slightly limited. You can take a look at the storage used, the amount of connections and the load. This help when defining the auto scaling options but does not replace a full monitoring solution:
edb_cloud_16

The events sections lists all events that happened to your cluster:
edb_cloud_17

Let’s try to manually scale up our cluster by adding another replica:
edb_cloud_18
edb_cloud_19
edb_cloud_20

Quite easy as well. Now we have two replicas which replicate from the same master. So, in the end, this might be a solution to consider.