Create a Workspace

Workspace s can be created through the Cloud Portal UI or the Management API. The following functions are available via these management interfaces.

• Create

• Connect

• Create or drop a database

• Attach or detach a database

Connecting to a workspace

Each workspace provides a connection endpoint that you can use to connect from a client, an IDE, or an application. You can also use the SQL Editor in the Cloud Portal to connect and run queries directly.

SingleStore Helios provides a Classless Inter-Domain Routing (CIDR) allowlist to restrict the networks that can access a workspace. This can be defined by editing the IP Allowlist for a workspace. Refer to IP Address Allowlisting for more information.

Resize or Scale a Workspace

Workspace can be resized or scaled by changing the size or scale factor in the Cloud Portal or Management API.

Resizing a workspace changes the base compute configuration to provision greater or fewer resources (vCPU & memory). This option should be used when the change is expected to be persisted for a period of time. Data is redistributed within the cache for optimal performance. When the operation is running there may be a temporary reduction in performance due to resources being dynamically added or removed.

For large deployments with heavy active workloads the time required to complete the resizing operation may increase as a larger volume of active data needs to be redistributed within the deployment. The resize operation and data rebalancing will continue in the background while the workload is running, so no extra steps need to be taken to ensure the job completes.Resizing can be performed through the Management API by using WorkspaceUpdate size.

Scaling a workspace adds additional compute and memory without changing the base configuration. This is ideal for situations where additional compute is needed for shorter periods of time. No data is moved in this configuration, allowing operations to complete more quickly.

Scaling can be performed through the Management API by using WorkspaceUpdate scaleFactor.

Autoscaling

Autoscaling is ideal for dynamic workloads where the user does not know when peaks in workload may occur and can be turned on or off for each compute deployment independently. Autoscaling tracks the active workload and automatically scales based on compute and memory usage. When the workload requests more vCPU or memory than is available, autoscaling will automatically add compute resources on the fly. If the workload decreases and the additional compute is no longer needed, autoscaling will return to the base size.

While many databases limit autoscaling to read-replicas, SingleStore has implemented autoscaling to provide both enhanced write and read performance.

When configuring autoscaling users can turn the feature on or off, and set the maximum amount of vCPU and Memory to be provisioned (2x or 4x of the base amount).

If set to 4x,  autoscaling increases resources incrementally, first scaling to 2x, and if necessary, then to 4x. The scaling threshold checks are the same (for example, 1x -> 2x checks are exactly the same as 2x -> 4x). The same applies to scaling down. It first scales from 4x to 2x and then to 1x.

The default settings for autoscaling may not fit every workload. Some workloads can benefit from a shorter sample duration, while others benefit from a longer duration to prevent unnecessary scaling.

Autoscaling provides three sensitivity levels to handle a workload. The default recommended setting is Normal.

1. Low: This is a more conservative scaling, which uses 15 min sampling and 30 minute cooldown.

2. Normal: This is the standard configuration, which uses 5 min sampling and 10 minute cooldown.

3. High: This level is the most sensitive scaling, which uses 3 min sampling and 5 minute cooldown.

The Low setting can be used when scaling should happen only after sufficient workload has been running for the 15-minute sampling period. This prevents the occurrence of scaling up when there are short spikes of load followed by a drop in CPU utilization.

The High setting is recommended when workloads are most dynamic and scaling should occur as often as needed, with minimal cooldown before returning to the base scale factor.

Cache Configuration

The Cache Configuration allows SingleStore to leverage greater volumes of Persistent Cache to increase the amount of data (the working set) that can be accessed with extremely low latency.Increasing the cache configuration, for example from “1x” to “2x” or “4x”), will increase the overall volume of the cache, and automatically distribute data within the cache. As data is automatically redistributed for optimal performance, typically this operation will take between minutes and hours, depending on the volume of data.

This operation runs online and data is available throughout the reconfiguration process. Cache configurations can be increased or decreased as desired.

Cache Configuration can be updated through the Management API with WorkspaceUpdate cacheConfig. Refer to Management API Overview for more information.

Suspend and Resume a Workspace

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

Options:

• Suspend: Compute resources will not be billed while a workspace is suspended

• Resume: Resume re-provisions compute resources for the workspace

• Auto-suspend: Suspend after a set period of time, or after a period of inactivity

Databases are retained even when workspaces are suspended.

Terminate a Workspace

Workspaces can be terminated when they are no longer needed.

Post-Termination Data Retention

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 store (such as a bucket).

Updates

Scheduled updates are applied to each workspace based on the update window assigned to the group. Updates are applied to all workspaces in a group simultaneously during the scheduled window.

Workloads that receive updates independently should be run in separate workspace groups to ensure independent schedules. For example, development and production workspaces should run in separate groups, thereby ensuring updates are applied to development before production.

Opt-in to Preview Features & Updates

When creating a workspace, this option enables the latest features and updates to be applied as soon as they are available. The configuration is suitable only for non-production deployments and cannot be changed after creation.

Example Workloads

• Run a SaaS application and operational analytics application on shared production data

• Deploy a workspace for batch reporting or one-time jobs on existing data, and terminate it when the work is complete

• Use application data from production to power new AI applications

Sharing Databases Across Applications

Example: Customer App Plus Operational Analytics Reporting

In the following examples, S-XX indicates the workspace size; the number of vCPUs and amount of memory available for a workload.

Additional workspaces can be quickly created and attached to the same database whenever there is a need.

• Serve the customer application from "App Workspace (App WS)" (R/W).

• Create a temporary "Reporting Workspace (Reporting WS) " to generate real-time insights.

  • Attach the database for reporting (R/O).

  • Run the reporting application.