Sign inTry Free

Manage Clusters

On this page

A cluster is owned by an organization, and members of the organization can create, scale, and terminate clusters.

Create a Cluster

To create a cluster, in the left navigation pane, select Create New > Cluster. Follow the provided instructions. A cluster cannot be renamed.

Note that the cluster admin password is configured when the cluster is first created. SingleStore recommends that you save this password as you will need it to log into the database outside of the Cloud Portal, such as when using a SQL client. This is also referred to as the “Master Username” in the Cloud Portal, which is admin by default.

Opt-in to Preview Features & Updates

When enabling this option, the deployment receives the latest features and updates as soon as they are available. The configuration is suitable only for non-production deployments and cannot be changed after creation.

Perform the following steps to get access to the Preview Features.

  1. In the Cloud Portal, select Create New > Cluster.

  2. Under Advanced Settings, enable Opt-in to Preview Features & Updates.

View Database Storage Usage and Cost

To view a database’s storage usage and cost:

  • Navigate to the organization name in the left navigation pane: (ORG:) > Billing & Usage > Usage Estimate > Storage Usage to view storage used.

  • Navigate to the organization name at the top (ORG:) > Billing & Usage > Usage Estimate > Billable > Storage Billed On-Demand (Average Monthly GB) to view the monthly storage cost.

  • Note that the storage cost is billed in US dollars ($) and the storage price is dependent on the deployment region that was selected when the database was created.

Resize a Cluster

Cluster size can be modified by simply selecting another size in the Cloud Portal.

To resize a cluster,navigate to Clusters, select the three dots under the Actions column, and select Resize & Scale from the list.

Resizing operations may require provisioning new instances from the cloud provider, and delays in availability can affect the overall completion time. Active workloads can further increase scaling duration.

SingleStore recommends completing or minimizing active workloads before initiating resize operations. When reducing the size, ensure the new size can accommodate the existing workload. For example, when scaling down from S-4 to S-1, utilization must be below 25% to ensure a smooth scale-down process.

Estimated times are not guaranteed and may vary depending on cloud provider provisioning and cluster workload.

Suspend and Resume a Cluster

Clusters do not need to be running when there is no active workload querying a database. To save cost, clusters can be suspended when inactive. 

Databases will be retained as long as the Cluster Group containing the database exists.

Note

Backup operations in SingleStore Helios fail if a cluster is in the process of resuming, suspending, or terminating. Starting a backup during these state transitions interrupts the operation and returns the following error:

ERROR 1317 ER_QUERY_INTERRUPTED: Leaf Error: Query execution was interrupted

Suspend a Cluster

To suspend the cluster, navigate to Clusters, select the three dots under the Actions column, and select Suspend. Users and Firewall rules will be retained.

While suspending a cluster, the system does not forcefully terminate or block active workloads. To avoid delays, SingleStore recommends stopping or pausing all workloads before initiating the suspend operation. If workloads remain active, the suspended operation may take significantly longer to complete.

Resume a Cluster

To resume a suspended cluster, navigate to Clusters and select Resume under the Actions column for the cluster. Resume operations may take a few minutes to attach databases and come online.

Resume operations may take a few minutes to attach databases and come online. Resume times can vary as cloud providers provision instances at different speeds. These provisioning delays occur within the cloud provider’s infrastructure layer and are not deterministically controlled by SingleStore. Therefore, consistent resume times are not guaranteed.

Auto Suspend a Cluster

Auto suspend allows you to configure a cluster to automatically suspend either after a set period of time or after a period of inactivity. It can be configured on an existing cluster, or set at the time of creation.

There are two types of auto suspend: Idle and Scheduled. Only one type can be enabled at a time.

  • Idle: the cluster will get suspended after X seconds of engine inactivity. The time only takes effect from the point when the settings are enabled. For example, if you set it for 30 minutes but the cluster already has an engine idle time of one hour before the settings are enabled, then the cluster will get suspended only after 30 minutes from the time the settings are enabled.

  • Scheduled: the cluster will get suspended after X seconds have passed, irrespective of its activity. (Note: this type of auto-suspend is not available for Trial users.)

The task that auto-suspends the clusters runs every 5 minutes, so there can be a maximum difference of five minutes between the time when the cluster should be suspended and when it will actually get suspended.

Once a cluster is resumed, you can either keep the previous auto-suspend settings or disable them. The default behavior keeps the previous settings.

The default auto-suspend settings at the time of cluster creation are:

  • For trial users, the settings are enabled by default to 20 minutes of idle time.

  • For standard users, the settings are disabled by default.

Note

When a cluster resumes from auto-suspend, SingleStore Helios requests new compute capacity from the cloud provider. Capacity availability depends on the provider and may not be immediate, which can delay cluster resume operations.

Terminate a Cluster

To terminate a running cluster, navigate to Clusters, select the three dots under the Actions column, and select Terminate from the list.

Data Retention in SingleStore Helios Service Post Termination

Encrypted data from terminated deployments is automatically and securely purged from all systems on termination, and any administrative backup data is purged within 14 days. Hence, it is not possible to recover data from a terminated deployment. If you need to retain data post-termination, SingleStore recommends that you back up your data to an external object storage bucket.

Cloud Workload Identity and Delegated Entities

Cloud Workload Identity represents a set of Kubernetes and AWS resources and configurations that are provisioned for each cluster. It enables cluster workloads, such as pipelines, to use IAM Roles for Service Accounts (IRSA) to access cloud resources without long‑lived static credentials. Workloads can use this identity to authenticate to cloud provider services without storing or rotating static credentials. Refer to Cloud Workload Identity and Delegated Entities for more information.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In