Hosting models overview
To allow for reliable resource allocation, Cloud Databases offers two hosting models; Shared Compute and Isolated Compute. Cloud Databases Shared Compute is a flexible option for your database deployment that preserves performance predictability. Cloud Databases Isolated Compute is our recommendation for production enterprise applications, providing more precise control and enterprise features.
Scaling your Shared Compute or Isolated Compute databases is currently available via the CLI, API, or Terraform only.
Cloud Databases Isolated Compute
Isolated Compute is a secure single-tenant offering for complex, highly performant enterprise workloads. By placing your deployment and all associated user-data management agents on an isolated machine, Cloud Databases Isolated Compute provides dedicated computing resources, dedicated storage bandwidth, and hypervisor-level isolation.
When provisioning, choose an initial host size for your instance. Storage is still selected separately, allowing you to determine the size of disk and number of IOPSA standard computing benchmark used to determine the best configuration settings for servers. your database receives.
CPU and RAM autoscaling is not supported on Isolated Compute. Disk autoscaling is available. If you provisioned an isolated instance or switched over from a deployment with autoscaling, monitor your resources using IBM Cloud® Monitoring integration, which provides metrics for memory, disk space, and disk I/O utilization. To add resources to your instance, manually scale your deployment.
Isolated Compute sizing
Isolated Compute features 6 size selections:
- 4 CPU x 16 RAM
- 8 CPU x 32 RAM
- 8 CPU x 64 RAM
- 16 CPU x 64 RAM
- 32 CPU x 128 RAM
- 30 CPU x 240 RAM
Cloud Databases Isolated Compute
Isolated Compute is a secure single-tenant offering for complex, highly-performant enterprise workloads. By placing your deployment and all associated user-data management agents on an isolated machine, Cloud Databases Isolated Compute provides dedicated computing resources, dedicated storage bandwidth, and hypervisor-level isolation.
When provisioning, choose the CPU x RAM size for the machine to set up your database. This machine will be exclusively assigned to running your database instance. Storage is still selected separately, allowing you to determine the size of disk and number of IOPSA standard computing benchmark used to determine the best configuration settings for servers. your database receives. Scale your database and change your machine size using your preferred method: the Cloud Databases CLI plug-in, the Cloud Databases API, or using Terraform.
Isolated Compute sizing
Isolated Compute features 6 size selections:
- 4 CPU x 16 RAM
- 8 CPU x 32 RAM
- 8 CPU x 64 RAM
- 16 CPU x 64 RAM
- 32 CPU x 128 RAM
- 30 CPU x 240 RAM
The host_flavor
parameter defines your Compute sizing. Input the appropriate value for your desired size. To provision a Shared Compute instance, specify multitenant
. All other options place you on different Isolated
Compute sizes.
Host flavor | host_flavor value |
---|---|
Shared Compute | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.encrypted |
Cloud Databases Isolated Compute
Isolated Compute is a secure single-tenant offering for complex, highly-performant enterprise workloads. By placing your deployment and all associated user-data management agents on an isolated machine, Cloud Databases Isolated Compute provides dedicated computing resources, dedicated storage bandwidth, and hypervisor-level isolation.
When provisioning, choose the CPU x RAM size for the machine to set up your database. This machine will be exclusively assigned to running your database instance. Storage is still selected separately, allowing you to determine the size of disk and number of IOPSA standard computing benchmark used to determine the best configuration settings for servers. your database receives. Scale your database and change your machine size using your preferred method: the Cloud Databases CLI plug-in, the Cloud Databases API, or using Terraform.
Isolated Compute sizing
Isolated Compute features 6 size selections:
- 4 CPU x 16 RAM
- 8 CPU x 32 RAM
- 8 CPU x 64 RAM
- 16 CPU x 64 RAM
- 32 CPU x 128 RAM
- 30 CPU x 240 RAM
The host_flavor
parameter defines your Compute sizing. Input the appropriate value for your desired size. To provision a Shared Compute instance, specify multitenant
. All other options place you on different Isolated
Compute sizes.
Host flavor | host_flavor value |
---|---|
Shared Compute | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.encrypted |
Cloud Databases Isolated Compute
Isolated Compute is a secure single-tenant offering for complex, highly-performant enterprise workloads. By placing your deployment and all associated user-data management agents on an isolated machine, Cloud Databases Isolated Compute provides dedicated computing resources, dedicated IO and network bandwidth, and hypervisor-level isolation.
When provisioning, choose the CPU x RAM size for the machine to set up your database. This machine will be exclusively assigned to running your database instance. Storage is still selected separately, allowing you to determine the size of disk and number of IOPSA standard computing benchmark used to determine the best configuration settings for servers. your database receives. Scale your database and change your machine size using your preferred method: the Cloud Databases CLI plug-in, the Cloud Databases API, or using Terraform.
CPU and RAM autoscaling is not supported on Cloud Databases Isolated Compute. Disk autoscaling is available. If you provisioned an isolated instance or switched over from a deployment with autoscaling, monitor your resources using IBM Cloud® Monitoring integration, which provides metrics for memory, disk space, and disk I/O utilization. To add resources to your instance, manually scale your deployment.
Isolated Compute sizing
Isolated Compute features 6 size selections:
- 4 CPU x 16 RAM
- 8 CPU x 32 RAM
- 8 CPU x 64 RAM
- 16 CPU x 64 RAM
- 32 CPU x 128 RAM
- 30 CPU x 240 RAM
The host_flavor
parameter defines your Compute sizing. Input the appropriate value for your desired size. To provision a Shared Compute instance, specify multitenant
. All other options place you on different Isolated
Compute sizes.
Host flavor | host_flavor value |
---|---|
Shared Compute | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.encrypted |
Isolated Compute capacity
Isolated Compute fully isolates your database, including database management pods (which touch user data). These management pods take up some overhead in your isolated compute instance, consuming a portion of the machine's compute. The following table shows the estimated remaining compute for each Isolated Compute size.
Host flavor | CPU remaining | RAM remaining |
---|---|---|
4 CPU x 16 RAM | 2.865 | 12.193 |
8 CPU x 32 RAM | 6.855 | 26.952 |
8 CPU x 64 RAM | 6.855 | 56.519 |
16 CPU x 64 RAM | 14.835 | 56.519 |
32 CPU x 128 RAM | 30.795 | 115.738 |
30 CPU x 240 RAM | 28.8 | 223.596 |
Provisioning
To provision a Cloud Databases service instance, select your hosting type from either Shared Compute or Isolated Compute.
To provision a Cloud Databases service instance, add a new host_flavor
parameter. This parameter allows you to select either Shared Compute (multitenant
) or Isolated Compute via assigning the parameter value for the
requested Isolated instance size. Note that because Isolated Compute sizes implicitly include both CPU and RAM allocations, CPU and RAM sizes should not be provided with an Isolated Compute request.
To provision a Cloud Databases service instance, add a new host_flavor
parameter. This parameter allows you to select either Shared Compute (multitenant
) or Isolated Compute via assigning the parameter value for the
requested Isolated instance size. Note that because Isolated Compute sizes implicitly include both CPU and RAM allocations, CPU and RAM sizes should not be provided with an Isolated Compute request.
To provision a Cloud Databases service instance, add a new host_flavor
parameter. This parameter allows you to select either Shared Compute (multitenant
) or Isolated Compute via assigning the parameter value for the
requested Isolated instance size. Note that because Isolated Compute sizes implicitly include both CPU and RAM allocations, CPU and RAM sizes should not be provided with an Isolated Compute request.
For more detailed instructions, see your database specific page.
Scaling and switching between hosting models
For new hosting models, scaling and switching are similar operations. While scaling your database as you normally would, select a different hosting type from what your database instance is currently placed on to switch to and between Shared and Isolated Compute.
For new hosting models, scaling and switching are similar operations. While scaling your database as you normally would, switch to and between hosting models by adding a new host_flavor
parameter set to the hosting model you wish
to scale to. Then, moving to the hosting type is as simple as running a scale command with this hosting flavor targeted.
For new hosting models, scaling and switching are similar operations. While scaling your database as you normally would, switch to and between hosting models by adding a new host_flavor
parameter set to the hosting model you wish
to scale to. Then, moving to the hosting type is as simple as running a scale command with this hosting flavor targeted.
For new hosting models, scaling and switching are similar operations. While scaling your database as you normally would, switch to and between hosting models by adding a new host_flavor
parameter set to the hosting model you wish
to scale to. Then, moving to the hosting type is as simple as running a scale command with this hosting flavor targeted.
For more detailed instructions, commands, and parameters, see your database-specific page.
Note that switching hosting models does not cause downtime, as this is not a backup and restore migration. Instead, the same process is applied as for updates or database instance scaling, where database processes will perform a rolling restart. We recommend ensuring that your application has retry and reconnect login in place to immediately re-establish a connection, as existing connections will be dropped during this time.
Choosing between hosting models
Isolated Compute | Shared Compute |
---|---|
Single-tenanted databases with dedicated storage bandwidth. Database management agents are placed on isolated machine. | Multi-tenanted, logically separated databases sharing bandwidth. Database management pods are also multi-tenanted. |
Receive all the available resources in your machine. | Transparent, deterministic CPU allocation. Know exactly what your performance will be and scale up and down as your workload requires. |
Some of our database offerings, such as MongoDB Enterprise and Elasticsearch Platinum, will be solely provisioned on Isolated Compute. Future enhancements, such as cross-region replication may be supported solely on Isolated Compute. | Excludes some database offerings, such as MongoDB Enterprise and Elasticsearch Platinum. |
Scalability is based on provided machine sizes. | Scalability is fine-grained and linear from a database-specific minimum configuration up to 28 CPU and 112 GB RAM. |
Databases availability by hosting model
The following table shows which model is available for each database.
Shared Compute | Isolated Compute | |
---|---|---|
PostgreSQL | ||
MongoDB Standard | ||
MongoDB Enterprise | ||
Redis | ||
Elasticsearch Enterprise | ||
Elasticsearch Platinum | ||
MySQL | ||
RabbitMQ | ||
EnterpriseDB | ||
etcd |