We implemented workspaces to enable our customers to work on several different Data projects and/or to setup different working environments. Soon after, however, our customers started to ask about the possibility of sharing Data Sources across workspaces. The two main scenarios we’ve seen are:

• Teams who want to re-use data across different data projects (Real-time dashboards, Alerts…) or environments (Staging, Production…) in order to avoid having to re-ingest the same data twice. Especially important for big Data Sources and Data Sources that are transformed or materialized in specific ways.
• Teams who want to separate responsibilities, so only part of the members are responsible for ingesting and maintaining data and others can exploit it.

Starting today, sharing Data Sources across workspaces in a read-only way is possible with Tinybird.

With this feature you will be able to:

• Share Data Sources across workspaces one-by-one and in read-only mode (Shared Data Sources can’t be re-shared). A user can only share a Data Source with other workspaces she has access to, by entering the Workspace name or its ID.

• If in the origin Workspace, see which Data Sources are shared with who.

• Log sharing activity. Who, what, when, with who.
• Use the workspace name as a namespace for the shared Data Sources, to ensure the right Data Source is used if there are name collisions.
• Create Pipes or Materialized Views originating from shared Data Sources.
• If in the destination Workspace, browse shared Data Sources using a specific visual language.

Caveats

• When sharing a Data Source with a Workspace, we will notify the users of the destination Workspace by email.
• When renaming / deleting a shared Data Source from the origin Workspace, we will notify all users in workspaces where the Data Source is shared.
• Data Sources can’t be shared using the CLI, for now. But we will display when we list the Data Sources if any of them is being shared.
• Users that have access to a shared Data Source will have access to the tinybird.datasources_ops_log and the tinybird.kafka_ops_log Data Sources. It is important to provide as much information as possible to any customer who has access to the original Data Source.

• It’s not possible for read-only users to check the quarantine of a Data Source. Having rows in quarantine is an ingestion problem, so the customer who has read access shouldn’t be worried about that, only about the “real” content.

Would you like to check out this new feature? Go to your account now.

‍