Product Description Cloud Databases

Last update: May 27 2025

Product Description Cloud Databases

Cloud Databases is a service for deploying and managing high-performance and fault-tolerant clusters of supported databases in the cloud.

You can work with cloud databases in the control panel, via the Cloud Databases API or Terraform (except OpenSearch).

The product supports user types and roles, projects and project limits and quotas.

Supported cloud databases⁠

PostgreSQL	Open source database. It is oriented on speed and extensibility — you can connect any external data sources, create new data types and functions
PostgreSQL for 1C	PostgreSQL version with necessary extensions for efficient work with 1C:Enterprise
PostgreSQL TimescaleDB	A version of PostgreSQL with the TimescaleDB extension that can be used to store time series
MySQL semi-sync	An open source relational database management system that is easy to manage and scale. Suitable for most data handling tasks
MySQL sync	An open source solution for MySQL. Powered by Percona Server for MySQL with XtraDB storage subsystem
Redis	NoSQL class in-memory database management system. Can work as a database and queue system
Kafka	An open source distributed system for message delivery, storage and processing. Can work as a data bus for Cloud Native applications
OpenSearch	A scalable open source search and analytics engine

How cloud databases work⁠

Cloud databases are deployed in a cluster. A cluster is one or more database servers (nodes). The nodes in the cluster run on the resources of the cloud platform.

Cloud databases support monitoring, backups, and cluster scaling. You can improve cluster resiliency and configure replication between nodes.

Database settings when creating the cluster are selected by default and depend on the cluster configuration and database version. You can change them if necessary.

The configuration of cloud database networks depends on the specifics of the infrastructure in which the cloud database is embedded.

Monitoring⁠

In cloud databases, you can monitor the status of the cluster in the dashboard:

• View information about cluster node utilization and database load in the form of graphs in the control panel;
• watch the status of the cluster;
• receive notifications when the disk is full.

Cluster and database node metrics can also be exported in Prometheus format.

Learn more about monitoring in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, and Kafka.

Backups⁠

In cloud databases, cluster backups are created automatically by WAL-G. All databases except Redis are Point-in-Time Recovery.The frequency of backups depends on the selected database.

Backups are stored in Selectel object storage isolated from other users' backups.Backups cannot be unloaded. Automatic backup creation cannot be disabled.

Read more about backups in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.

Scaling⁠

The cloud database cluster can be scaled — for example, increase vCPU and RAM to improve cluster performance. You can select a configuration from a different line of configurations, but the type of disk used must match and the disk size must be larger.

Learn more about scaling in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, Kafka, and OpenSearch.

Fault tolerance and replication⁠

PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, My SQL semi-sync, Redis⁠

By default, the cluster consists of one main node — the master node. When connected to the master node, all operations are available: read (SELECT) and write (INSERT, UPDATE, DELETE and others).

To provide cluster fault tolerance, add replicas — full copies of the master node. They are read-only (SELECT) copies of the master node. If the master node is unavailable, the replicas will take over and the cluster will operate normally. They can also be used to reduce the load on the master node during active reads.

For a replica cluster, the following applies SLA — we guarantee 99.95% write availability and 99.99% read availability.

The type of node placement in a cloud database cluster depends on the availability of replicas in the cluster and the number of segments in the pool in which the cluster is located:

• Single-AZ — in one segment of the pool. Applicable for clusters without replicas and for clusters with replicas that are in pools with a single segment;
• Multi-AZ — in different segments of the pool. Applicable for replica clusters that are in pools with multiple segments. Nodes are allocated to segments sequentially.

Read more about fault tolerance in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis.

OpenSearch⁠

The cluster uses the standard mechanism of index replication — for each primary shard the number of replica shards you specified when creating the index is created. Writing to the index is done only through primary shards, reading can be done simultaneously from primary and replica shards.

Cloud database settings⁠

Database settings affect the performance of the database cluster. When you create a database cluster, the values for all settings are set automatically. The values are selected to ensure high cluster performance and vary depending on the cluster configuration and database version.

If the automatic values are not suitable for your tasks, for all cloud databases except Redis and OpenSearch, you can set your values when creating a cluster or change the settings in an already created cluster.

Learn more about configuring cloud databases in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, and Kafka.

Networks⁠

When creating a cloud database cluster, it is necessary to consider the specifics of the infrastructure in which the cloud database is embedded — whether the cluster nodes need to be accessed from the Internet and whether network connectivity with other Selectel services is required.

The cluster can be connected:

• to a private subnet — a subnet with no access from the Internet;
• public subnet (except OpenSearch) — all public subnet addresses are accessible from the Internet.

Once a cluster is created, the subnet cannot be changed.

Learn more about creating network connectivity between a Selectel dedicated server and a cloud database cluster in the instructions for PostgreSQL, PostgreSQL for 1C, PostgreSQL TimescaleDB, MySQL sync, MySQL semi-sync, Redis, and Kafka.

Areas of responsibility⁠

Selectel provides⁠

• hardware selection for high DBMS performance;
• installing an operating system;
• DBMS installation and standard configuration, which is optimal for the selected configuration;
• updating and maintenance of the operating system and service software;
• Cluster reliability and fault tolerance — when you build a fault-tolerant cluster, we provide failover in the event of a failure;
• Configuring and maintaining the service network for cluster replicas;
• Backup — automatic creation and storage of backups;
• cluster status monitoring system in the control panel;
• secure data storage and protection against theft and leakage;
• compliance with the requirements of 152-FZ;
• Availability of resources to scale the cluster if you initiate scaling;
• technical support.

The user provides⁠

• correct connection to the database;
• optimality of writing database queries;
• the schema and structure of the data in the database;
• Change settings according to your workload profile and application peculiarities;
• initiating cluster scaling.

If you need help with database administration, order service administration services.