YugabyteDB clusters
Distributed SQL, node operations and full cloud recovery.
Choose a cluster
YugabyteDB uses a PostgreSQL-compatible YSQL connection and a distributed storage engine. Choose a published YugabyteDB node type with at least three nodes. Use one region, or three live regions with at least one node in each when distributed deployments are enabled. Three masters coordinate metadata; every healthy tablet server accepts SQL reads and writes. Check SQL features and extension compatibility before migrating from PostgreSQL.
Connect securely
Download the deployment CA, copy its hostname, selected port, database name and user from Connection, and use PostgreSQL-compatible drivers with TLS certificate verification. SQL endpoints accept reads and writes. A three-region cluster has an endpoint in every live region; configure a PostgreSQL-compatible multi-host client to reconnect through another region. Your IP restrictions apply to every endpoint. Reuse a connection pool: fresh SQL sessions can need extra time to load catalog metadata across regions. Allow a suitable startup and migration query timeout. Internal RPC and administration interfaces are never exposed publicly.
Manage nodes
Node health and host metrics appear in the cluster panel. A planned node restart requires a healthy cluster, confirmation and readiness checks. Change node quantities by region through Upgrade and review the new monthly price before payment. Additional data nodes join the existing cluster. Removing a data node drains its tablets first; three master voters are retained. Applications should reconnect and retry interrupted connections.
Backups and recovery
Full logical backups are encrypted and stored in cloud storage. Each database has a consistent dump; multiple databases do not share a single atomic snapshot. Recovery creates an independent cluster with its own recurring charge. The source stays intact. PostgreSQL WAL-based PITR is not supported for YugabyteDB; the portal only offers full restore points.
Limits and availability
The service uses YSQL and replication factor three. A three-region cluster places one data replica and one master voter in each region, so the two surviving regions can form a majority after one region fails. Losing the majority stops writes. Synchronous cross-region writes add latency, and applications must reconnect and retry safely. More than three data nodes increases capacity rather than automatically increasing replication factor. A single-region cluster does not protect against a whole-region outage. Replication consumes node traffic allowances; an exhausted allowance can interrupt connectivity. Node count, per-node connection limits, and database and user limits follow the purchased configuration. The database storage allowance is shared across your databases; replicated copies do not count as additional usable data. Adding nodes does not automatically raise that allowance. Use a storage upgrade when you need more space.