Workspaces Implementation

Each workspace is a part of a Workspace Group, which allows for the configuration and management of access, updates, and data sharing. Databases can be attached or detached from any workspace within a workspace group. Each group can contain up to five workspaces, and each database can have one R/W (read and write) and many R/O (read only) attachments.

Each workspace group is deployed in a cloud provider and region. An organization can have many workspace groups deployed across multiple cloud providers and regions.

Database Attachments and Data Replication

Databases can be attached to multiple workspaces simultaneously. Each database can have one R/W attachment and many R/O attachments. This allows data to be shared across isolated compute workloads.

For example, a customer-facing SaaS application is running on workspace 1 and writing data into DB01. An internal telemetry application running on workspace 2 is reading data from DB01. In this scenario, DB01 has an R/W attachment to workspace 1 and a R/O attachment to workspace 2.

Attachments are created on each database, and it is possible for a workspace to have a combination of R/W and R/O attachments.

Writes made to a database from a workspace with an R/W attachment will appear on workspaces with R/O attachments instantaneously. This is because SingleStoreDB does not require writes to go to object storage before being available on other workspaces for read queries.

SingleStoreDB has a data storage engine which synchronously replicates data between workspaces automatically in real-time. All new writes to a database are replicated instantaneously, allowing workspaces with R/O attachments to serve real-time workloads without waiting for data to load or going through complex ETL processes.

When attaching a database to a workspace as R/O all new data written will be replicated to the new workspace. When sizing the workspace ensure that the selected size can accommodate the size of the working data set. A very small workspace attaching a database with a large working set will not have sufficient resources to process reads against the database.

Workspace Groups Updates

Scheduled updates are applied to each workspace group based on the update window assigned. 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 update schedules. For example, development and production workspaces should run in separate groups. Thereby ensuring updates are applied to development before production.

Migrating Existing Clusters to Workspaces

Existing customers who are using clusters and want to migrate to workspaces, refer Migrating to Workspaces to plan and implement the move.

Note

All features and capabilities available for clusters are applicable in workspaces. Management of users, groups, roles, permissions, firewall, resource governor pools, and global system variables settings can be done only at the workspace group level.