Sharing data from existing warehouses

What to expect during setup

If your team is actively setting up a new warehouse share for Paramark, it is normal for the process to take a few days while your data team configures access, confirms the right tables or views are included, and validates permissions internally.

A practical sequence usually looks like this:

1. Your team prepares the share and confirms which tables or views should be exposed to Paramark.

2. Paramark provides the required recipient details or service account information for the warehouse you are using.

3. Once your team finishes the setup, Paramark validates that the share is visible and that every expected table is queryable.

If setup is still in progress, the best next step is usually to let Paramark know when your team expects the share to be ready and then reconnect once access has been granted. After access is live, Paramark can verify the shared objects and flag any missing tables or permission issues quickly.

Snowflake

Sharing is done through a Secure Data Share. 

1. Provide Paramark with the cloud provider and region where your data resides.

2. Paramark will share an Account ID and Locator ID that can be used to grant permissions and share the data share.

3. Paramark will accept the share and confirm all tables are available.

Tips

• In the SQL syntax for granting access, Locator ID works best.

• If you are using a create or replace statement in your ETL for any tables, you will likely need to add ALTER SHARE <share_name> ADD ACCOUNT = <locator_id>; after replacing the table.

Common Snowflake setup question

If your team wants to share a curated set of Snowflake views or tables rather than exposing a large number of raw source tables, that works well with Paramark. In many cases it is the preferred setup because your data team can keep the business logic in Snowflake while giving Paramark a stable, read-only surface to query.

A few practical guidelines help this go smoothly:

• Align with your Paramark team on the exact list of tables or views that should be visible in the share.

• Keep the schema stable once the share is live, especially column names, meanings, and grain.

• If you refine the SQL behind a shared view, Paramark can usually keep using the same shared object as long as the agreed schema remains intact.

• After the share is updated, ask Paramark to validate that every expected table or view is visible and queryable.

Validating shared tables after query changes

If Paramark can only see some of the tables or views you expected to share, the fastest next step is to validate the exact list of objects in the share and confirm which ones are queryable from our side. This most commonly happens after a query refinement, when new views were added, or when an ETL job recreated a shared object.

When a Snowflake table disappears after a share update

If a specific Snowflake table or view stops appearing in the share after your team updates the query logic, adds a new baseline table, or refines the objects being shared, the fastest next step is to confirm whether the shared object was recreated or whether the share needs to be updated to include the latest object definition.

A few practical checks usually resolve this quickly:

• Confirm the object still exists under the expected database, schema, and object name from your side.

• If the table or view was recreated with CREATE OR REPLACE or rebuilt by an ETL job, re-apply the share permissions to that object before validating again.

• If a new table was added to the share, verify that it was explicitly added to the Snowflake share and that Paramark is still the authorized recipient on that share.

• After the update, ask Paramark to re-check the exact object list so any missing tables can be confirmed immediately.

In other words: if a table such as a newly added baseline output is present on your side but missing for Paramark, the issue is usually not the data itself — it is that the share needs to be refreshed, the object needs to be re-added, or permissions need to be re-applied after the object changed.

GCP BigQuery 

A common BigQuery setup pattern is to create a new dedicated project for Paramark access, then use a scheduled daily transfer or query job to copy the needed warehouse tables into that project. This gives your team a clean read-only surface for Paramark while keeping the source warehouse and internal transformation logic in your existing project.

Once that destination project is ready, grant Paramark's service account access to the required datasets or tables and let us know when the transfer is live so we can validate visibility and permissions.

• Create a dedicated project for Paramark

• You can set up a BigQuery job to transfer data from other internal projects to this dedicated project for Paramark

  • Please use a table and not a view/materialized view.

• We prefer you share the tables with our service account:

  • Organization ID: 364258081002.

  • Service Account: customer-data@paramark-customer-app.iam.gserviceaccount.com

  • Project ID: paramark-customer-app

  • In GCP terminology, you assign permissions to "principals" : either our Google group (customer-data-viewers@paramark.com) or the service account

  • Then for BigQuery itself, there are various permissions you can grant to our principal, which needs to enable read/query permissions for the datasets or tables required. (This doc covers some of the same ground.)

    • We recommend "BigQuery Data Viewer"

If your team is creating a new BigQuery project for Paramark

That setup works well. Many teams create a dedicated BigQuery project specifically for the Paramark share, then use a scheduled transfer or transformation job to copy the approved tables into that project before granting Paramark access.

A few practical guidelines help this go smoothly:

• Use ordinary tables rather than views or materialized views for the shared data.

• Confirm that the transfer job is populating the new project on the cadence you expect before asking Paramark to validate access.

• Grant Paramark read/query access only after the destination project and tables are ready, so validation can happen immediately.

• Once access is live, let Paramark know which datasets or tables should be visible so we can quickly confirm permissions and flag any missing objects.

If your internal team is still provisioning the new project, the most helpful update is simply the expected readiness date. Once the project exists and permissions are in place, Paramark can validate the share and confirm whether any additional BigQuery roles are needed.

AWS Redshift

Redshift has a Data Share feature. 

1. In AWS, create the data share.

2. Grant permissions to Paramark's account. (We will provide the account number in onboarding).

3. Paramark will validate the data share is available to query.

Note that Redshift datashares do not support the following object types:

• external tables and external schemas

• materialized views

• late binding views

• system views and system tables

• tables / views / materialized views with interleaved sort keys

• views with underlying UDFs (user-defined functions)

If you're using these, we suggest adding a step to your data pipelines to create ordinary tables and share those with Paramark instead.

AWS S3

S3 buckets are shared through IAM Roles. 

1. Paramark creates an IAM role and shares the ARN to you.

2. Create an S3 bucket.

3. Provide s3:GetObject, s3:ListBucket, and s3:GetBucketLocation to the Paramark IAM role.

4. Send paramark the s3:// URL for the bucket to validate access.

Data must be tabular and in either parquet (preferred) or CSV format. See the Requirements for Shared Data article for CSV requirements.

Databricks

We use Databricks-to-Databricks Delta Sharing. 

1. Provide Paramark with your cloud provider and region where the data resides.

2. Paramark will share sharing identifier.

3. Create a share in Databricks.

4. Add Paramark as a recipient.

If your team is not ready to automate the share on day one, a one-time historical backfill via flat files is a perfectly acceptable bridge. In that case, keep each file in the agreed time-series schema, include a data dictionary, normalize channel naming across the backfill, and separate metrics that live at different grains into clearly labeled tables rather than forcing them into one export. Once the Delta Share is live, Paramark can transition ongoing refreshes to the shared Databricks tables.

ClickHouse

Paramark can pull your marketing and target metric data directly from your ClickHouse warehouse. To set this up we need the following from your data team.

1. ClickHouse connection details

A read-only set of credentials for the ClickHouse instance where your modeling data lives:

2. SQL queries for the data you want shared

Your Paramark onboarding lead will work with you to define the exact ClickHouse SQL queries we need for your modeling data. Typically these cover your target metric(s) (e.g. new signups, MRR, orders) and your daily marketing spend by channel, campaign, geo, and platform — but the specifics depend on your business, your ClickHouse schema, and what's already modeled in your dbt layer.

3. Security & access

• We connect via ClickHouse's HTTPS interface (port 8443 on ClickHouse Cloud) using a standard SQL username and password.

• We strongly recommend a dedicated read-only ClickHouse user with SELECT grants only on the specific tables your queries reference.

Want to learn more about sharing your data? Check out other Paramark data sharing articles here