The IBM Cloud® Databases team focuses on providing hassle-free availability, reliability and security. In accordance with these values, we are making improvements to our hosting model to align with industry practices and improve the predictability of performance for our clients. This will apply to all IBM Cloud Database instances. 

Those familiar with our databases know that when provisioning, users can select between a database with dedicated cores allocated to their instance, or a database placed on a multi-tenant machine, where cores are shared with other tenants. As part of our continuous effort to improve usability, we are moving to more clearly differentiated hosting choices: Isolated Compute and Shared Compute.  

Isolated Compute, our single-tenant offering, brings a focus on isolation by placing your database and all associated user-data operations on its own virtual machine. Shared Compute comes directly from your feedback, and improves our existing multi-tenant offering by delivering predictable performance while maintaining separation through logically separated tenants.  

Choosing between hosting models 

We’re incredibly excited to bring you Isolated Compute, and it is our recommended hosting model for Enterprise workloads. However, when Shared Compute suits you better, switching back and forth between our models is easy. Just select the model you want, review your resource selection and switch. 

Introducing: Shared Compute 

Prefer a multi-tenant infrastructure with free-form resource allocations? Just like the current multi-tenant model, the new shared model also uses shared worker nodes; IBM Cloud Databases ensures that each separate customer database is logically separated for data isolation and security.  

Based on your feedback, we implemented the Shared Compute model to also maintain predictable and transparent performance.  

When provisioning a Shared Compute instance using  API, CLI, or Terraform, if no CPU amount is specified, ICD will automatically allocate a small amount of CPU to your database up to a 2 CPU max. Automatic CPU is provided at a 1:8 ratio of CPU:RAM; therefore, a user with 4 GB RAM receives 4/8th of a CPU; a user with 8 GB RAM receives 1 CPU; and a user with 20 GB RAM receives 2 CPU due to the 2 CPU limit. If you have higher performance requirements than 2 CPU, you can easily leverage the flexibility of the shared model. With the ability to select the amount of CPU and RAM resources you receive, performance can be scaled to fit your workload.  

When provisioning a Shared Compute instance using the UI, select from the Small allocation preset to test the smallest available size, or Custom allocation preset for flexible selections above 2 CPU.  

Additionally, if you know that your instance will experience variable demand, use RAM autoscaling to set not only the expected load and duration that would initiate resource scaling, but also the resource and cost limit your database will scale to.  

Shared Compute allows for granular resource requests. To ensure that your databases still have enough resources for entry-level functionality, there are minimum resource requirements as follows:  

• RabbitMQ: 1 CPU x 8 GB RAM 
• All other database offerings: 0.5 CPU x 4 GB RAM 

Learn more about Shared Compute.  

Introducing: Isolated Compute 

Our Isolated model is the service for enterprise production workloads. When provisioning, select the specific size of the virtual machine to provision your database on—this machine will be dedicated to running this database instance, giving you hypervisor-level isolation between your instance and any other database. To strengthen isolation further, dedicated database management agents run alongside the database instance on the same isolated machines. 

Storage is still selected independently, allowing you to determine the storage and IOPS (input/output operations per second) your database receives, with this IO bandwidth also dedicated to your database instance. 

When you need a different usage amount, simply scale your database through your preferred method—UI, API, CLI, or Terraform—and change your worker size.  

Learn more about Isolated Compute.  

Transition timeline from existing hosting models 

For more information on the transition timeline from our current hosting models and minimum resource requirements, refer to our documentation, or dive further into pricing.