Workspaces leverage SingleStore’s unique architecture and data durability guarantees to launch isolated compute pools for running discrete customer workloads.
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 to dedicated computing resources, providing scalability and workload isolation.
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 almost instantaneously. Sub-second replication latency is typical. This is because SingleStore does not require writes to go to object storage before being available on other workspaces for read queries. The transaction log tail is sent to the replica and applied there asynchronously in real time. Thus, R/W-R/O sync is eventually made consistent.
All new writes to a database are replicated immediately, 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 the incoming replication stream or reads against the database. For example, if a rowstore table is replicated to a small R/O workspace, replay on the R/O workspace will stop once the memory limit is reached, and the database can become unrecoverable. If replay stops, then eventually the write-side may also stop. An atomic write for two databases within a single workspace is not supported.
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.
