Organization Usage¶

The ORGANIZATION_USAGE_VIEWER, ORGANIZATION_BILLING_VIEWER, and ORGANIZATION_ACCOUNTS_VIEWER SNOWFLAKE database roles are granted the SELECT privilege on Organization Usage views in the shared SNOWFLAKE database.

The Snowflake-specific views are subject to change. Avoid selecting all columns from these views. Instead, select the columns that you want. For example, if you want the name column, use SELECT name, rather than SELECT *.

ORGANIZATION_USAGE views can contain large volumes of data across every account in your organization. For each view you query, follow the same two rules on historical and other large views:

1. Always bound the time range on that view’s primary time column (see the table below, then that view’s reference topic for the exact name and type).
2. Select explicit columns instead of SELECT *.

Historical views and time filters¶

Most large ORGANIZATION_USAGE views expose a primary timestamp or date column. Put a bounded range on that column in every query for that view (for example WHERE start_time >= … AND start_time < … on QUERY_HISTORY, using start_time because that is the primary time filter column for QUERY_HISTORY in the table below). Open-ended time ranges force Snowflake to consider the full history across your organization before it can return rows.

The following table lists common historical views (and similar large scans) where bounded time predicates matter most. The table is illustrative, not exhaustive; apply the same bounded-time approach to other historical ORGANIZATION_USAGE views, using each view’s reference topic to choose the column. For each row below, start with the primary time filter column in a bounded predicate (for example WHERE col >= … AND col < …). View revisions (for example v30, v21) change over time; use each view’s reference topic for authoritative column names and types.

Before joining several ORGANIZATION_USAGE views, apply bounded time predicates on each view you reference (for example bound QUERY_HISTORY.start_time and COPY_HISTORY.last_load_time separately when both appear in the join). For dashboards that rerun the same logic, materialize results in a table you own and refresh it on a schedule instead of rescanning wide history.

Good query patterns¶

Each example names the ORGANIZATION_USAGE view it applies to. Every example follows the two rules above: bounded time on that view’s primary time column (from the table) and explicit columns in the SELECT list. When that view includes account_name, add AND account_name IN (…) so the scan is limited to the accounts you care about.

QUERY_HISTORY: Bound start_time.

Copy codeExpand code block

SELECT query_id, start_time, user_name, warehouse_name
  FROM SNOWFLAKE.ORGANIZATION_USAGE.QUERY_HISTORY
  WHERE start_time > '2025-01-01 00:00:00'::timestamp_ltz;

Show lessSee more

Scroll to top

COPY_HISTORY: Bound last_load_time.

Copy codeExpand code block

SELECT account_name, file_name, error_count, status, last_load_time
  FROM SNOWFLAKE.ORGANIZATION_USAGE.COPY_HISTORY
  WHERE last_load_time >= '2025-01-01 00:00:00'::timestamp_ltz
    AND last_load_time < '2025-02-01 00:00:00'::timestamp_ltz;

Show lessSee more

Scroll to top

DATABASES: Object inventory (no time predicate in this pattern; still list columns).

Copy codeExpand code block

SELECT database_name, account_name
  FROM SNOWFLAKE.ORGANIZATION_USAGE.DATABASES;

Show lessSee more

Scroll to top

USERS: Filter account_name when you do not need every account.

Copy codeExpand code block

SELECT account_name, name, login_name
  FROM SNOWFLAKE.ORGANIZATION_USAGE.USERS
  WHERE account_name IN ('ACC1', 'ACC2', 'ACC3');

Show lessSee more

Scroll to top

The DATABASES and USERS examples use object-style views with smaller result sets; keep explicit column lists so downstream schemas stay stable when Snowflake adds columns.

Query patterns to avoid (history views)¶

The following anti-patterns are shown for specific views; the same issues apply to any large history view when you omit a bounded time predicate on that view’s primary time column (see the table above).

QUERY_HISTORY: Unbounded aggregate.

Copy codeExpand code block

SELECT COUNT(*) FROM SNOWFLAKE.ORGANIZATION_USAGE.QUERY_HISTORY;

Show lessSee more

Scroll to top

LOAD_HISTORY: LIMIT without a time predicate on last_load_time.

Copy codeExpand code block

SELECT * FROM SNOWFLAKE.ORGANIZATION_USAGE.LOAD_HISTORY LIMIT 1;

Show lessSee more

Scroll to top

QUERY_ATTRIBUTION_HISTORY: SELECT * with no time predicate on start_time.

Copy codeExpand code block

SELECT * FROM SNOWFLAKE.ORGANIZATION_USAGE.QUERY_ATTRIBUTION_HISTORY;

Show lessSee more

Scroll to top

Why unbounded patterns are expensive¶

ORGANIZATION_USAGE views surface organization-wide history. When a query does not include selective time predicates (and account_name filters when you only need certain accounts), Snowflake may need to consider a very large amount of history before it returns rows or completes an aggregate. On wide views such as QUERY_HISTORY, that work can scale to very large row counts, which increases run time and warehouse cost.

The Latency values in ORGANIZATION_USAGE views describe how current the data is for each listed view; they do not remove the need to constrain time ranges (and account_name when applicable) on those same views for large scans.