Plan your universe

Plan your deployment →  across different products

YugabyteDB YugabyteDB Anywhere YugabyteDB Aeon

Summary of best practices

The following best practices are recommended for production universes.

In depth

New UI Placement in the following sections describes the New UI, which uses Guided and Expert modes. To enable the New UI, refer to New experience. For steps to create a universe, refer to Create universes.

Topology

A YugabyteDB universe typically consists of three or more nodes that communicate with each other and across which data is distributed. You can place the nodes in a single availability zone, across multiple zones in a single region, and across regions. With more advanced topologies, you can attach a read replica cluster, pin data to geographic regions, or replicate asynchronously to another universe. The topology you choose depends on your requirements for latency, availability, and geo-distribution.

Single region

Single-region universes are available in the following topologies:

• Single availability zone. Resilient to node outages.
• Multiple availability zones. Resilient to node and availability zone outages.

Cloud providers design zones to minimize the risk of correlated failures caused by physical infrastructure outages like power, cooling, or networking. In other words, single failure events usually affect only a single zone. By deploying nodes across zones in a region, you get resilience to a zone outage as well as high availability.

Single-region universes are not resilient to region-level outages.

Multiple region

Multi-region universes are resilient to region-level outages (when data is replicated across regions), and are available in the following topologies:

• Replicate across regions. Universe nodes are deployed across 3 or more regions, with data replicated synchronously. Refer to Synchronous multi region.
• Partition by region. Cluster nodes are deployed in separate regions. Data is pinned to specific geographic regions using row-level geo-partitioning. Allows fine-grained control over pinning rows in a user table to specific geographic locations.
• Read replica. Replica clusters are added to an existing primary cluster and deployed in separate regions, typically remote from the primary. Data is written in the primary cluster and copied to the read replicas, where it can be read. The primary cluster still gets all write requests, while read requests can go either to the primary cluster or to the read replica clusters depending on which is closest. Refer to Add a read replica.
• xCluster. Two universes are deployed in separate regions. Data is replicated asynchronously between them, either in one direction or bidirectionally. Use xCluster for disaster recovery or asynchronous replication.

You can also deploy a single universe across multiple cloud providers using an on-premises provider.

For more details, refer to Multi-region deployments.

Provider and region

Provider

YugabyteDB Anywhere deploys universes using a provider configuration that describes your environment — regions, availability zones, images, networking, and (for public clouds) the credentials YugabyteDB Anywhere uses to create nodes.

Your choice of provider depends primarily on where your applications run and how much automation you want YugabyteDB Anywhere to have.

Not sure which provider to use? Refer to Provider configurations.

You must create a provider configuration before you create a universe. For Kubernetes, see Create Kubernetes provider configuration.

Region

For best performance as well as lower data transfer costs, locate your universe as close to your applications as possible:

• Use the same cloud provider as your application.
• Locate universe nodes in the same region as your application.

You can only select regions (and availability zones) that have been added to the provider configuration.

For on-premises providers, ensure the free pool has enough nodes in the regions and zones you plan to use.

Instance types

When you create a universe, you choose an instance type from those available in the provider and selected regions. YugabyteDB Anywhere uses the same instance type for all TServer nodes in the cluster.

For public clouds, instance availability varies by region. For on-premises, instance type is informational — you provision the VMs. For Kubernetes, you set cores, memory, and volume size instead of a cloud instance type.

Placement

YugabyteDB achieves resiliency by replicating data across fault domains using the Raft consensus protocol. The fault domain can be at the level of individual nodes, availability zones, or entire regions.

Placement determines how resilient the universe is to domain (that is, node, zone, or region) outages, whether planned or unplanned. Resilience is achieved by adding redundancy, in the form of additional nodes, across the fault domain. Due to the way the Raft protocol works, providing a fault tolerance of ft requires replicating data across 2ft + 1 domains. For example, to survive the outage of 2 nodes, a cluster needs 2 * 2 + 1 nodes. While the 2 nodes are offline, the remaining 3 nodes can continue to serve reads and writes without interruption.

With a resilient universe, planned outages such as maintenance and upgrades are performed using a rolling restart, meaning your workloads are not interrupted.

Setup modes

When creating or modifying universe placement, you choose Regular Cluster (production) or Single-Node Cluster (development and testing only). For regular clusters, you then choose Guided or Expert mode.

Guided is recommended for most users. Use Expert when you need different node counts per zone, a region and zone layout that Guided does not allow, or to set replication factor directly.

Single-Node Cluster is a separate option on the Placement page (not a Guided resilience type). It also deploys a single node with RF 1 and skips Guided and Expert mode.

Guided mode

In Guided mode, start by selecting the cluster's resilience and the number of outages (1, 2, or 3) you want the cluster to tolerate without downtime. YugabyteDB Anywhere then requires a matching number of regions, availability zones, and nodes, and applies replication factor automatically (RF = 2 × outages + 1).

On Kubernetes, node-level resilience is labeled Pod.

All availability zones have the same number of nodes. You cannot set per-zone counts in Guided mode; switch to Expert if you need that.

After you set resilience, select regions, then assign availability zones and the number of nodes per zone. For multi-region clusters, optionally rank preferred availability zones.

Region

• YugabyteDB can continue to do reads and writes even in case of a cloud region outage.
• Requires exactly 3, 5, or 7 regions (matching the outage count you chose). You cannot use 2, 4, or 6 regions, or more than 7.
• Each region typically contributes one availability zone; you cannot add extra zones in Guided region-level placement.
• Recommended for production deployments that must survive a region outage.

Availability zone

• YugabyteDB can continue to do reads and writes even in case of a cloud availability zone outage.
• Requires exactly 3, 5, or 7 availability zones, in one or more regions. You cannot select more regions than the required zone count.
• Not resilient to region outages (unless your zones happen to span enough regions to survive a region failure — Expert can express some of those layouts more directly).
• Recommended for production deployments that must survive a data center or zone outage.

Because cloud providers typically provide only 3–4 availability zones per region, surviving more than one zone outage in a single region usually requires placing zones in additional regions.

Node

• YugabyteDB can continue to do reads and writes even in case of node outage, but this configuration is not resilient to availability zone or region outages.
• Exactly one region and one availability zone.
• Minimum of 3, 5, or 7 nodes in that zone (matching the outage count).
• On Kubernetes, this is pod-level resilience.

None

• Minimum of 1 node, with no replication.
• Operations that require a restart result in downtime (no rolling restart is possible).
• For development and testing only.

Expert mode

In Expert mode, start by selecting one or more regions, then set the replication factor and place nodes in availability zones. YugabyteDB Anywhere infers resilience from the combination of regions, zones, nodes, and RF (for example, RF 3 across 3 regions is region-level; RF 3 across 3 zones in one region is zone-level; RF 3 in a single zone is node-level).

Expert mode gives you more control, with the following rules:

• RF must be 1, 3, 5, or 7. RF 1 is not resilient to outages and is subject to downtime during operations that require a restart.
• RF must be greater than or equal to the number of regions you selected. For example, 3 regions requires RF 3, 5, or 7.
• You cannot place more availability zones than the RF. To add more zones, increase RF first.
• Total nodes must be at least the RF. RF N requires either N availability zones or at least N total nodes across zones.
• You can set a different node count in each availability zone.
• You must select an availability zone for every zone row; blank zone selections are not allowed.
• Maximum RF is 7, so you cannot place nodes in more than 7 regions.

Use Expert when Guided cannot represent the topology you need. For example, different node counts per zone, two regions with zones distributed in a way Guided does not allow, or setting RF independently of a Guided resilience preset.

If you switch from Expert to Guided and the current placement is not a Guided-supported topology (for example, uneven node counts per zone), YugabyteDB Anywhere warns you and resets the placement configuration.

Preferred region

You can rank availability zones so tablet leaders sit close to your application. Give every zone in a region the same rank to prefer that region. See Preferred region and leader affinity.

Preferred ranking controls where tablet leaders are elected. It does not change replica placement, replication factor, or where dedicated YB-Master processes run. Non-preferred zones still host tablet followers. When no zone is ranked, leader balancing spreads leaders across the universe.

For lower latency, rank the zone or region closest to the application as 1. If the application uses a smart driver, set the topology keys to match.

Ranks must be contiguous integers starting at 1. Zones with the same rank share leaders. Unranked zones are used only if no higher-ranked zone is available.

For example, a primary cluster in us-east, us-central, and us-west with the application in us-east: rank us-east 1, us-central 2, and us-west 3. If us-east fails, followers in us-central become leaders. See Global database.

You can enable follower reads to serve reads from non-preferred regions. If a client connects to a read replica, reads are served from the replica; writes still go to tablet leaders in the preferred region.

Dedicated masters

For universes with many databases or very large table counts, place YB-Master processes on dedicated nodes. The number of master nodes is equal to the replication factor.

Dedicated master placement is available for AWS, GCP, Azure, OCI, and on-premises; it is not supported on Kubernetes. Refer to Dedicated YB-Masters.

Changing placement

After the universe is created, you can change placement (regions, zones, and nodes). Refer to Scale universes.

The following limitations apply when editing an existing universe:

• You can increase replication factor (or Guided resilience that increases RF), but you cannot decrease it. Increasing RF may also require more nodes or availability zones. Contact Yugabyte Support for help with capacity planning.
• If the current placement is not a topology Guided supports, Guided mode is unavailable and you must use Expert.

Read replicas and other advanced placement options are configured after the primary universe is created. Refer to Add a read replica.

Hardware

The size of the universe is based on the instance type (vCPUs, memory, and disk) and the number of nodes. For the universe to be resilient, you need a minimum of 3 nodes.

For production universes, a minimum of 3 nodes with 4 to 8 vCPUs per node is recommended.

During an update, one node is always offline. When sizing your universe to your workload, ensure you have enough additional capacity to support rolling updates with minimal impact on application performance.

If your configuration doesn't match your performance requirements, you can scale your universe after it is created. You can increase the number of vCPUs per node (scale up, also referred to as vertical scaling), as well as the total number of nodes (scale out, also referred to as horizontal scaling). You can also increase the disk size per node. In some cases, instance type and disk size changes can be applied as a smart resize without migrating data.

YugabyteDB recommends vertical scaling until nodes have 16 vCPUs, and horizontal scaling once nodes have 16 vCPUs. For example, for a 3-node universe with 4 vCPUs per node, scale up to 8 vCPUs rather than adding a fourth node. For a 3-node universe with 16 vCPUs per node, scale out by adding a 4th node.

When creating the universe, you also choose CPU architecture (x86 or ARM) and, for cloud providers, the Linux version from the provider configuration's catalog. For airgapped installations, use a custom image; you cannot use YugabyteDB Anywhere-managed Linux versions. Refer to Create universes.

For Kubernetes, set cores, memory, and volume size for TServer and Master separately rather than selecting a cloud instance type.

YugabyteDB version

Universes are created using a YugabyteDB release that is available in your YugabyteDB Anywhere instance. You choose the version when you create the universe.

Use a version from the stable release series, and prefer an LTS release for production.

If the version you want is not listed, import it into YugabyteDB Anywhere. Refer to Manage YugabyteDB releases.

You manage upgrades. For multi-node universes, YugabyteDB Anywhere performs a rolling upgrade without downtime. For production universes, validate upgrades on a staging universe first.

Staging universe

Use a staging universe for the following tasks:

• Verifying that your application is compatible with database updates.
• Ensuring that your application correctly handles a rolling restart of the database without errors.
• Testing new features. Use your staging (also known as development, testing, pre-production, or canary) environment to try out new database features while your production systems are still running a previous version.
• Testing scaling operations and disaster recovery. Find out how your environment responds to a scaling operation, outages, or the loss of a node.

Create a staging universe and configure your staging environment to connect to it. The staging universe can be smaller than your production universe, but you need to ensure that it has enough resources and capacity to handle a reasonable load. Single-node and RF 1 universes are too limited for staging.

When you plan an upgrade, upgrade and validate the staging universe before upgrading production. If you identify a performance problem or regression, postpone the production upgrade and contact Yugabyte Support.

Backups

YugabyteDB Anywhere does not back up universes until you configure backup storage and a backup schedule. Do this before going to production.

You can also perform on-demand backups, incremental backups, and point-in-time recovery.

Don't schedule backups during maintenance windows or periods of heavy traffic. Refer to Back up universes.

For region-level disaster recovery, use xCluster Disaster Recovery in addition to backups.

Security

YugabyteDB Anywhere universes are not automatically exposed to the public internet. Restrict access so that only YugabyteDB Anywhere, application servers, and database administrators can reach universe nodes. Refer to Networking.

When you create a universe, configure the following:

• Network access. Optionally assign public IPs (AWS, GCP, Azure, OCI). For Kubernetes, you can enable IPv6.

• Encryption in transit. Encrypt node-to-node and client-to-node traffic using a YugabyteDB Anywhere-generated or customer-managed certificate. Client-to-node encryption requires node-to-node encryption. Refer to Encryption in transit.

• Encryption at rest. Encrypt universe data using a KMS configuration. Refer to Encryption at rest.

• Database authentication. Enable YSQL and YCQL authentication and set the admin password. Save the password; it is not stored in YugabyteDB Anywhere.

  After the universe is provisioned, add users and restrict their access. Refer to Database authorization.

  YugabyteDB Anywhere also supports LDAP and OIDC for database authentication. Refer to Database authentication.

Next steps

• Create a universe