Creating a cluster

1. Sign in to the EDB Postgres AI Console.

2. On the Overview or Clusters page, select Create New > Database cluster.

3. On the Create Cluster page, specify the cluster settings on the following tabs:

   • Cluster Info
   • Cluster Settings
   • DB Configuration (optional)
   • Additional Settings (optional)

4. Select Create Cluster. It might take a few minutes to deploy.

Cluster Info tab

1. Select the type of cluster to deploy.

   • Single Node creates a cluster with one primary and no standby replicas. Suited for test environments where high availability might not be required. You can create single-node clusters running PostgreSQL, EDB Postgres Extended Server or EDB Postgres Advanced Server.

   • Primary/Standby High Availability creates a cluster with one primary and one or two standby replicas in different availability zones. You can create primary/standby high-availability clusters running PostgreSQL, EDB Postgres Extended Server or EDB Postgres Advanced Server. If you enable read-only workloads, then you might have to raise the IP address resource limits for the cluster.

   • Distributed High Availability creates a cluster, powered by EDB Postgres Distributed, with up to two data groups spread across multiple cloud regions to deliver higher performance and faster recovery. You can create distributed high-availability clusters running PostgreSQL, EDB Postgres Extended Server, or EDB Postgres Advanced Server. See Creating a distributed high-availability cluster for instructions.

   See Supported cluster types for more information about the different cluster types.

   Note

   You can't switch from a single-node or primary/standby high-availability cluster to a distributed high-availability cluster or vice versa.

2. Select the number of standby replicas for your primary/standby high-availability cluster.

3. Select the cloud provider and region for your cluster. If you're using your account and haven't connected it to EDB Postgres AI Console yet, see Connecting to your cloud.

   Tip

   For the best performance, we strongly recommend that this region be the same as your other resources that communicate with your cluster. For a list of available regions, see Supported regions. If you're interested in deploying a cluster to a region that isn't currently available, contact Support.

4. Select Next: Cluster Settings to continue to specify the required settings for your cluster.

Cluster Settings tab

1. In the Cluster Name field, enter the name for your cluster.

2. In the Password field, enter a password for your cluster. This is the password for the user edb_admin.

3. Under Tags, select +.

4. To assign an existing tag, in the search bar under Tags, enter a tag name. To add a new tag, instead select + Add Tag.

5. In the Database Type section:

   1. In the Postgres Type field, select the type of Postgres you want to use:

      • EDB Postgres Advanced Server is EDB's Oracle-compatible database offering. View a quick demonstration of Oracle compatibility on EDB Postgres AI. EDB Postgres Advanced Server is compatible with all three cluster types.

      • EDB Postgres Extended Server is EDB's PostgreSQL-compatible database offering that uses advanced logical replication.

      • PostgreSQL is the open-source, object-relational database management system. PostgreSQL is compatible with single-node and primary/standby high-availability cluster types.

   2. In the Postgres Version list, select the version of Postgres that you want to use. See Database version policy for more information.

6. In the Instance Size section:

   1. Select the category that works best for your applications and workload:

      • Memory optimized for large data sets

      • Compute optimized for compute bound applications

      • General purpose if you don't require memory or compute optimization

   2. Select the instance series and size. See Sizes for virtual machines in Azure, Amazon EC2 Instance Types, or the Google Cloud Machine families resource and comparison guide for information to help you choose the appropriate instance type.

      Note

      When provisioning a cluster, some CPU and memory resources are reserved for use by EDB Postgres AI and your cloud provider. For example, when using Kubernetes, provisioning a server with 8GB of memory yields only about 6GB of memory after accounting for the requirements of Kubernetes and EDB Postgres AI.

      Tip

      To maximize your disk size for AWS, select R5b as your instance and then io2 Block Express as your storage to get a maximum disk size of 64 TB and 256,000 IOPS.

7. In the Storage section:

   By default, the Database Storage volume stores the Postgres data and the write-ahead logs (WAL) together. If you want to improve write performance for WAL files, you can allocate separate storage volume for the WAL files. To allocate separate storage volume for WAL files, select Use a separate storage volume for Write-Ahead Logs. Then select the volume type, size, IOPS, and disk throughput separately for Database Storage and Write-Ahead Logs Storage. If you allocate separate storage volume for the WAL files, you have to pay cloud infrastructure costs for the second volume. Once separate storage volume is allocated for WAL files, you can't remove it from the cluster settings later on.

   From the Volume Type list, select your volume type.

   Azure

   For Azure, in Volume Type, select Premium SSD or Ultra Disk. Compared to Premium SSD volumes, ultra disks offer lower-latency, high-performance options and direct control over your disk's input/output operations per second (IOPS). For EDB Postgres AI, we recommend using ultra disks for workloads that require the most demanding performance. See Using Azure ultra disks for more information.

   • For Premium SSD, in Volume Properties, select the type and amount of storage needed for your cluster. See Azure Premium SSD storage types for more information.

   • For ultra disk, in Volume Properties, select the disk size and IOPS for your cluster. EDB Postgres AI calculates disk throughput based on your IOPS settings, but you have the option of updating the value.

     Important

     While setting the required IOPS for the disk that you selected, consider the VM limits that are tied to the VM size that you selected. See Ultra disk IOPS for more information.

   AWS

   For AWS, in Volume Type, select General Purpose SSD (GP3), io2, or io2 Block Express.

   Note

   io2 Block Express is available for selected instance types, such as R5b. However, you can't switch between io2 and io2 Block Express after creating your cluster.

   In Volume Properties, select the disk size for your cluster, and configure the IOPS.

   GCP

   For Google Cloud, in Volume Type, select SSD Persistent Disk.

   In Volume Properties, select the disk size for your cluster.

   Note for all cloud providers

   When provisioning database storage, not all of the storage space you specify is available for holding your data. Some space is reserved for other purposes. For a full explanation of the structure of a Postgres data directory, see Database File Layout. You can make more storage space available for data if you specify separate storage for write ahead logs (WAL).

8. In the Network, Logs, & Telemetry section:

   In Connectivity Type, specify whether to use private or public networking. Networking is set to Public by default. Public means that any client can connect to your cluster’s public IP address over the internet. Optionally, you can limit traffic to your public cluster by specifying an IP allowlist, which allows access only to certain blocks of IP addresses. To limit access, select Use allowlists and add one or more classless inter-domain routing (CIDR) blocks. CIDR is a method for allocating IP addresses and IP routing to a whole network or subnet. If you have any CIDR block entries, access is limited to those IP addresses. If none are specified, all network traffic is allowed.

   Private networking allows only IP addresses in your private network to connect to your cluster.

   If you're using private networking and you're using EDB Hosted cloud account, you must enter your cloud service provider's account information. EDB Postgres AI Cloud Service uses it to auto-approve your private endpoints and also to provide access for logging and telemetry. To enable you to create your private endpoint, Cloud Service provides you with the corresponding service name, which you can use to connect to your cluster privately.

   See Cluster networking architecture for more information.

9. To optionally make updates to your database configuration parameters, select Next: DB Configuration.

DB Configuration tab

In the Parameters section, you can update the value of the database configuration parameters as needed.

To update the parameter values, see Modifying your database configuration parameters.

For other optional settings, select Next: Additional Settings.

Additional Settings tab

Volume Snapshots

Enable Volume Snapshots to take the snapshot backups. The snapshot backups are stored on the disk in the same region without degrading the performance. It might increase the storage costs on your cloud service provider. By default, the snapshot backups are stored on the disk for 30 days.

Backups

Change the default database backup retention period of 30 days using the Retention Period controls in the Backups section. You can configure the retention period to a number of days, weeks, or months. The retention period must be between 1-180 days, 1-25 weeks, or 1-6 months.

Cloud Service deletes backups older than the retention period.

Maintenance

Enable the Custom Maintenance Window option and use the controls to set a weekly 60-minute maintenance window in which maintenance upgrades occur for the cluster. If you don't set a window, the updates are applied at EDB's discretion with prior notification.

For more information, see Periodic maintenance.

Connections

Read-only workloads

Enable Read-only Workloads. This feature directs read-only operations exclusively toward replicas. If this option is enabled, you might have to raise the IP address resource limits for the cluster:

• For Azure, the IP address quota is Standard Public IP Address.

• For AWS, the IP address quota is Elastic IP. You might also have to increase the Network Load Balancers per Region value.

When enabling read-only workloads, keep in mind:

• Read-only workloads are routed to Postgres physical standbys. Commands run on read-only workloads aren't filtered by Cloud Service. The connection is read-only because it runs on a standby replica where Postgres doesn't permit changes to the contents of database tables. A privileged connection to a standby replica can still execute other sensitive commands permitted by Postgres on standby replicas. For example, it can modify replication slots or Postgres configuration settings, terminate backends, see activity from other users, and more. We recommend that you use a Postgres role with minimal privileges for your application, even for read-only workloads.

• Advisory locks aren't replicated between Postgres nodes, so advisory locks taken on a standby replica don't conflict with advisory locks taken on the primary or another standby replica. We recommend that applications that rely on advisory locking avoid using read-only workloads for those transactions.

For information on replication lag while using read-only workloads, see Standby replicas.

PgBouncer

Enable PgBouncer to have it manage your connections to Postgres databases and help your workloads run more efficiently — all entirely managed by Cloud Service. Learn more about EDB PgBouncer.

Use the PgBouncer Configuration Settings menu to set PgBouncer-specific settings. Select the Read-Write and Read-Only tabs according to the type of connection you want to configure. The Read-Only tab is available if you're creating a primary/standby high-availability cluster and have enabled read-only workloads.

Access

Identity and Access Management (IAM) Authentication

Enable Identity and Access Management (IAM) Authentication to turn on the ability to log in to Postgres using your AWS IAM credentials. For this feature to take effect, after you create the cluster, you must add each user to a role that uses AWS IAM authentication in Postgres. For details, see IAM authentication for Postgres.

Superuser Access

Enable Superuser Access to grant superuser privileges to the edb_admin role. This option is available for single-node and primary/standby high-availability clusters. See Notes on the edb_admin role.

Security

Enable Transparent Data Encryption (TDE) to use your own encryption key. This option is available for EDB Postgres Advanced Server and EDB Postgres Extended Server for version 15 and later. Select an encryption key from your project and region to encrypt the cluster with TDE. To learn more about TDE support, see Transparent Data Encryption.

Completing the TDE configuration

After you create the cluster in the EDB Postgres AI Console, the UI will display the Waiting for access to encryption key state. To complete the configuration and enable the key sync between Cloud Service and the key management platform you must grant encrypt and decrypt permissions to your key:

1. In EDB Postgres AI Console, select the cluster name and access the cluster's page. See the Action required: grant key permissions to activate the cluster.

2. Follow the on-screen guide to grant encrypt and decrypt permissions to your key. The instructions differ depending on the cloud provider of your key. Some additional guidance:

   AWS

   1. Copy the Principal identifier to your clipboard.

   2. Go to the AWS console, and navigate to the Key Management Service.

   3. Select Customer-managed keys, and Edit policy for your key.

   4. Append a new policy statement where the Principal.AWS field contains the Principal identifier you copied earlier and the Principal.Action field contains kms:Encrypt and kms:Decrypt permissions.

      This example contains the default AWS policy statement and the BigAnimal policy statement that corresponds to the TDE configuration:

      → WrapCopy

      {
           "Version": "2012-10-17",
           "Id": "key-consolepolicy-3",
           "Statement": [
               {
                   "Sid": "Enable IAM User Permissions",
                   "Effect": "Allow",
                   "Principal": {
                       "AWS": "arn:aws:iam::<aws_project_id>:root"
                   },
                   "Action": "kms:*",
                   "Resource": "*"
               },
               {
                   "Sid": "Enable TDE on cluster ExampleCluster",
                   "Effect": "Allow",
                   "Principal": {
                       "AWS": "arn:aws:iam::<aws_project_id>:role/<pg_cluster_role>"
                   },
                   "Action": [
                       "kms:Encrypt",
                       "kms:Decrypt"
                   ],
                   "Resource": "*"
               }
           ]
       }

   GCP

   1. Copy the service account to your clipboard.
   2. On the Google Cloud console, select Security, VIEW BY PRINCIPALS, and GRANT ACCESS for your key.
   3. Paste the service account into the New principals field.
   4. Assign the Cloud KMS CryptoKey Decrypter and Cloud KMS CryptoKey Encrypter roles and save.
   Azure

   1. Copy the MSI Workload Identity to your clipboard.
   2. On the Microsoft Azure console, navigate to Key vaults.
   3. Select the key. Go to Access configuration and set the Permission model to Vault access policy.
   4. Select Access policies.
   5. Select Create.
   6. In Permissions, select Encrypt and Decrypt.
   7. In Principal, paste the MSI Workload Identity you copied earlier and finish creating the policy.

What’s next

After you create your cluster, use these resources to learn about cluster use and management:

• Using your cluster
• Managing Postgres access

Related CLI commands

For information on related CLI commands, see:

• Managing clusters using the CLI
• Maintenance windows CLI command