Snowflake Permissions
A reference explaining every permission Revefi asks for on Snowflake and what each one is used for.
Overview
Revefi operates on a metadata access principle: the role you create for Revefi is a read-only role that reads metadata, query logs, and aggregated statistics. By default Revefi never reads the rows in your tables, so none of the grants below include SELECT on your monitored databases.
This page explains why each permission in the Snowflake setup guide is requested.
Every grant below goes to the
REVEFI_ROLEcreated in Step 1 of the setup guide. Revefi connects as a single user assigned to that single role, so the role's grants are the complete boundary of what Revefi can do in your account.
Account-level permissions
| Permission | What Revefi uses it for |
|---|---|
USAGE, MONITOR, OPERATE, MODIFY on Revefi's warehouse | Lets Revefi run its own SQL against the dedicated REVEFI_WH warehouse. OPERATE starts and resumes the warehouse when a collection run begins; MODIFY lets Revefi keep its own warehouse right-sized as your monitoring workload changes. Revefi uses this one warehouse for all of its queries. |
IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" | Lets Revefi query the metadata views Snowflake publishes in the shared SNOWFLAKE database. This is the source for spend attribution, query performance analysis, usage analytics, and lineage — see below for the schema and views involved. |
MONITOR USAGE ON ACCOUNT (optional) | Lets Revefi see the names of all databases in the account and the configuration of future warehouses, not just the ones granted individually. Grant this only if you want Revefi to monitor all tables across all databases. See Step 4. |
What Revefi reads from the SNOWFLAKE database
SNOWFLAKE databaseSNOWFLAKE is the read-only database Snowflake itself shares into every account. It holds the account's operational metadata. Revefi reads from up to three schemas in this database.
ACCOUNT_USAGE
ACCOUNT_USAGE| Revefi Features | Views |
|---|---|
| Query & performance | QUERY_HISTORY, QUERY_ATTRIBUTION_HISTORY, QUERY_INSIGHTS, LOCK_WAIT_HISTORY |
| Spend | WAREHOUSE_METERING_HISTORY, METERING_DAILY_HISTORY |
| Warehouse management | WAREHOUSE_EVENTS_HISTORY, WAREHOUSE_LOAD_HISTORY |
| Pipelines | TASK_HISTORY, COPY_HISTORY, DYNAMIC_TABLE_REFRESH_HISTORY |
| Storage | STORAGE_USAGE, TABLE_STORAGE_METRICS |
| Lineage & metadata | ACCESS_HISTORY, TAG_REFERENCES, OBJECT_DEPENDENCIES, TABLES, STAGES, FUNCTIONS, PROCEDURES |
| Users & governance | USERS, LOGIN_HISTORY, SESSIONS |
| Cortex / AI | CORTEX_AI_FUNCTIONS_USAGE_HISTORY, CORTEX_AISQL_USAGE_HISTORY, CORTEX_FUNCTIONS_USAGE_HISTORY, CORTEX_ANALYST_USAGE_HISTORY, CORTEX_SEARCH_DAILY_USAGE_HISTORY, CORTEX_AGENT_USAGE_HISTORY, CORTEX_DOCUMENT_PROCESSING_USAGE_HISTORY, CORTEX_FINE_TUNING_USAGE_HISTORY, CORTEX_CODE_CLI_USAGE_HISTORY, CORTEX_CODE_SNOWSIGHT_USAGE_HISTORY, SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY |
Granting IMPORTED PRIVILEGES on the SNOWFLAKE database is equivalent to granting USAGE_VIEWER, OBJECT_VIEWER, GOVERNANCE_VIEWER, and SECURITY_VIEWER database roles along with the optional access requested in the below steps.
To grant access to only ACCOUNT_USAGE without exposing organization-level data, you may use the database roles instead.
ORGANIZATION_USAGE (optional)
ORGANIZATION_USAGE (optional)| Revefi Features | Views |
|---|---|
| Contract Burndown | ACCOUNTS, CONTRACT_ITEMS, REMAINING_BALANCE_DAILY, USAGE_IN_CURRENCY_DAILY |
These views cover commitment drawdown, spend in your billing currency, and cross-account rollups that span every account in the organization. This schema is optional: without it, Revefi reports account-level spend without contract context, and everything else continues to work.
This schema exists only on the organization account and on regular accounts with the
ORGADMINrole enabled. On such an account,IMPORTED PRIVILEGESalready covers it — Snowflake treats access to the sharedSNOWFLAKEdatabase as access to this schema, so no separate grant is needed. On the organization account itself, access is instead gated behindGLOBALORGADMINand application roles such asSNOWFLAKE.ORG_USAGE_ADMIN.
DATA_SHARING_USAGE (optional)
DATA_SHARING_USAGE (optional)| Revefi Features | Views |
|---|---|
| Data Share | LISTING_ACCESS_HISTORY, LISTING_CONSUMPTION_DAILY, LISTING_EVENTS_DAILY |
This schema is optional: it exists only for accounts that publish Marketplace or private-exchange listings, and Revefi skips it when it is absent.
Per-warehouse permissions
Granted on each warehouse you want Revefi to observe — see Step 3.
| Permission | What Revefi uses it for |
|---|---|
MONITOR ON WAREHOUSE | Reads the warehouse's query activity and load so Revefi can find performance bottlenecks, queuing, and spill, and produce sizing recommendations. |
USAGE ON WAREHOUSE | Reads the warehouse's parameters (size, cluster count, auto-suspend, timeouts) so recommendations account for the current configuration. Revefi does not run queries on your warehouses — it only runs them on its own. |
Per-database metadata permissions
Granted on each database you want Revefi to monitor — see Step 2.
| Permission | What Revefi uses it for |
|---|---|
USAGE ON DATABASEUSAGE ON ALL SCHEMAS IN DATABASEUSAGE ON FUTURE SCHEMAS IN DATABASE | Lets Revefi run USE <database> / USE <schema>. This does not grant access to the data in the database; it only allows subsequent queries to resolve object names without fully qualifying them. The FUTURE grant means schemas created later are covered without re-running the script. |
REFERENCES ON ALL TABLESREFERENCES ON FUTURE TABLESREFERENCES ON ALL VIEWSREFERENCES ON FUTURE VIEWS | Lets Revefi discover that a table or view exists and read its entry in the database's INFORMATION_SCHEMA views — row count, size, last-updated time, column names, and data types. REFERENCES deliberately does not allow reading the rows. |
MONITOR ON ALL DYNAMIC TABLESMONITOR ON FUTURE DYNAMIC TABLES | Reads refresh history and state for dynamic tables, so freshness and volume monitors work on them the same way they do on regular tables. |
Why the setup script uses a JavaScript stored procedure. In Snowflake, a
FUTUREgrant defined at the schema level takes precedence over one defined at the database level — so if any of your schemas already has its own future grants, the database-levelREFERENCES ON FUTURE TABLESgrant silently does not apply there. The script'sGRANT_SCHEMA_REFERENCES_FOR_DBprocedure enumerates your schemas, detects which ones have existing future grants, and re-grantsREFERENCESper schema for just those. If no schema has future grants, the procedure is a no-op. See Snowflake's notes on future grants.
Permissions on Revefi's own database
Revefi creates a dedicated database (REVEFI_DB by default) and is granted full read/write on it — USAGE, CREATE SCHEMA, CREATE TABLE, CREATE VIEW, SELECT/INSERT/UPDATE/DELETE on tables and views, plus CREATE PROCEDURE and CREATE TASK.
These broader grants are scoped entirely to this one database, which Revefi creates and owns. It holds query-log metadata that Revefi maintains, along with the procedures and tasks used for warehouse management. No object of yours lives in it.
Warehouse management permissions (optional)
Only needed if you want Revefi to act on its recommendations rather than just report them. See Step 5.
| Permission | What Revefi uses it for |
|---|---|
MODIFY ON WAREHOUSE | Changes the warehouse size to apply an approved sizing recommendation. |
OPERATE ON WAREHOUSE | Starts and suspends the warehouse — for example, shutting one down when it is completely idle. |
EXECUTE TASK ON ACCOUNT | Runs the Snowflake tasks Revefi creates in REVEFI_DB to carry out warehouse recommendations. |
EXECUTE MANAGED TASK ON ACCOUNT | Runs the cluster management safety-net task on Snowflake-managed (serverless) compute, so your cluster settings are restored even if Revefi cannot reach your account. |
Both warehouse grants can be applied to selected warehouses one at a time, or to every warehouse at once using the helper procedure in the setup guide. You can also constrain what Revefi is allowed to do with warehouse constraints and schedule overrides.
Does Revefi ever need data-level access?
Not by default. Revefi's monitors run on metadata and aggregated statistics. Some advanced data quality checks — missing values, distribution anomalies, referential integrity — need to read column values, and for those you may optionally grant SELECT on the specific tables you want checked. This is always opt-in and scoped to the tables you choose.
Related pages
- Snowflake setup guide — the full onboarding script
- Snowflake setup script generator — generates a script for just the features you need
- Snowflake FAQ — common setup and access questions
- Snowflake editions — feature differences by edition
Questions about a specific grant? Reach out to [email protected].
Updated 12 minutes ago