Comparison

BigQuery sharing (formerly Analytics Hub) vs Snowflake Marketplace

Two ways to receive data without loading a file, set side by side as Google and Snowflake document them: access, payment, regions, what you may copy, and how data delivered direct sits beside a listing.

Updated 5 October 20268 min read

Both products let a provider hand you data without sending a file. You subscribe to a listing or get one, and a read-only object appears in your own project or account. This comparison sets BigQuery sharing, which Google's documentation describes as formerly Analytics Hub, beside Snowflake Marketplace from the buyer's side. It covers what you receive, how access and payment work, where the data can live, what you may copy and how to keep your own history of a shared table. Each statement about Google or Snowflake comes from their own documentation, read on 4 October 2026.

Each is a data marketplace inside one platform, so the choice between them usually follows the warehouse you already run. A listing is built for data that a provider publishes that way and for reading it with no load to run. Fokals is delivered direct, by REST API and as bulk files, which you load with a BigQuery load job or Snowflake's COPY INTO command, and a later section sets out what a loaded copy gives you beside a listing.

The two side by side

BigQuery sharing, formerly Analytics HubSnowflake Marketplace
The vendor's descriptionA data exchange platform for sharing data across organisational boundaries without replicating itThe place to explore, access and provide listings
Where listings sitIn data exchanges, each private or publicOn the Marketplace, or offered privately to specific consumers
What a listing holdsA BigQuery dataset or a Pub/Sub topicA share of data or a Snowflake Native App
What you receiveA linked dataset: a read-only pointer in your projectA database created in your account from the provider's share
How you get itSubscribe, Request access or Purchase via MarketplaceGet, Request or Buy
Paying a provider on the platformA purchase through Google Cloud Marketplace, for listings integrated with itA usage-based or subscription-based plan, billed by Snowflake
What the platform charges youThe queries you runThe compute that runs your queries
ReachThe region of the exchange, with replicas for listings in multiple regionsAccounts on Amazon Web Services, Google Cloud and Microsoft Azure, with replication to your region
Copy controlsA publisher can switch off copy and export of the data and of query resultsShared objects are read-only

What you receive

Google's introduction describes a data exchange as a container of listings and a listing as a reference to a shared resource. Subscribing creates a linked dataset in your project. Google's page on subscribing calls it read-only: you can query its tables and views and join them to your own, and you cannot edit its data or metadata.

Snowflake describes a listing as an enhanced method of Secure Data Sharing: a share, or a Snowflake Native App, with a title, a description and other metadata. Getting a listing gives you a database made from the share. The page on Secure Data Sharing says no data is copied or transferred between accounts and that shared objects are read-only.

The objects line up almost one for one: an exchange or the Marketplace holds listings, and a listing becomes a linked dataset or a database. Two differences sit in what a listing can carry. On Snowflake it can be an application as well as data. On Google it can be a Pub/Sub topic as well as a dataset.

Access and payment

To subscribe on Google you need the BigQuery User role on your own project and the Analytics Hub Subscriber role on the listing or its exchange. A listing that needs approval or purchase shows Request access or Purchase via Marketplace in place of Subscribe. For a listing integrated with Google Cloud Marketplace, Google's page on commercial listings describes choosing a subscription plan and accepting the terms there, on your Google Cloud billing account, before you subscribe. It adds that data clean rooms and Pub/Sub topics are not supported for that integration. Where a listing offers only Request access, the provider contacts you.

On Snowflake the consumer guide asks for the CREATE DATABASE and IMPORT SHARE privileges, the PURCHASE DATA EXCHANGE LISTING privilege for paid listings, and an organisation that has accepted the terms. A listing is free, a limited trial or paid. A free listing gives instant access to the full dataset. A limited trial gives instant but limited access to a data product, which Snowflake's page on exploring listings describes as limited in time, in the data it covers, or both. A paid listing follows one of two pricing models: usage-based, billed in arrears for the months with usage, or subscription-based, billed upfront. The payment page says purchases are billed in US dollars, and that on a usage-based plan a query can be billable when it reads paid data even if it returns no rows.

Google says there is no additional cost for managing exchanges or listings, that the publisher pays for storage and that the subscriber pays for the queries it runs, on demand or on capacity pricing. Snowflake says the only charge to a consumer is for the compute that queries the shared data.

Where the data can live

Snowflake's Marketplace page says the Marketplace is available to accounts hosted on Amazon Web Services, Google Cloud and Microsoft Azure, with the exception of Microsoft Azure Government. When a listing is not yet in your region, the access guide has you select Request. With cross-cloud auto-fulfillment Snowflake replicates the data product to your region. The provider bears that cost and sets how often the replica is refreshed, so ask what the interval is: it decides how current the data is where you are.

On Google a shared dataset sits in the region of its data exchange, as the page on managing listings states, and a listing for multiple regions relies on replicas of the dataset. Check the regions a listing offers against the region of the tables you will join it to.

Copying, and keeping your own history

A shared table shows the provider's data as it is now. Research usually needs what was known on each date, so the question is whether you may keep dated copies of your own.

Google gives the publisher a switch. Its introduction says a publisher can restrict data egress on a listing, on query results or on both. Where it is restricted, the copy, clone, export and snapshot functions are unavailable, and so are CREATE TABLE AS SELECT and writing query results to a destination table. Separately, Google lists snapshots of linked dataset tables as unsupported in any case.

Snowflake's sharing page describes shared objects as read-only, and its page on configuring listings describes a service agreement that consumers must accept before they access a listing. What you may do with the rows you read is a matter for that agreement, so read it before you copy.

Where copying is allowed, a dated copy is one statement run on a schedule. The table and dataset names are illustrative.

-- BigQuery, for a listing whose publisher allows egress
insert into research.vendor_signals_history
select current_date() as snapshot_date, s.*
from vendor_linked.signals as s;

-- Snowflake, where the listing's terms allow a copy
insert into research.vendor_signals_history
select current_date() as snapshot_date, s.*
from vendor_db.public.signals as s;

A copy made this way starts on the day you first run it. It cannot recover what the table held before, which is why the first question to a provider is whether published rows are ever revised.

What the provider sees

Both platforms tell the provider something about your use. Google says publishers can track the jobs run against a shared dataset, consumption by subscriber project and organisation, and the rows and bytes processed. Its page on managing data exchanges adds a setting, subscriber email logging, that logs the principal identifiers of the users who run jobs and queries on linked datasets. Snowflake says providers can monitor interest in a listing and usage of the data in the share. A fund that would rather a vendor did not learn which tables it reads should ask each provider what it records.

Data delivered direct, beside a listing

Fokals delivers firmographic, technographic, hiring and intent data on public and private companies as CSV, JSON Lines and JSON, through its REST API and bulk exports, as the delivery page describes, and you load the files with the warehouse's own loader. Google's loading page lists CSV and JSON among the formats a load job accepts, and its page on loading JSON requires the newline-delimited form. Snowflake loads staged files with the COPY INTO command. The worked steps are in loading company data into BigQuery and loading company data into Snowflake.

A loaded copy gives you three things beside a listing.

  • You hold the copy. The tables sit in your own project or account, and you can query them as of any date you loaded. Fokals daily and weekly datasets are written once, after the period closes, and are never revised, so the loaded table is a point-in-time record with no snapshot job to run.
  • It joins on identifiers you already hold. Every company has one stable Fokals company ID, and a listed company carries its ticker, MIC, ISIN, LEI and share-class FIGI, so the loaded tables meet your own tables, and a listing's, on a shared identifier.
  • The terms are written for your use. Fokals is licensed by written agreement, for internal use, embedding in a product or redistribution. Data marketplace vs direct licensing sets the two routes side by side.

Passing loaded data on is a licence question. Either platform will let you publish data you loaded as a private listing to another organisation. Whether you may depends on a redistribution right in your licence, not on the platform.

Which to use, by need

  • You already run one of the two warehouses. Use its marketplace. Each delivers into its own platform.
  • You want to test before buying. Snowflake documents limited trial listings. On Google, ask the provider when you request access.
  • You need dated copies. On Google, ask whether egress is restricted. On Snowflake, read the listing's terms.
  • The provider is in another region or cloud. Snowflake documents replication to your region. On Google, check the regions the listing offers.
  • You want more than tables. Snowflake listings can deliver a Native App, and Google listings a Pub/Sub topic.

The guides to BigQuery sharing for data buyers and Snowflake Marketplace for data buyers take each product further, and Snowflake vs BigQuery compares the warehouses themselves.

Frequently asked questions

Is BigQuery sharing the same as Analytics Hub?

Yes. Google's documentation now calls the product BigQuery sharing and describes it as formerly Analytics Hub. The objects are the ones Analytics Hub had: data exchanges, listings and linked datasets, and the subscriber role is still named Analytics Hub Subscriber. A guide or a contract that says Analytics Hub is referring to the same service.

What is the difference between BigQuery sharing and Snowflake Marketplace?

Both give a buyer read-only access to a provider's data without a file. BigQuery sharing organises listings in data exchanges and gives you a linked dataset in your Google Cloud project. Snowflake Marketplace gives you a database in your Snowflake account, made from the provider's share. They differ in payment, which runs through Google Cloud Marketplace or through Snowflake, in trial listings, which Snowflake documents, and in copy controls, which Google gives the publisher.

Do I pay for storage when I subscribe to shared data?

Not on either platform, as documented. Google says the publisher pays for the storage of a shared dataset and the subscriber pays for the queries it runs. Snowflake says the only charges to a consumer are for the compute used to query shared data. A paid listing adds the provider's own price on top, under the plan the listing sets.

Can I copy data from a listing into my own tables?

It depends on the listing. On Google a publisher can restrict egress, which makes copy, export, snapshot and writing query results to a destination table unavailable. On Snowflake shared objects are read-only, and what you may do with the rows is set by the terms you accept. Ask the provider before you design anything that needs your own dated copies.

How do I load Fokals data into BigQuery or Snowflake?

Fokals is delivered direct, by REST API and as bulk files in CSV, JSON Lines or JSON. In BigQuery a load job reads the CSV or newline-delimited JSON files into a table of your own dataset, and in Snowflake the COPY INTO command loads the staged files into your account. Daily and weekly datasets are written once and never revised, so the loaded tables are a point-in-time record you can query as of any day. The data is licensed by written agreement, and that agreement decides what you may do with the copy you load.

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 4 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.