Publishing Secure Datasets with Analytics Hub

BigQuery Analytics Hub (opens in a new tab) is the publication layer for sharing BigQuery assets inside and across organizations without creating unmanaged copies. A publisher creates a data exchange as a container for sharing, publishes listings that describe and grant access to specific assets, and consumers discover and subscribe to those listings. Because administration stays in the publisher project, access can be granted, changed, or revoked centrally while control of the source data remains with the owner.

1.1Data Exchanges and Listings

A data exchange and its listings are the foundation for all Analytics Hub sharing within or outside an organization. The exchange sets the sharing boundary and ownership, while each listing points to one shared asset and defines how a subscriber can use it. A publisher builds sharing in a fixed order because a listing depends on its parent exchange and subscribers depend on the listing for governed access.

1. Create exchange: Create the exchange in the publisher project to own and administer sharing policy.
2. Create listing: Add a listing to the exchange that references the source dataset or topic.
3. Publish and manage: Publish the listing for internal or external discovery, then manage membership, access, and lifecycle as needs change.

Choose exchanges and listings when the goal is curated, repeatable publication to known teams, partners, or a broader audience. The subscriber receives only the access defined by the listing, and the publisher retains the ability to change or revoke that access.

1.2Sharing Real-Time Data with Pub/Sub Topics

A Pub/Sub topic listing shares real-time streaming data through Analytics Hub instead of a static table snapshot. Data flows from the publisher-owned Pub/Sub topic to each authorized subscriber, so subscribers receive new events as they are published. The publisher retains ownership of the topic and its listing, while subscribers attach and consume within their own projects. Choose Pub/Sub topic sharing when consumers need continuous event streams rather than periodic queries against a dataset.

1.3Collaborating on Sensitive Data with Data Clean Rooms

A data clean room is an Analytics Hub environment for multi-organizational collaboration on sensitive data. The clean room allows participating organizations to bring their governed datasets together and run joint analysis under shared controls, rather than exchanging raw copies outside any boundary. Control stays with each contributor, who administers what data enters the clean room and what analysis is permitted. Choose data clean rooms when the requirement is collaborative insight on restricted data where direct dataset sharing would expose too much.

1.4Protecting Shared Assets Against Exfiltration

VPC Service Controls (VPC SC) adds a network and identity perimeter around shared Analytics Hub assets to protect against data exfiltration. The perimeter encloses trusted publisher and subscriber projects on the inside, and traffic that attempts to copy or move data to resources on the outside is denied even when Identity and Access Management (IAM) permissions would otherwise allow access. The shared asset depends on both its listing permission and the perimeter rule, so access requires passing both checks. Apply VPC Service Controls when listings cross trust boundaries and copying data outside the approved perimeter must be blocked.

1.5Monetizing Data Through Google Cloud Marketplace

Google Cloud Marketplace is the commercial channel for Analytics Hub assets. A publisher commercializes an existing exchange listing by offering it as a paid product, so discovery, entitlement, and billing flow through Marketplace to the external buyer. The underlying trust model does not change: the publisher still owns the source and administers the listing, while the buyer receives only the access granted by the listing. Choose Marketplace commercialization when the goal is data monetization beyond internal or partner sharing.

The four sharing patterns differ by use case and control relationship:

Robust access governance for published datasets is the practice of combining coarse project permissions with fine-grained data filters so each consumer sees only the rows, columns, and derived results they are entitled to see. In BigQuery (opens in a new tab), the publisher keeps the source dataset in its own project and shares it in place, while Identity and Access Management (IAM) roles, authorized resources, row-level policies, and column-level policies enforce the boundary between publisher storage and subscriber queries.

2.1Role-Based Access Control with Least Privilege

Role-based access control (RBAC) with least privilege is the foundation that grants a user, group, or service account only the minimum permission needed for its role, such as no-access, read-only, or write. The data owner maps IAM roles to identities based on project needs, access patterns, or resource tags, starting from predefined BigQuery roles and creating custom roles when more precise permission sets are required. Granularity is increased with IAM policies with conditions that limit access by attributes such as time, resource, or request context, and with principal access boundary (PAB) policies that cap what an identity can do even when other grants are broader.

This model separates operational control from data access control. A cloud engineering group may grant permission to run jobs or manage infrastructure, while a separate data owner grants permission to read the dataset itself. Because BigQuery separates compute from storage, subscriber queries run with subscriber compute against publisher storage, so the publisher must grant data access explicitly and the subscriber must hold permission to run jobs. VPC Service Controls adds a network perimeter around Google Cloud resources that helps prevent data exfiltration outside the perimeter, and audit trails from Cloud Audit Logs and Cloud Logging record who accessed what to enforce governance policies.

2.2Authorized Sharing for Published Datasets

BigQuery sharing is the zero-copy publication path that shares a dataset in place without replication or file movement. The publisher workflow moves in order: first, the publisher creates or selects a shared dataset or Pub/Sub topic in the publisher project; then, the publisher organizes that resource into a listing inside a data exchange; then, the publisher grants subscriber access at the exchange or listing level. Subscribing creates a read-only linked dataset in the subscriber project that is a live pointer to the shared dataset, so queries always see current publisher data without a copy.

A linked dataset is authorized to read its source without requiring the subscriber to hold IAM rights on the underlying source dataset. That authorization extends to standard tables and views plus delegated resources:

• Authorized views that expose only a filtered query result without granting access to source tables
• Authorized datasets that delegate access from a source dataset to a view or routine in another dataset
• Authorized routines including user-defined functions (UDFs), table functions, and SQL stored procedures
• BigQuery ML models, external tables, materialized views, tables, table snapshots, and views that are part of the shared dataset

Data owners retain control through exchange and listing permissions, data egress options, and usage monitoring. When egress is restricted on a listing, copy, clone, export, snapshot, CREATE TABLE AS SELECT, CREATE VIEW AS SELECT, writing to a destination table or view, and BigQuery Data Transfer Service on the linked dataset become unavailable. Publishers can monitor jobs executed, bytes scanned, rows processed, and subscribers by project and organization to detect overuse or unexpected access.

2.3Row-Level Security and Column-Level Security

Row-level security in BigQuery is a table filter that grants access to only a subset of rows based on a row access policy evaluated at query time. The policy defines which rows an identity or group can see, and every query against the table flows from the storage engine through the policy check before rows return to the user. The table itself remains one object, so a regional sales team and a national team can query the same published table while each receives only its allowed rows. Shared datasets support row-level security, so the filter continues to apply when the table is consumed through a linked dataset.

Column-level security in BigQuery is a separate query-time check that grants access to sensitive columns using policy tags or type-based classification. A policy tag is attached to a column such as national identifier, balance, or diagnosis, and a different IAM grant controls who can read that tag. Users without the grant can still query the table but are denied the protected columns, which prevents accidental disclosure when a wide table is published. Sensitive Data Protection helps find columns to tag by scanning for personally identifiable information (PII), financial data, and health information and storing data profiles for review.

The fine-grained controls differ by what they hide and how they enforce it:

Column data masking complements these controls when a column must remain visible but unreadable to some consumers. Data masking obscures the sensitive value while still permitting access to the surrounding row, and it can also match sensitive patterns to guard against accidental disclosure. BigQuery automatically encrypts data at rest and in transit, with optional customer-managed keys, so masking and fine-grained policies govern visibility while encryption governs storage protection.

Optimizing a published dataset means making it easy to find through search and catalogs while assigning storage and query costs to the correct project. In Google Cloud, BigQuery sharing (opens in a new tab) publishes data in place without replication, and Knowledge Catalog and Data Catalog make that data searchable through listings and governed metadata. Cost control follows the same split: the publisher retains storage costs and the subscriber pays for the queries or reads it runs.

3.1Make Published Datasets Discoverable In Place

BigQuery sharing is a publish-and-subscribe exchange that shares BigQuery datasets and Pub/Sub topics across organizational boundaries without copying data. A publisher creates a shared dataset or shared topic in its own project, organizes references to it as listings inside a data exchange, and grants access at the exchange or listing level. A subscriber then discovers the listing, subscribes, and receives a live pointer in its own project — a read-only linked dataset for BigQuery or a linked Pub/Sub subscription for streaming — and queries or reads without additional IAM on the source.

Discovery depends on exchange visibility and catalog indexing. A private data exchange is visible only to granted users or groups, while a public data exchange lets all authenticated Google Cloud users (allAuthenticatedUsers) discover and subscribe to its listings. The same distinction applies to listings: private listings are shared directly with specific users or groups, while public listings in a public exchange can reference free public resources or commercial resources. Cloud Marketplace-integrated listings are indexed in Data Catalog and Knowledge Catalog, but the catalog cannot specifically filter for that resource type.

Public datasets extend the same model at internet scale. BigQuery public datasets (opens in a new tab) are hosted by Google under projects such as bigquery-public-data, with Google paying for storage and each querier paying only for queries it runs, with the first 1 TB per month free. Subscribers find them in the Google Cloud console Explorer pane, through BigQuery sharing, through the bq command-line tool, or through the BigQuery REST API and client libraries, and must query with a fully qualified name such as bigquery-public-data.bbc_news.fulltext.

3.2Enrich Listings With Descriptive And Governance Metadata

A listing is the searchable record for a shared resource, and a complete listing carries the context a subscriber needs to evaluate it. A publisher can specify the resource description, sample queries, sample message data, documentation links, relevant instructions for subscribers, primary contact email address, provider details, and publisher details. Data exchanges also carry a primary contact email address so subscribers can contact the owner directly.

Catalogs add governed metadata on top of that publisher-supplied description:

• Business glossary terms, aspects and aspect types, and enriched entry metadata that standardize vocabulary and context
• Column-level lineage and source tags that trace provenance and visually represent data flow back to origin
• Data quality rule results, such as correctness and completeness percentages and thresholds, stored as tags
• Retention, encryption, de-identification, privacy assessment, and consumption-purpose labels linked to IAM and query controls
• Cost-related metrics, such as query, storage, and egress costs calculated from Cloud Billing exports to BigQuery

This combination lets internal teams and external consumers search by business meaning, verify quality and lineage, and enforce purpose and retention policy before subscribing, rather than relying on table names alone.

3.3Assign Storage And Query Costs To Publisher And Subscriber

There is no additional charge for managing data exchanges or listings in BigQuery sharing. Cost-sharing follows resource type, with storage staying with the publisher and consumption billed to the subscriber project:

The same split applies when a dataset is shared with the public. Storage charges are incurred by the billing account attached to the project that contains the publicly shared dataset, while query charges are incurred by the billing account attached to the project where the query jobs run. Because the linked dataset is only a pointer, the subscriber pays for bytes scanned in its own job project even though no data was copied.

Publishers monitor that consumption without seeing subscriber data. Provider usage metrics report jobs that run against the shared dataset, consumption by subscriber project and organization, and total rows and bytes processed. Billing usage metrics for Google Cloud Marketplace (opens in a new tab)-integrated listings are not captured in provider usage metrics or in INFORMATION_SCHEMA views, so commercial publishers track orders through Cloud Marketplace instead.

3.4Control Shared Query Costs With Slots, Reservations, And Workload Options

BigQuery separates storage from compute, so sharing many copies does not require more compute until subscribers query. Compute is measured in slots, a unit of capacity that Google manages, and memory is provided by a remote distributed service connected over Google's petabit network. Data is stored compressed, encrypted, replicated, and distributed in Google's distributed file system without consuming query slots.

Subscribers and publishers control query spend by choosing how slots are purchased and how queries are scheduled. On-demand pricing bills per bytes scanned, while capacity-based pricing uses reservations — buckets of dedicated slots that are dynamically created and then assigned to projects, folders, or organizations. Interactive queries execute as soon as possible by default, while batch queries are queued and start when idle capacity is available in the shared pool. Assigning a subscriber project to a reservation therefore caps and isolates the cost of querying published data, while leaving storage costs with the publisher.

Key Facts

• BigQuery Analytics Hub shares data through data exchanges that contain listings, and subscribing creates a read-only linked dataset that points to publisher storage without copying data.
• Pub/Sub topic listings share real-time streaming events from a publisher-owned topic to subscribers, while data clean rooms enable joint analysis of sensitive data without exchanging raw copies.
• VPC Service Controls encloses trusted publisher and subscriber projects in a perimeter that denies data movement to outside resources even when IAM permissions allow access.
• Authorized views expose only filtered query results, row-level security filters rows by policy at query time, and column-level security and masking hide or obscure protected columns.
• Storage costs bill to the project containing the shared dataset while query and subscribe throughput costs bill to the subscriber project running the job.