Workspaces Implementation

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 typically 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.

There are two situations in which replay latency can happen:

• Load replay needs the CPU to go through the log, so if this part is slowed down, replay will fall behind.

• SingleStore processes and saves transactions in a certain order, but it does not always commit them in that order. For example, if you have a big load followed by a small load, the system might finish the small task first. However, when it needs to replay or sync this on a replica, the replica has to wait for the big load to finish before replaying the small one.

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.