Что произойдёт при отказе первичного узла PostgreSQL?

Оператор CloudNativePG автоматически повысит реплику до первичного узла и переключит точку подключения. Данные защищены репликацией на уровне БД, а при реплицируемом классе хранилища — ещё и на уровне дисков.

Это настоящий PostgreSQL?

Да, стандартный PostgreSQL под управлением оператора CloudNativePG (CNPG) — работают привычные расширения, драйверы и инструменты.

Как проверить, что бэкапы PostgreSQL восстанавливаются?

Восстановление возможно не только на место, но и в отдельный новый кластер — копии можно регулярно проверять, не затрагивая production.

Можно ли подключаться к managed PostgreSQL извне облака?

Да, сервис публикуется через LoadBalancer с публичным IP, подключение защищено TLS. Приложениям внутри того же пространства DevSpace публичный адрес не нужен — они обращаются к базе по внутреннему имени сервиса.

Managed PostgreSQL in the cloud — DBaaS on CloudNativePG (CNPG)

Managed PostgreSQL

A replicated PostgreSQL cluster in your DevSpace, in a few minutes: streaming replication, automatic failover, backups to object storage. Regular PostgreSQL — with a standard protocol that any driver and any ORM can connect to.

Fault‑tolerant PostgreSQL with automatic failover and point‑in‑time recovery.

Free Trial

What you get

-1-

A cluster, not an instance.

primary node plus replicas with streaming replication
-2-

Automatic failover

If the primary node fails, its role automatically shifts to the replica, without the need for an engineer’s intervention.
-3-

Backups and PITR

Continuous archiving of logs (WAL) to an S3‑compatible storage and recovery to any point in time.
-4-

Standard PostgreSQL

Full compatibility with ecosystem extensions, drivers, and tools.
-5-

User and database management

declaratively, from a panel or via a manifest

Free Trial

How the service works

The cluster is managed by CloudNativePG (CNPG) — an open Kubernetes operator for PostgreSQL, one of the most popular in the industry (the project is being developed by the CNCF ecosystem community).

Streaming replication

The data from the primary node is synchronized to the replicas using the standard PostgreSQL mechanism. You choose the number of replicas.
Self-healing

The operator constantly compares the actual state of the cluster with the desired state: it will recreate a failed node and reinitialize a lagging replica—on its own, without tickets or a duty officer.
Automatic failover

If the primary node is unavailable, the operator increases the active replica and switches the connection point. The application only needs to reconnect.
Replicable storage — selectable

The storage class is specified when creating the cluster; the replicated class duplicates the node’s data across multiple servers — in this case, protection works at both the database level and the disk level.
Continuous WAL archiving

Preemptive write logs are constantly sent to the object storage — this is the basis for point‑in‑time recovery.

Opportunities

Use cases

The main product database

production load with availability requirements
A separate base for the environment

dev, staging, and prod in different DevSpace spaces, with data migration via backup/restore.
Quick recovery after errors

“Dropped” data during migration? PITR will revert the state to the minute before it, to a separate cluster for reconciliation.
Replacement of self‑assembled installations

Replication, failover, and backups without manual configuration of Patroni/pgBackRest and on‑call duties.

Free Trial

How to deploy PostgreSQL in the cloud — three steps

1

Add the “PostgreSQL” service to your DevSpace: size, number of replicas, disk space. If you don’t have a space yet, creating one will take a couple of minutes.
2

Enable backup — the schedule and storage policy are set in the settings.
3

Connect using the standard connection string from the panel — psql, any driver, or ORM.

FAQ

Try it out