Yandex Cloud
Search
Contact UsGet started
  • Blog
  • Pricing
  • Documentation
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • ML & AI
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Customer Stories
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Education and Science
    • Yandex Cloud Partner program
  • Blog
  • Pricing
  • Documentation
© 2025 Direct Cursus Technology L.L.C.
Yandex Managed Service for PostgreSQL
  • Getting started
    • All guides
      • Getting information on existing clusters
      • Creating a cluster
      • Updating cluster settings
      • Stopping and starting a cluster
      • Managing PostgreSQL hosts
      • Migrating hosts to a different availability zone
      • Managing replication slots
      • Managing backups
      • Managing disk space
      • Maintenance
      • Updating the PostgreSQL version
      • Deleting a cluster
  • Access management
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Public materials
  • Release notes

In this article:

  • Creating a cluster
  • Connection Manager
  • Creating a cluster copy
  • Examples
  • Creating a single-host cluster
  1. Step-by-step guides
  2. Clusters
  3. Creating a cluster

Creating a PostgreSQL cluster

Written by
Yandex Cloud
Improved by
amatol
Updated at May 5, 2025
  • Creating a cluster
    • Connection Manager
  • Creating a cluster copy
  • Examples
    • Creating a single-host cluster

A PostgreSQL cluster is one or more database hosts between which you can configure replication. Replication is enabled by default in any cluster consisting of more than one host: the master host accepts write requests and duplicates changes on replicas. The transaction is confirmed if the data is written to disk both on the master host and on a certain number of replicas, sufficient to establish a quorum.

Note

  • The number of hosts you can create together with a PostgreSQL cluster depends on the selected disk type and host class.
  • Available disk types depend on the selected host class.
  • If the DB storage is 97% full, the cluster switches to read-only mode. Plan and increase the required storage size in advance or set up an automatic increase in its size.

By default, Managed Service for PostgreSQL sets the maximum number of connections to each PostgreSQL cluster host. This maximum cannot be greater than the value of Max connections.

Warning

Managed Service for PostgreSQL reserves 15 connections for service users per PostgreSQL host. For example, if the cluster has Max connections 100, you can reserve a maximum of 85 connections for cluster users.

Creating a clusterCreating a cluster

To create a Managed Service for PostgreSQL cluster, you will need the vpc.user and managed-postgresql.editor roles or higher. For more information on assigning roles, see the Identity and Access Management documentation.

Connection ManagerConnection Manager

Cluster DB connections are managed by Connection Manager.

Creating a cluster automatically creates:

  • Connection Manager connection with information about the database connection.

  • Yandex Lockbox secret that stores the DB owner's user password. Storing passwords in Yandex Lockbox ensures their security.

The connection and secret will be created for each new database user. To view all connections, select the Connections tab on the cluster page.

You need the connection-manager.viewer role to view connection info. You can use Connection Manager to configure access to connections.

You can use Connection Manager and secrets you create there free of charge.

Management console
CLI
Terraform
REST API
gRPC API

To create a Managed Service for PostgreSQL cluster:

  1. In the management console, select the folder where you want to create a DB cluster.

  2. Select Managed Service for PostgreSQL.

  3. Click Create cluster.

  4. Enter a name for the cluster in the Cluster name field. It must be unique within the folder.

  5. Select the environment where you want to create the cluster (you cannot change the environment once the cluster is created):

    • PRODUCTION: For stable versions of your apps.
    • PRESTABLE: For testing purposes. The prestable environment is similar to the production environment and likewise covered by the SLA, but it is the first to get new functionalities, improvements, and bug fixes. In the prestable environment, you can test compatibility of new versions with your application.
  6. Select the DBMS version.

  7. Select the host class that defines the technical specifications of the VMs where the DB hosts will be deployed. All available options are listed under Host classes. When you change the host class for a cluster, the characteristics of all the already created hosts change too.

  8. Under Size of storage:

    • Select the disk type.

      The selected type determines the increments in which you can change your disk size:

      • Network HDD and SSD storage: In increments of 1 GB.
      • Local SSD storage:
        • For Intel Broadwell and Intel Cascade Lake: In increments of 100 GB.
        • For Intel Ice Lake: In increments of 368 GB.
      • Non-replicated SSDs and ultra high-speed network SSDs with three replicas: In increments of 93 GB.
    • Select the storage size to be used for data and backups. For more information on how backups take up storage space, see Backups.

  9. (Optional) Under Automatic increase of storage size, specify the settings you need:

    • In the Increase size field, set the conditions to:

      • Increase the storage size during the next maintenance window if the storage is more than the specified percent (%) full.
      • Increase the storage size right away if the storage is more than the specified percent (%) full.

      You can set both conditions, but the threshold for immediate increase must be higher than that for increase during the maintenance window.

    • In the Maximum storage size field, specify the maximum storage size that can be set when increasing the storage size automatically.

    If the specified threshold is reached, the storage size increases differently depending on disk type:

    • For network HDDs and SSDs, by the higher of the two values: 20 GB or 20% of the current disk size.

    • For non-replicated SSDs and ultra high-speed network SSDs with three replicas, by 93 GB.

    • For local SSDs:

      • In an Intel Broadwell or Intel Cascade Lake cluster, by 100 GB.
      • Intel Ice Lake cluster, by 368 GB.

    If the threshold is reached again, the storage size will be automatically increased until it reaches the specified maximum. After that, you can specify a new maximum storage size manually.

    Warning

    • You cannot decrease the storage size.
    • While resizing the storage, cluster hosts will be unavailable.

    Note

    Some PostgreSQL settings depend on the storage size.

    If you have set up the storage size to increase within the maintenance window, set up a schedule for the maintenance window.

  10. Under Database, specify the DB attributes:

    • DB name. The name must be unique within the folder.

      The database name may contain Latin letters, numbers, underscores, and hyphens. The name may be up to 63 characters long. The names postgres, template0, and template1 are reserved for Managed Service for PostgreSQL. You cannot create databases with these names.

    • DB owner username. By default, the new user is assigned 50 connections to each host in the cluster. You can change the allowed number of connections using the Conn limit setting.

      The username may contain Latin letters, numbers, hyphens, and underscores but must begin with a letter (except the pg_ combination), number, or underscore. The name may be up to 63 characters long.

      Such names as admin, repl, monitor, postgres, mdb_superuser, mdb_admin, mdb_monitor, and mdb_replication are reserved for Managed Service for PostgreSQL. You cannot create users with these names.

    • Password:

      • Enter manually: Select to enter your password. The password must be from 8 to 128 characters long.

      • Generate: Select to generate a password with the help of Connection Manager.

      To view the password, select the Users tab after you create the cluster and click View password in the user's row. This will open the page of the Yandex Lockbox secret that stores the password. To view passwords, you need the lockbox.payloadViewer role.

    • Collation (sorting) locale and character set locale. These settings define the rules for sorting strings (LC_COLLATE) and classifying characters (LC_CTYPE). In Managed Service for PostgreSQL, locale settings apply at the individual DB level.

      PostgreSQL uses locales to support various language standards. The locale you choose affects:

      • Sort order in the queries that use the ORDER BY operator or standard text data matching operators.
      • The functions upper, lower, initcap, and the to_char family of functions.
      • Pattern matching operators (LIKE, ILIKE, SIMILAR TO, regular expressions).
      • Support of indexes with the LIKE operator.

      By default, the C locale is used. if you use the C encoding for text data containing non-Latin (for example, Cyrillic) characters, errors might occur in the data sort order and data display in the case of pattern search. If this locale is not suitable for valid processing of tables in your database, select another encoding from the list. However, please keep in mind that a non-standard locale might decrease the database query processing rate.

      For more information about locale settings, see the PostgreSQL documentation.

      You cannot change locale settings after you create a database. However, you can set the sorting locale for columns when creating and modifying individual tables. Learn more in the PostgreSQL documentation.

  11. Under Network settings, select:

    • Cloud network for the cluster. If you do not have a network, click Create network to create one:

      1. In the window that opens, specify the network name and select the folder to host the network.
      2. Optionally, enable the Create subnets setting to automatically create subnets in all availability zones.
      3. Click Create network.

      Warning

      The cloud network selected for cluster deployment can't be changed. If you need to move your cluster to a different cloud network later, use the restore from a backup feature and specify the desired network for the cluster backup.

    • Security groups for the cluster network traffic. You may need to additionally set up security groups to be able to connect to the cluster.

  12. Under Hosts, select the parameters for the DB hosts created with the cluster. By default, each host is created in a separate subnet. To select a specific subnet for a host, click .

    When configuring the hosts, note that if you selected local-ssd or network-ssd-nonreplicated under Size of storage, you need to add at least three hosts to the cluster.

    To connect to the host from the internet, enable the Public access setting.

  13. Configure additional cluster settings, if required:

    • Backup start time (UTC): Time interval during which the cluster backup starts. Time is specified in 24-hour UTC format. The default time is 22:00 - 23:00 UTC.

    • Retention period for automatic backups, days: Retention period for automatic backups. If an automatic backup expires, it is deleted. The default is 7 days. For more information, see Backups.

      Changing the retention period affects both new automatic backups and existing backups. For example, the initial retention period was 7 days. The remaining lifetime for a backup with this period is 1 day. When the retention period increases to 9 days, the remaining lifetime for this backup is 3 days.

      Automatic cluster backups are stored for a specified number of days whereas manually created ones are stored indefinitely. After a cluster is deleted, all backups persist for 7 days.

    • Maintenance window: Maintenance window settings:

      • To enable maintenance at any time, select arbitrary (default).
      • To specify the preferred maintenance start time, select by schedule and specify the desired day of the week and UTC hour. For example, you can choose a time when the cluster is least loaded.

      Maintenance operations are carried out both on enabled and disabled clusters. They may include updating the DBMS, applying patches, and so on.

    • DataLens access: This option allows you to analyze cluster data in Yandex DataLens.

    • WebSQL access: Enables you to run SQL queries against cluster databases from the Yandex Cloud management console using Yandex WebSQL.

    • Yandex Query access: Enables you to run YQL queries against cluster databases from Yandex Query.

    • Serverless access: Enable this option to allow cluster access from Yandex Cloud Functions. For more information about setting up access, see the Cloud Functions documentation.

    • Statistics sampling: Allows you to use the Performance diagnostics tool in a cluster. If this option is enabled, also set the Sessions sampling interval and Statements sampling interval using the sliders. Both are measured in seconds.

    • Autofailover: If this option is enabled, the replication source for all replica hosts will automatically switch to the new master host when the master changes. To learn more, see Replication.

      If the master host is deleted, a new master will be selected automatically regardless of the value of this option.

      Alert

      If the Autofailover option is disabled, run the selection of a new master or assign this role to one of the replicas manually if the master host fails.

    • Pooling mode: Select one of the connection pooler modes.

    • Deletion protection: Protection of the cluster, its databases, and users against deletion.

      By default, the parameter inherits its value from the cluster when creating users and databases. You can also set the value manually; for more information, see the User management and Database management sections.

      If the parameter is changed on a running cluster, only users and databases with the Same as cluster protection will inherit the new value.

      Even with cluster deletion protection enabled, one can still delete a user or database or connect manually and delete the database contents.

  14. If required, configure DBMS cluster-level settings.

    Note

    Some PostgreSQL settings depend on the selected host class or storage size.

  15. Click Create cluster.

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder specified when creating the CLI profile is used by default. To change the default folder, use the yc config set folder-id <folder_ID> command. You can specify a different folder using the --folder-name or --folder-id parameter.

To create a Managed Service for PostgreSQL cluster:

  1. Check whether the folder has any subnets for the cluster hosts:

    yc vpc subnet list
    

    If there are no subnets in the folder, create the required subnets in Yandex Virtual Private Cloud.

  2. View the description of the CLI command to create a cluster:

    yc managed-postgresql cluster create --help
    
  3. Specify cluster parameters in the create command (the list of supported parameters in the example is not exhaustive):

    yc managed-postgresql cluster create \
      --name <cluster_name> \
      --environment <environment> \
      --network-name <network_name> \
      --host zone-id=<availability_zone>,`
               `subnet-id=<subnet_ID>,`
               `assign-public-ip=<access_to_host_from_internet> \
      --resource-preset <host_class> \
      --user name=<username>,password=<user_password> \
      --database name=<DB_name>,owner=<database_owner_name> \
      --disk-size <storage_size_in_GB> \
      --disk-type <network-hdd|network-ssd|network-ssd-nonreplicated|local-ssd> \
      --security-group-ids <list_of_security_group_IDs> \
      --connection-pooling-mode=<connection_pooler_mode> \
      --deletion-protection
    

    Where:

    • environment: Environment, prestable or production.

    • disk-type: Disk type.

    • assign-public-ip: Allow access to the host from the internet, true or false.

    • deletion-protection: Protection of the cluster, its databases, and users against deletion.

      By default, the parameter inherits its value from the cluster when creating users and databases. You can also set the value manually; for more information, see the User management and Database management sections.

      If the parameter is changed on a running cluster, only users and databases with the Same as cluster protection will inherit the new value.

      Even with deletion protection enabled, one can still connect to the cluster manually and delete the data.

    You need to specify the subnet-id if the selected availability zone has two or more subnets.

    Warning

    The cloud network selected for cluster deployment can't be changed. If you need to move your cluster to a different cloud network later, use the restore from a backup feature and specify the desired network for the cluster backup.

    The database name may contain Latin letters, numbers, underscores, and hyphens. The name may be up to 63 characters long. The names postgres, template0, and template1 are reserved for Managed Service for PostgreSQL. You cannot create databases with these names.

    The password must be from 8 to 128 characters long.

    Note

    You can also generate a password using Connection Manager. To do this, adjust the command, setting the user parameters as follows:

      --user name=<username>,generate-password=true
    

    To view the password, select the cluster you created in the management console, go to the Users tab and click View password in the user's row. This will open the page of the Yandex Lockbox secret that stores the password. To view passwords, you need the lockbox.payloadViewer role.

    The available connection pooler modes include SESSION, TRANSACTION, and STATEMENT.

    You can also set the additional replication-source option in the --host parameter to manually manage replication threads.

    To allow access to the cluster from Yandex Cloud Functions, provide the --serverless-access parameter. For more information about setting up access, see the Cloud Functions documentation.

    To allow access to the cluster from Yandex Query, provide the --yandexquery-access=true parameter. This feature is at the Preview stage and is available upon request.

    Note

    When creating a cluster, the anytime maintenance mode is set by default. You can set a specific maintenance period when updating the cluster settings.

With Terraform, you can quickly create a cloud infrastructure in Yandex Cloud and manage it using configuration files. These files store the infrastructure description written in HashiCorp Configuration Language (HCL). If you change the configuration files, Terraform automatically detects which part of your configuration is already deployed, and what should be added or removed.

Terraform is distributed under the Business Source License. The Yandex Cloud provider for Terraform is distributed under the MPL-2.0 license.

For more information about the provider resources, see the documentation on the Terraform website or mirror website.

If you do not have Terraform yet, install it and configure its Yandex Cloud provider.

To create a Managed Service for PostgreSQL cluster:

  1. In the configuration file, describe the resources you want to create:

    • DB cluster: Description of the cluster and its hosts

    • Database: Description of the cluster DB

    • User: Description of the cluster user

    • Network: Description of the cloud network where a cluster will be located. If you already have a suitable network, you don't have to describe it again.

    • Subnets: Description of the subnets to connect the cluster hosts to. If you already have suitable subnets, you don't have to describe them again.

    Warning

    The cloud network selected for cluster deployment can't be changed. If you need to move your cluster to a different cloud network later, use the restore from a backup feature and specify the desired network for the cluster backup.

    Here is an example of the configuration file structure:

    resource "yandex_mdb_postgresql_cluster" "<cluster_name>" {
      name                = "<cluster_name>"
      environment         = "<environment>"
      network_id          = "<network_ID>"
      security_group_ids  = [ "<list_of_security_group_IDs>" ]
      deletion_protection = <deletion_protection>
    
      config {
        version = "<PostgreSQL_version>"
        resources {
          resource_preset_id = "<host_class>"
          disk_type_id       = "<disk_type>"
          disk_size          = <storage_size_in_GB>
        }
        pooler_config {
          pool_discard = <Odyssey_parameter>
          pooling_mode = "<operation_mode>"
        }
        ...
      }
    
      host {
        zone             = "<availability_zone>"
        name             = "<host_name>"
        subnet_id        = "<subnet_ID>"
        assign_public_ip = <access_to_host_from_internet>
      }
    }
    
    resource "yandex_mdb_postgresql_database" "<DB_name>" {
      cluster_id = "<cluster_ID>"
      name       = "<DB_name>"
      owner      = "<database_owner_name>"
      depends_on = [
        yandex_mdb_postgresql_user.<username>
      ]
    }
    
    resource "yandex_mdb_postgresql_user" "<username>" {
      cluster_id = "<cluster_ID>"
      name       = "<username>"
      password   = "<user_password>"
    }
    
    resource "yandex_vpc_network" "<network_name>" { name = "<network_name>" }
    
    resource "yandex_vpc_subnet" "<subnet_name>" {
      name           = "<subnet_name>"
      zone           = "<availability_zone>"
      network_id     = "<network_ID>"
      v4_cidr_blocks = ["<range>"]
    }
    

    Where:

    • environment: Environment, PRESTABLE or PRODUCTION.

    • assign_public_ip: Allow access to the host from the internet, true or false.

    • deletion_protection: Protection of the cluster, its databases, and users against deletion, true or false.

      By default, the parameter inherits its value from the cluster when creating users and databases. You can also set the value manually; for more information, see the User management and Database management sections.

      If the parameter is changed on a running cluster, only users and databases with the Same as cluster protection will inherit the new value.

      Even with deletion protection enabled, one can still connect to the cluster manually and delete the data.

    • version: PostgreSQL version, 13, 13-1c, 14, 14-1c, 15, 15-1c, 16, 16-1c, and 17.

    • pool_discard: Odyssey pool_discard parameter, true or false.

    • pooling_mode: Operation mode, SESSION, TRANSACTION, or STATEMENT.

    The database name may contain Latin letters, numbers, underscores, and hyphens. The name may be up to 63 characters long. The names postgres, template0, and template1 are reserved for Managed Service for PostgreSQL. You cannot create databases with these names.

    The password must be from 8 to 128 characters long.

    Note

    You can also generate a password using Connection Manager. To do this, specify generate_password = true instead of "password" = "<user_password>".

    To view the password, select the cluster you created in the management console, go to the Users tab and click View password in the user's row. This will open the page of the Yandex Lockbox secret that stores the password. To view passwords, you need the lockbox.payloadViewer role.

    To set up the maintenance window (for disabled clusters as well), add the maintenance_window section to the cluster description:

    resource "yandex_mdb_postgresql_cluster" "<cluster_name>" {
      ...
      maintenance_window {
        type = <maintenance_type>
        day  = <day_of_week>
        hour = <hour>
      }
      ...
    }
    

    Where:

    • type: Maintenance type. The possible values include:
      • anytime: Anytime.
      • weekly: By schedule.
    • day: Day of the week for the weekly type in DDD format, e.g., MON.
    • hour: Hour of the day for the weekly type in the HH format, e.g., 21.

    To set up statistics collection, to the config section, add the performance_diagnostics section:

    resource "yandex_mdb_postgresql_cluster" "<cluster_name>" {
      ...
      config {
        ...
        performance_diagnostics {
          enabled = <enables statistics collection: true or false>
          sessions_sampling_interval  = <sessions sampling interval>
          statements_sampling_interval = <statements sampling interval>
        }
        ...
      }
      ...
    }
    

    Where:

    • enabled: Enable statistics collection, true or false.
    • sessions_sampling_interval: Session sampling interval, from 1 to 86400 seconds.
    • statements_sampling_interval: Statement sampling interval, from 60 to 86400 seconds.

    For a complete list of available Managed Service for PostgreSQL cluster configuration fields, see the Terraform provider documentation.

  2. Make sure the settings are correct.

    1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure.

    2. Run this command:

      terraform validate
      

      Terraform will show any errors found in your configuration files.

  3. Create a cluster.

    1. Run this command to view the planned changes:

      terraform plan
      

      If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.

    2. If everything looks correct, apply the changes:

      1. Run this command:

        terraform apply
        
      2. Confirm updating the resources.

      3. Wait for the operation to complete.

    Time limits

    A Terraform provider sets the timeout for Managed Service for PostgreSQL cluster operations:

    • Creating a cluster, including restoring from a backup: 30 minutes.
    • Editing a cluster: 60 minutes.
    • Deleting a cluster: 15 minutes.

    Operations exceeding the set timeout are interrupted.

    How do I change these limits?

    Add the timeouts block to the cluster description, for example:

    resource "yandex_mdb_postgresql_cluster" "<cluster_name>" {
      ...
      timeouts {
        create = "1h30m" # 1 hour 30 minutes
        update = "2h"    # 2 hours
        delete = "30m"   # 30 minutes
      }
    }
    
  1. Get an IAM token for API authentication and put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Create a file named body.json and add the following contents to it:

    {
      "folderId": "<folder_ID>",
      "name": "<cluster_name>",
      "environment": "<environment>",
      "networkId": "<network_ID>",
      "securityGroupIds": [
        "<security_group_1_ID>",
        "<security_group_2_ID>",
        ...
        "<security_group_N_ID>"
      ],
      "deletionProtection": <deletion_protection:_true_or_false>,
      "configSpec": {
        "version": "<PostgreSQL_version>",
        "resources": {
          "resourcePresetId": "<host_class>",
          "diskSize": "<storage_size_in_bytes>",
          "diskTypeId": "<disk_type>"
        },
        "access": {
          "dataLens": <access_to_DataLens:_true_or_false>,
          "webSql": <access_to_WebSQL:_true_or_false>,
          "serverless": <access_to_Cloud_Functions:_true_or_false>,
          "dataTransfer": <access_to_Data_Transfer:_true_or_false>,
          "yandexQuery": <access_to_Query:_true_or_false>
        },
        "performanceDiagnostics": {
          "enabled": <activate_statistics_collection:_true_or_false>,
          "sessionsSamplingInterval": "<session_sampling_interval>",
          "statementsSamplingInterval": "<statement_sampling_interval>"
        }
      },
      "databaseSpecs": [
        {
          "name": "<DB_name>",
          "owner": "<database_owner_name>"
        },
        { <similar_configuration_for_DB_2> },
        { ... },
        { <similar_configuration_for_DB_N> }
      ],
      "userSpecs": [
        {
          "name": "<username>",
          "password": "<user_password>",
          "permissions": [
            {
              "databaseName": "<DB_name>"
            }
          ],
          "login": <allow_user_to_connect_to_DB:_true_or_false>
        },
        { <similar_configuration_for_user_2> },
        { ... },
        { <similar_configuration_for_user_N> }
      ],
      "hostSpecs": [
        {
          "zoneId": "<availability_zone>",
          "subnetId": "<subnet_ID>",
          "assignPublicIp": <public_host_address:_true_or_false>
        },
        { <similar_configuration_for_host_2> },
        { ... },
        { <similar_configuration_for_host_N> }
      ]
    }
    

    Where:

    • folderId: Folder ID. You can request it with the list of folders in the cloud.

    • name: Cluster name.

    • environment: Cluster environment, PRODUCTION or PRESTABLE.

    • networkId: ID of the network the cluster will be in.

      Warning

      The cloud network selected for cluster deployment can't be changed. If you need to move your cluster to a different cloud network later, use the restore from a backup feature and specify the desired network for the cluster backup.

    • securityGroupIds: Security group IDs.

    • deletionProtection: Protection of the cluster, its databases, and users against deletion.

      By default, the parameter inherits its value from the cluster when creating users and databases. You can also set the value manually; for more information, see the User management and Database management sections.

      If the parameter is changed on a running cluster, only users and databases with the Same as cluster protection will inherit the new value.

      Even with deletion protection enabled, one can still connect to the cluster manually and delete the data.

    • configSpec: Cluster settings:

      • version: PostgreSQL version.

      • resources: Cluster resources:

        • resourcePresetId: Host class.
        • diskSize: Disk size in bytes.
        • diskTypeId: Disk type.
      • access: Cluster settings for access to the following Yandex Cloud services:

        • dataLens: Yandex DataLens
        • webSql: Yandex WebSQL
        • serverless: Yandex Cloud Functions
        • dataTransfer: Yandex Data Transfer
        • yandexQuery: Yandex Query
      • performanceDiagnostics: Statistics collection settings:

        • enabled: Enables statistics collection.
        • sessionsSamplingInterval: Session sampling interval. The values range from 1 to 86400 seconds.
        • statementsSamplingInterval: Statement sampling interval. The values range from 60 to 86400 seconds.
    • databaseSpecs: Database settings as an array of elements, one for each DB. Each element has the following structure:

      • name: DB name.
      • owner: DB owner username. It must match one of the usenames specified in the request.
    • userSpecs: User settings as an array of elements, one for each user. Each element has the following structure:

      • name: Username.

      • password: User password. The password must be from 8 to 128 characters long.

        You can also generate a password using Connection Manager. To do this, specify "generatePassword": true instead of "password": "<user_password>".

        To view the password, select the cluster you created in the management console, go to the Users tab and click View password in the user's row. This will open the page of the Yandex Lockbox secret that stores the password. To view passwords, you need the lockbox.payloadViewer role.

      • permissions.databaseName: Name of the database the user gets access to.

      • login: User permission to connect to the DB.

    • hostSpecs: Cluster host settings as an array of elements, one for each host. Each element has the following structure:

      • zoneId: Availability zone.
      • subnetId: Subnet ID.
      • assignPublicIp: Permission to connect to the host from the internet.
  3. Use the Cluster.Create method and send the following request, e.g., via cURL:

    curl \
      --request POST \
      --header "Authorization: Bearer $IAM_TOKEN" \
      --header "Content-Type: application/json" \
      --url 'https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters' \
      --data "@body.json"
    
  4. View the server response to make sure the request was successful.

  1. Get an IAM token for API authentication and put it into the environment variable:

    export IAM_TOKEN="<IAM_token>"
    
  2. Clone the cloudapi repository:

    cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi
    

    Below, we assume the repository contents are stored in the ~/cloudapi/ directory.

  3. Create a file named body.json and add the following contents to it:

    {
      "folder_id": "<folder_ID>",
      "name": "<cluster_name>",
      "environment": "<environment>",
      "network_id": "<network_ID>",
      "security_group_ids": [
        "<security_group_1_ID>",
        "<security_group_2_ID>",
        ...
        "<security_group_N_ID>"
      ],
      "deletion_protection": <deletion_protection:_true_or_false>,
      "config_spec": {
        "version": "<PostgreSQL_version>",
        "resources": {
          "resource_preset_id": "<host_class>",
          "disk_size": "<storage_size_in_bytes>",
          "disk_type_id": "<disk_type>"
        },
        "access": {
          "data_lens": <access_to_DataLens:_true_or_false>,
          "web_sql": <access_to_WebSQL:_true_or_false>,
          "serverless": <access_to_Cloud_Functions:_true_or_false>,
          "data_transfer": <access_to_Data_Transfer:_true_or_false>,
          "yandex_query": <access_to_Query:_true_or_false>
        },
        "performance_diagnostics": {
          "enabled": <activate_statistics_collection:_true_or_false>,
          "sessions_sampling_interval": "<session_sampling_interval>",
          "statements_sampling_interval": "<statement_sampling_interval>"
        }
      },
      "database_specs": [
        {
          "name": "<DB_name>",
          "owner": "<database_owner_name>"
        },
        { <similar_configuration_for_DB_2> },
        { ... },
        { <similar_configuration_for_DB_N> }
      ],
      "user_specs": [
        {
          "name": "<username>",
          "password": "<user_password>",
          "permissions": [
            {
              "database_name": "<DB_name>"
            }
          ],
          "login": <allow_user_to_connect_to_DB:_true_or_false>
        },
        { <similar_configuration_for_user_2> },
        { ... },
        { <similar_configuration_for_user_N> }
      ],
      "host_specs": [
        {
          "zone_id": "<availability_zone>",
          "subnet_id": "<subnet_ID>",
          "assign_public_ip": <public_host_address:_true_or_false>
        },
        { <similar_configuration_for_host_2> },
        { ... },
        { <similar_configuration_for_host_N> }
      ]
    }
    

    Where:

    • folder_id: Folder ID. You can request it with the list of folders in the cloud.

    • name: Cluster name.

    • environment: Cluster environment, PRODUCTION or PRESTABLE.

    • network_id: ID of the network the cluster will be in.

      Warning

      The cloud network selected for cluster deployment can't be changed. If you need to move your cluster to a different cloud network later, use the restore from a backup feature and specify the desired network for the cluster backup.

    • security_group_ids: Security group IDs.

    • deletion_protection: Protection of the cluster, its databases, and users against deletion.

      By default, the parameter inherits its value from the cluster when creating users and databases. You can also set the value manually; for more information, see the User management and Database management sections.

      If the parameter is changed on a running cluster, only users and databases with the Same as cluster protection will inherit the new value.

      Even with deletion protection enabled, one can still connect to the cluster manually and delete the data.

    • config_spec: Cluster settings:

      • version: PostgreSQL version.

      • resources: Cluster resources:

        • resource_preset_id: Host class.
        • disk_size: Disk size in bytes.
        • disk_type_id: Disk type.
      • access: Cluster settings for access to the following Yandex Cloud services:

        • data_lens: Yandex DataLens
        • web_sql: Yandex WebSQL
        • serverless: Yandex Cloud Functions
        • data_transfer: Yandex Data Transfer
        • yandex_query: Yandex Query
      • performance_diagnostics: Statistics collection settings:

        • enabled: Enables statistics collection.
        • sessions_sampling_interval: Session sampling interval. The values range from 1 to 86400 seconds.
        • statements_sampling_interval: Statement sampling interval. The values range from 60 to 86400 seconds.
    • database_specs: Database settings as an array of elements, one for each DB. Each element has the following structure:

      • name: DB name.
      • owner: DB owner username. It must match one of the usenames specified in the request.
    • user_specs: User settings as an array of elements, one for each user. Each element has the following structure:

      • name: Username.

      • password: User password. The password must be from 8 to 128 characters long.

        You can also generate a password using Connection Manager. To do this, specify "generate_password": true instead of "password": "<user_password>".

        To view the password, select the cluster you created in the management console, go to the Users tab and click View password in the user's row. This will open the page of the Yandex Lockbox secret that stores the password. To view passwords, you need the lockbox.payloadViewer role.

      • permissions.database_name: Name of the database the user gets access to.

      • login: User permission to connect to the DB.

    • host_specs: Cluster host settings as an array of elements, one for each host. Each element has the following structure:

      • zone_id: Availability zone.
      • subnet_id: Subnet ID.
      • assign_public_ip: Permission to connect to the host from the internet.
  4. Use the ClusterService.Create call and send the following request, e.g., via gRPCurl:

    grpcurl \
      -format json \
      -import-path ~/cloudapi/ \
      -import-path ~/cloudapi/third_party/googleapis/ \
      -proto ~/cloudapi/yandex/cloud/mdb/postgresql/v1/cluster_service.proto \
      -rpc-header "Authorization: Bearer $IAM_TOKEN" \
      -d @ \
      mdb.api.cloud.yandex.net:443 \
      yandex.cloud.mdb.postgresql.v1.ClusterService.Create \
      < body.json
    
  5. View the server response to make sure the request was successful.

Warning

If you specified security group IDs when creating a cluster, you may also need to configure security groups to connect to the cluster.

Creating a cluster copyCreating a cluster copy

You can create a PostgreSQL cluster using the settings of another one created earlier. To do so, you need to import the configuration of the source PostgreSQL cluster to Terraform. This way you can either create an identical copy or use the imported configuration as the baseline and modify it as needed. Importing a configuration is a good idea when the source PostgreSQL cluster has a lot of settings and you need to create a similar one.

To create an PostgreSQL cluster copy:

Terraform
  1. If you do not have Terraform yet, install it.

  2. Get the authentication credentials. You can add them to environment variables or specify them later in the provider configuration file.

  3. Configure and initialize a provider. There is no need to create a provider configuration file manually, you can download it.

  4. Place the configuration file in a separate working directory and specify the parameter values. If you did not add the authentication credentials to environment variables, specify them in the configuration file.

  5. In the same working directory, place a .tf file with the following contents:

    resource "yandex_mdb_postgresql_cluster" "old" { }
    
  6. Write the ID of the initial PostgreSQL cluster to the environment variable:

    export POSTGRESQL_CLUSTER_ID=<cluster_ID>
    

    You can request the ID with the list of clusters in the folder.

  7. Import the settings of the initial PostgreSQL cluster into the Terraform configuration:

    terraform import yandex_mdb_postgresql_cluster.old ${POSTGRESQL_CLUSTER_ID}
    
  8. Get the imported configuration:

    terraform show
    
  9. Copy it from the terminal and paste it into the .tf file.

  10. Place the file in the new imported-cluster directory.

  11. Modify the copied configuration so that you can create a new cluster from it:

    • Specify the new cluster name in the resource string and the name parameter.
    • Delete created_at, health, id, and status.
    • In the host sections, delete fqdn and role.
    • If the disk_size_autoscaling section has disk_size_limit = 0, delete this section.
    • If the maintenance_window section has type = "ANYTIME", delete the hour parameter.
    • Optionally, make further changes if you need to customize the configuration.
  12. Get the authentication credentials in the imported-cluster directory.

  13. In the same directory, configure and initialize a provider. There is no need to create a provider configuration file manually, you can download it.

  14. Place the configuration file in the imported-cluster directory and specify the parameter values. If you did not add the authentication credentials to environment variables, specify them in the configuration file.

  15. Check that the Terraform configuration files are correct:

    terraform validate
    

    If there are any errors in the configuration files, Terraform will point them out.

  16. Create the required infrastructure:

    1. Run this command to view the planned changes:

      terraform plan
      

      If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources.

    2. If everything looks correct, apply the changes:

      1. Run this command:

        terraform apply
        
      2. Confirm updating the resources.

      3. Wait for the operation to complete.

    All the required resources will be created in the specified folder. You can check resource availability and their settings in the management console.

Time limits

A Terraform provider sets the timeout for Managed Service for PostgreSQL cluster operations:

  • Creating a cluster, including restoring from a backup: 30 minutes.
  • Editing a cluster: 60 minutes.
  • Deleting a cluster: 15 minutes.

Operations exceeding the set timeout are interrupted.

How do I change these limits?

Add the timeouts block to the cluster description, for example:

resource "yandex_mdb_postgresql_cluster" "<cluster_name>" {
  ...
  timeouts {
    create = "1h30m" # 1 hour 30 minutes
    update = "2h"    # 2 hours
    delete = "30m"   # 30 minutes
  }
}

ExamplesExamples

Creating a single-host clusterCreating a single-host cluster

CLI
Terraform

To create a cluster with a single host, provide a single --host parameter.

Create a Managed Service for PostgreSQL cluster with the following test specifications:

  • Name: mypg.
  • Environment: production.
  • Network: default.
  • Security group: enp6saqnq4ie244g67sb.
  • With one s2.micro host in the b0rcctk2rvtr******** subnet, in the ru-central1-a availability zone.
  • Network SSD storage (network-ssd): 20 GB.
  • User: user1, password: user1user1.
  • Database: db1, owner: user1.
  • Protection of the cluster, its DBs, and users against accidental deletion: Enabled.

Run the following command:

yc managed-postgresql cluster create \
   --name mypg \
   --environment production \
   --network-name default \
   --resource-preset s2.micro \
   --host zone-id=ru-central1-a,subnet-id=b0rcctk2rvtr******** \
   --disk-type network-ssd \
   --disk-size 20 \
   --user name=user1,password=user1user1 \
   --database name=db1,owner=user1 \
   --security-group-ids enp6saqnq4ie244g67sb \
   --deletion-protection

Create a Managed Service for PostgreSQL cluster and a network for it with the following test specifications:

  • Name: mypg.

  • Version: 17.

  • Environment: PRESTABLE.

  • Cloud ID: b1gq90dgh25bebiu75o.

  • Folder ID: b1gia87mbaomkfvsleds.

  • New network: mynet.

  • New security group: pgsql-sg, allowing cluster connections from the internet through port 6432.

  • Host class: s2.micro (one host), new subnet: mysubnet, availability zone: ru-central1-a. mysubnet range: 10.5.0.0/24.

  • Network SSD storage (network-ssd): 20 GB.

  • User: user1, password: user1user1.

  • Database: db1, owner: user1.

  • Protection of the cluster, its DBs, and users against accidental deletion: Enabled.

The configuration file for this cluster is as follows:

resource "yandex_mdb_postgresql_cluster" "mypg" {
  name                = "mypg"
  environment         = "PRESTABLE"
  network_id          = yandex_vpc_network.mynet.id
  security_group_ids  = [ yandex_vpc_security_group.pgsql-sg.id ]
  deletion_protection = true

  config {
    version = 17
    resources {
      resource_preset_id = "s2.micro"
      disk_type_id       = "network-ssd"
      disk_size          = "20"
    }
  }

  host {
    zone      = "ru-central1-a"
    name      = "mypg-host-a"
    subnet_id = yandex_vpc_subnet.mysubnet.id
  }
}

resource "yandex_mdb_postgresql_database" "db1" {
  cluster_id = yandex_mdb_postgresql_cluster.mypg.id
  name       = "db1"
  owner      = "user1"
}

resource "yandex_mdb_postgresql_user" "user1" {
  cluster_id = yandex_mdb_postgresql_cluster.mypg.id
  name       = "user1"
  password   = "user1user1"
}

resource "yandex_vpc_network" "mynet" {
  name = "mynet"
}

resource "yandex_vpc_subnet" "mysubnet" {
  name           = "mysubnet"
  zone           = "ru-central1-a"
  network_id     = yandex_vpc_network.mynet.id
  v4_cidr_blocks = ["10.5.0.0/24"]
}

resource "yandex_vpc_security_group" "pgsql-sg" {
  name       = "pgsql-sg"
  network_id = yandex_vpc_network.mynet.id

  ingress {
    description    = "PostgreSQL"
    port           = 6432
    protocol       = "TCP"
    v4_cidr_blocks = [ "0.0.0.0/0" ]
  }
}

Was the article helpful?

Previous
Getting information on existing clusters
Next
Updating cluster settings
© 2025 Direct Cursus Technology L.L.C.