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 |
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 |
Transition timeline from existing hosting models to Isolated and Shared Compute
Multi-tenant users that are automatically transitioned to Shared Compute will be grandfathered, meaning that they get RAM and CPU increased to the Shared Compute minimum resource allocations, if required. These increases will not be charged until May 2025.
Starting August 2024, existing multi-tenant instances will begin the transition to Shared Compute; this means that first, RAM minimum allocation on multi-tenant instances will be applied (8 GB RAM for RabbitMQ, 4 GB RAM for all other databases), lifting the RAM of existing instances that fall below these minimums. All new provisioning requests will also have to abide to the minimum resource requirements (1 CPU and 8 GB RAM for RabbitMQ, 0.5 CPU and 4 GB RAM for all other databases). Existing dedicated core users will not be impacted by minimum resource requirements unless a scale or provision action is invoked on an instance that is currently below these minimums.
Following this, multi-tenant databases will be gradually transitioned from non-determinstic CPU allocation to the deterministic Shared Compute CPU allocation. Ahead of this transition, monitor your database's CPU usage to determine what allocation is required to maintain your current performance level.
Existing multi-tenant users will be grandfathered through to May 2025 for both CPU and minimum RAM resource allocations that are automatically added.
From September 2024, the transition of multi-tenant instance to shared compute will be complete. All new multi-tenant provisions are placed on Shared Compute. Dedicated cores provisioning remain available at this time.
In May 2025, we will transition dedicated core users to Isolated Compute and remove grandfathering for Shared Compute instances. All Dedicated Cores instances will be transitioned to the nearest larger Isolated Compute size. Dedicated Core instances can follow the simple switchover steps to transition to Isolated Compute at any time by using the Cloud Databases CLI plug-in, the Cloud Databases API, or through Terraform.
Notifications will be sent ahead of changes, including at the following times:
- Before the transition of multi-tenant to Shared Compute, to notify you of expected changes.
- After all multi-tenant instances are transitioned to Shared Compute resource allocations, to recommend that you review your database performance and adjust resources as necessary.
- Before final shutdown of dedicated cores and the transition to Isolated Compute. Additionally, before the end of grandfathering of Shared Compute instances. You can also find all notifications at IBM Cloud announcements.
Ahead of the May 2025 date, if you have a multi-tenant instance, there are a few exceptions where grandfathering would no longer apply:
- If you have an existing database and change your RAM allocation only, you will be charged corresponding to the RAM changes.
- If you have an existing database and change your CPU allocation, you will be charged for all CPU and RAM allocated to your database.
- If you create a new Shared Compute instance, you will be charged for all CPU and RAM allocated to your database.
- If you transition your multi-tenant instance yourself to Shared Compute, you will be charged for all CPU and RAM allocated to your database.