Planning a cluster
Before deploying a production cluster, you need to consider the following factors.
Best practices
The following best practices are recommended for production clusters.
| Feature | Recommendation |
|---|---|
| Provider and region | Deploy your cluster in a virtual private cloud (VPC), with the same provider and in the same region as your application VPC. YugabyteDB Managed supports AWS and GCP. You need to create the VPC before you deploy the cluster. Refer to VPC network. |
| Fault tolerance | Availability zone (AZ) level - minimum of three nodes across multiple AZs, with a replication factor of 3. |
| Sizing | For most production applications, at least 3 nodes with 4 to 8 vCPUs per node. When scaling your cluster, for best results increase node size up to 16 vCPUs before adding more nodes. For example, for a 3-node cluster with 4 vCPUs per node, scale up to 8 or 16 vCPUs before adding a fourth node. |
| YugabyteDB version | Use the Stable release track. |
| Backups | Use the default backup schedule (daily, with 8 day retention). |
| Security and authorization | YugabyteDB Managed clusters are secure by default. After deploying, set up IP allow lists and add database users to allow clients, applications, and application VPCs to connect. Refer to IP allow lists. |
In depth
Provider and region
Provider
YugabyteDB Managed supports AWS and GCP. Your choice of provider will depend primarily on where your existing applications are hosted. YugabyteDB Managed pricing is the same for both.
Region
For best performance as well as lower data transfer costs, you want to minimize transfers between providers, and between provider regions. Do this by locating your cluster as close to your applications as possible:
- Use the same cloud provider as your application.
- Locate your cluster in the same region as your application.
For lowest possible network latency and data transfer costs, deploy your cluster in a VPC on the same cloud provider as your application VPC and peer it with the application VPC. This configuration also provides the best security.
For a list of supported regions, refer to Cloud provider regions.
Fault tolerance
The fault tolerance determines how resilient the cluster is to node and cloud zone failures. YugabyteDB Managed provides the following options for providing replication and redundancy:
-
Availability zone level. Includes a minimum of 3 nodes spread across multiple availability zones with a replication factor (RF) of 3. YugabyteDB can continue to do reads and writes even in case of a cloud availability zone failure. This configuration provides the maximum protection for a data center failure.
-
Node level. Includes a minimum of 3 nodes deployed in a single availability zone with a RF of 3. YugabyteDB can continue to do reads and writes even in case of a node failure, but this configuration is not resilient to cloud availability zone outages.
-
Region level. Yugabyte supports multi-region clusters with regional fault tolerance. Contact Yugabyte Support for help configuring regional fault tolerance.
Although you can't change the cluster fault tolerance after the cluster is created, you can scale horizontally as follows:
- For Availability zone level, you can add or remove nodes in increments of 3.
- For Node level, you can add or remove nodes in increments of 1.
For production clusters, Availability zone level is recommended.
For application development and testing, you can set fault tolerance to None to create a single-node cluster. Single-node clusters can't be scaled.
Sizing
The size of the cluster is based on the number of vCPUs. The basic configuration for YugabyteDB Managed clusters includes 2 vCPUs per node. Each vCPU comes with 50GB of storage. A node has a minimum of 2 vCPUs, and 2GB of RAM per vCPU. For the cluster to be fault tolerant, you need a minimum of 3 nodes.
Depending on your performance requirements, you can increase the number of vCPUs per node, as well as the total number of nodes. You can also increase the disk size per node. However, once increased, you can't lower the disk size per node.
YugabyteDB Managed supports both vertical and horizontal scaling. If your configuration doesn't match your performance requirements, you can change these values after the cluster is created (increasing or decreasing vCPUs and increasing storage, and adding or removing nodes). Refer to Scaling clusters.
For production clusters, a minimum of 3 nodes with 4 to 8 vCPUs per node is recommended.
YugabyteDB version
By default, clusters are created using a stable release, taken from the stable release series of YugabyteDB.
You can choose to deploy your cluster using a preview release for development and testing. YugabyteDB Managed database preview releases are typically taken from the preview release series of YugabyteDB, though they can also include a recently released stable release.
If you need a feature from a preview release (that isn't yet available in a stable release) for a production deployment, contact Yugabyte Support before you create your cluster.
Yugabyte manages upgrades for you. After you choose a track, database upgrades continue to take releases from the track you chose. For multi-node clusters, Yugabyte performs a rolling upgrade without any downtime. You can manage when Yugabyte performs maintenance and upgrades by configuring the maintenance window for your cluster.
Backups
YugabyteDB Managed provides a default recommended backup schedule (daily, with 8 day retention), and manages backups for you. You can change the default schedule, as well as perform on-demand backups.
YugabyteDB Managed performs full cluster (all namespaces) level backups, and the backups are stored in the same region as your cluster. 100GB/month of basic backup storage is provided for every vCPU; more than that and overage charges apply. Refer to Backup storage costs.
Security
Clusters are secure by default. You need to explicitly allow access to clusters by adding IP addresses of clients connecting to the cluster to the cluster IP allow list. Refer to IP allow lists.
If your applications are running in a VPC, deploy your cluster in a VPC to improve security and lower network latency. You also need to add the CIDR ranges of any application VPCs to your cluster IP allow list. You need to create the VPC before you deploy the cluster. YugabyteDB Managed supports AWS and GCP for VPCs. Refer to VPC network.
User authorization
YugabyteDB uses role-based access control to manage database access. When you create a cluster, YugabyteDB Managed adds a default admin user (the credentials for this user are configurable).
After the cluster is provisioned, create a new database and add users. You can create users specific to each connecting application, and restrict their access accordingly.
Note
In YSQL, the admin user is not a full superuser. For security reasons, you do not have access to the Yugabyte or Postgres superusers, nor can you create users with superuser privileges.For more information on users and roles in YugabyteDB Managed, refer to Database authorization in YugabyteDB Managed clusters.
Pricing
The biggest factor in the price of a cluster is the number vCPUs.
Cluster charges are based on the total number of vCPUs used and how long they have been running. Cluster per-hour charges include free allowances for disk storage, backup storage, and data transfer. If you use more than the free allowance, you incur overages on top of the base vCPU capacity cost.
Before creating a cluster, you need to create your billing profile and add a payment method. Refer to Manage your billing profile and payment method.
If you're interested in evaluating YugabyteDB Managed for production use and would like trial credits to conduct a proof-of-concept (POC), contact Yugabyte Support.