Data Segregation

Rockset provides customers the ability to control who has access to data within the platform. This document explains how data is segregated into Workspaces, how to provide access Workspaces, and design considerations when providing access across Workspaces.

Key Terms

Workspace - Logical segregation of data, like an individual database

A workspace is the most granular form of data segregation within Rockset. It can be thought of as a container or folder that can hold documents/data (Collections) as well as means to access data (Views, Query Lambdas). Workspaces and resources have a 1:1 mapping.

Collection - Tables within a database

A collection is a set of Rockset documents. All documents within a collection and all fields within a document are mutable. Similar to tables in traditional SQL databases, collections are traditionally queried with FROM clauses in SQL queries.

Alias - An alias reference for a collection

A collection alias references a collection. By using collection aliases, you can use the alias name in your queries in place of the actual collection name. Additionally, you can switch the alias to a different collection at any time without any downtime for your queries.

View - a virtual collection

Views are virtual collections defined by static SQL queries. A view’s SQL query can reference other views, collections, aliases, or it may not reference anything.

Query Lambda - Parameterized queries

Query Lambdas are named parameterized queries that reside within a given workspace. They use a dedicated endpoint, have tagging, and maintain a version history.

Role - A role is a set of privileges.

Virtual Instance (VI) - Compute resources

A Virtual Instance is a set of compute resources used to process streaming ingest and queries.

❗Note: Privileges for VIs only grant access to use those computational resources. To query data,
users would need both VI privileges as well as Workspace privileges.

Data Segregation within Rockset

Rockset leverages workspaces to separate data. Within a given workspace, users are able to query all collections within that workspace. By default, users querying one workspace are unable to query data within another workspace unless they have privileges to be able to access both workspaces. However, there are cases where you might want to share a subset of data between two workspaces, or only allow one team to view a subset of data within a given workspace. To address this, Rockset uses Views and Query Lambdas to be able to securely share a subset of data across workspaces.

Views and Query Lambdas can be used to selectively share data from one workspace with another.

To be able to use a Query Lambda or a View to access data within Workspace A from Workspace B, the user creating the View or QL must first have the following privileges:

• Privileges to query Workspace A
• Privileges to query Workspace B
• At least one of the following
  • Privileges to create a View in Workspace B, or
  • Privileges to create a Query Lambda in Workspace B

Both Views and Query Lambdas are similar in how they operate; both are saved SQL queries. The difference is that Views are effectively static queries, and Query Lambdas are parameterized queries. Once the View has been created in a Workspace, any other users within that Workspace can view the data within the View. Likewise, once a Query Lambda is created within a Workspace any user within that workspace that have Query Lambda Execute privileges can view the results of the Query Lambda.

To query the View, a user needs the following privileges:

• Privileges to query Workspace B (where the view is)
• Privileges to use a VI (the compute resources to run a query)

To use the Query Lambda, a user needs the following privilege:

• Privileges to Execute the Query Lambdas in Workspace B

❗Note: Only users who have privileges to query both workspaces are able to modify Query Lambdas or
Views accessing both workspaces. Any other users attempting to modify them will experience authorization errors.