Single Origin reads metadata only from your Amazon Redshift data warehouse — database, schema, table, view, and column definitions plus system catalog and usage information. It never reads the contents of your tables.

You now connect Single Origin by creating a dedicated read-only user and role in your cluster and granting them metadata access. The setup is a short SQL script and nothing leaves your environment.

What you're granting

You grant a dedicated role the following. None of these grant access to the data inside your tables.

REFERENCES is the key to the metadata-only guarantee: it exposes the shape of each table — columns and types — but not the rows. Combined with read access to the system catalog, Single Origin can profile the structure and usage of your warehouse without ever reading your data.

Before you start

You'll need:

• A superuser (for example, the cluster's admin user) to run the script.

• A strong password for the new service user (shown as <STRONG_PASSWORD> below), or set up IAM-based authentication if you prefer not to manage a password.

• The list of databases and schemas you want Single Origin to see.

• Your cluster's connection details: endpoint (host), port, and database name.

  If you've enabled metadata security on the cluster (METADATA_SECURITY=true), users only see metadata for objects they've been granted access to — so the per-schema USAGE and REFERENCES grants below are required, not optional.

Option 1 — Base setup script

Run this once as a superuser (Redshift Query Editor v2 works well). Replace <STRONG_PASSWORD> with your value:

 
    -- 1. Create a dedicated role and user for Single Origin
CREATE ROLE single_origin_role;

CREATE USER single_origin_user PASSWORD '<STRONG_PASSWORD>';
GRANT ROLE single_origin_role TO single_origin_user;

-- 2. Allow read access to system tables and views (object + usage metadata)
GRANT ROLE "sys:monitor" TO ROLE single_origin_role;

Option 2 — Grant metadata access per schema

Run this block for each schema you want Single Origin to see. Replace <schema_name>:

GRANT USAGE ON SCHEMA "<schema_name>" TO ROLE single_origin_role;

GRANT REFERENCES ON ALL TABLES IN SCHEMA "<schema_name>" TO ROLE single_origin_role;

-- Include tables created in the future, so you don't have to re-run this later
ALTER DEFAULT PRIVILEGES IN SCHEMA "<schema_name>"
  GRANT REFERENCES ON TABLES TO ROLE single_origin_role;

View Schemas

1. Go to the Redshift Editor console.
2. Enter the follow SQL query to create the view schema table:
3. Click Run to execute the query.
4. After execution, click Export and select CSV as saved file format.

 
    SELECT
         schemaname as schema_name,
         viewname as view_name,
         definition as view_definition,
         viewowner as view_owner
    FROM pg_views
    WHERE view_owner != 'rdsdb'

Repeat the block for each schema in each database. To connect to a different database, reconnect the Query Editor to that database first — grants apply to the database you're currently connected to.

Helper: generate the per-schema grants automatically

Rather than writing the block by hand for every schema, run this query (connected to the target database, replacing <database_name>) to generate the statements for all user schemas, then copy the output and run it:

SELECT
  'GRANT USAGE ON SCHEMA "' || schema_name || '" TO ROLE single_origin_role;' || chr(10) ||
  'GRANT REFERENCES ON ALL TABLES IN SCHEMA "' || schema_name || '" TO ROLE single_origin_role;' || chr(10) ||
  'ALTER DEFAULT PRIVILEGES IN SCHEMA "' || schema_name ||
    '" GRANT REFERENCES ON TABLES TO ROLE single_origin_role;'
FROM svv_all_schemas
WHERE database_name = '<database_name>'
  AND schema_name NOT IN ('information_schema', 'pg_catalog', 'pg_internal');

Finish up

Once the script has run, share your cluster's endpoint, port, database name, and the single_origin_user credentials with your Single Origin contact (or enter them in the onboarding flow). You may also need to allow network connectivity to the cluster — typically via an interface VPC PrivateLink connection or by allowlisting Single Origin's IP range; your contact can provide the details. We'll connect and begin reading metadata — no further action needed on your side.

Revoking access

Remove Single Origin's access at any time. Run as a superuser:

DROP USER single_origin_user;
DROP ROLE single_origin_role;

Dropping the role removes every grant associated with it, and dropping the user immediately ends Single Origin's ability to connect. If Redshift reports that the role or user owns objects or has dependent privileges, revoke those grants first, then drop.