Selectel launches Multi-AZ managed database clusters

On 23 July 2026, Selectel announced Multi-AZ managed database clusters in its geographically distributed ru-6 cloud region. Current versions of PostgreSQL, MySQL, Redis, TimescaleDB and ClickHouse are supported, and the nodes of each cluster are distributed across three independent availability zones.

According to the provider, the sites are 10–15 kilometres apart and connected by a network offering up to 10 Gbit/s. The architecture is designed to keep a service operating if one zone fails. This is a meaningful infrastructure improvement, but Multi-AZ should not be treated as a complete business-continuity plan.

What distribution across zones provides

An availability zone is an isolated part of a cloud platform with its own engineering systems and network boundary. If database replicas are placed in different zones, a power, equipment or local network failure at one site should not take the entire cluster offline at once.

Multi-AZ reduces the risk of a data-centre-level single point of failure and removes some cluster engineering from the customer’s workload. The provider manages node placement while applications connect to the managed database service.

Application availability, however, depends on more than the database. If a load balancer, message queue, secret store or identity service remains in one zone, the business process can still stop. The change therefore needs to be evaluated across the full dependency map.

Multi-AZ, backup and a secondary region are different controls

These mechanisms address different events:

• a replica in another zone helps the service survive a site failure;
• a backup is needed after accidental deletion, corruption or a failed migration;
• a secondary region reduces exposure to a larger regional disruption;
• an exportable copy reduces dependence on one cloud account or provider.

Replication may spread a logical error quickly to every node. Multi-AZ therefore does not remove the need for isolated backups and regular restore tests. These layers are explained in our guide to backup and fault tolerance.

What to clarify before moving a production database

The official announcement confirms the supported engines, three zones, the distance between sites and network capacity. A project decision also requires current documentation and contract terms:

1. Which replication mode is used by the selected database engine?
2. How is a failure detected and how long does failover take?
3. Does the connection endpoint change during failover?
4. Can recently acknowledged transactions be lost?
5. Which maintenance operations cause interruption?
6. Where are backups stored physically?
7. Which RPO, RTO and SLA values are contractual?
8. How does a customer receive failover and degradation events?

The team should also check quotas, available configurations, extension versions and network constraints. The same database product name does not guarantee full compatibility with an application’s current environment.

How to run a verifiable pilot

A pilot should combine performance testing with controlled failures. First, establish normal latency, throughput and cost. Then simulate a dropped node connection, replica restart, a long transaction during failover and the loss of one zone.

At the application layer, verify:

• connection timeouts and retry policy;
• idempotency of repeated operations;
• connection-pool recovery after a role change;
• absence of duplicate and lost jobs;
• monitoring and alert delivery;
• actual recovery time for a user operation.

The user operation, not a green cluster indicator in a console, is the final metric. The database can report availability while an application continues using a stale connection or waits through an excessive timeout.

Practical conclusion

Multi-AZ DBaaS reduces the infrastructure that a team must build and maintain itself. It is particularly valuable for systems in which database downtime immediately stops sales, customer service or internal operations.

The migration decision should still follow an application architecture review, failure testing and verification of contractual service levels. Our comparison of IaaS and an owned data centre can support the platform decision, while recovery objectives belong in a separate disaster-recovery plan.

Source: official Selectel blog; the original URL is provided in the article metadata.