Administering Snowflake is different from administering a traditional database. There's no server to patch, no storage to provision, no indexes to rebuild. What's left is the work that actually matters: controlling who can do what, sizing and governing the compute that drives the bill, and tuning the parameters that shape behavior. Most of it happens through SQL and a handful of object types.

Roles and access control

Snowflake uses role-based access control, and privileges are granted to roles, not directly to users. Users are then granted roles. A few system roles anchor the hierarchy: ACCOUNTADMIN at the top (use it sparingly), SECURITYADMIN for managing grants and users, SYSADMIN for creating warehouses and databases, and USERADMIN for users and roles. The recommended pattern is to build custom functional roles (analyst, engineer, loader) beneath SYSADMIN and grant object privileges to those, so access maps to job function rather than to individuals.

CREATE ROLE analyst;
GRANT USAGE ON WAREHOUSE bi_wh TO ROLE analyst;
GRANT USAGE ON DATABASE analytics TO ROLE analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.marts TO ROLE analyst;
GRANT ROLE analyst TO USER jdoe;

Warehouses: the compute you pay for

A virtual warehouse is the compute cluster that runs queries, and it's the main lever on both performance and cost. Administration means sizing them (X-Small through larger T-shirt sizes), enabling auto-suspend so they stop billing when idle and auto-resume so they wake on demand, and using multi-cluster warehouses to absorb concurrency spikes. The single most effective cost control is a short auto-suspend (60 seconds for interactive warehouses) paired with separating workloads onto their own warehouses so a heavy ETL job can't starve a BI dashboard.

Resource monitors and parameters

Resource monitors put a credit budget around warehouses with triggers that notify, then suspend, when a quota is hit - the guardrail that turns "the bill surprised us" into "the warehouse stopped at the cap." Behavior is also shaped by parameters set at the account, user, or session level: STATEMENT_TIMEOUT_IN_SECONDS to kill runaway queries, DATA_RETENTION_TIME_IN_DAYS to control Time Travel history, and STATEMENT_QUEUED_TIMEOUT_IN_SECONDS to fail fast instead of waiting forever.

CREATE RESOURCE MONITOR bi_budget
  WITH CREDIT_QUOTA = 1000 FREQUENCY = MONTHLY
  TRIGGERS ON 80 PERCENT DO NOTIFY
           ON 100 PERCENT DO SUSPEND;
ALTER WAREHOUSE bi_wh SET RESOURCE_MONITOR = bi_budget;

Monitoring what's happening

The ACCOUNT_USAGE and INFORMATION_SCHEMA views are the administrator's window into the account: QUERY_HISTORY for what ran and how much it scanned, WAREHOUSE_METERING_HISTORY for credit consumption per warehouse, LOGIN_HISTORY for access auditing, and ACCESS_HISTORY for column-level data access. Watching credits by warehouse and query, and reviewing which roles touch sensitive tables, is most of day-to-day Snowflake operations.

Frequently asked questions

Why grant privileges to roles instead of users? Roles map access to job function, so adding or removing a person is one grant rather than re-creating their whole permission set - and access stays auditable.

What's the simplest way to control Snowflake cost? Short auto-suspend on warehouses, workload separation onto dedicated warehouses, and resource monitors that suspend at a credit cap.

Should I use ACCOUNTADMIN for daily work? No. Reserve it for true account-level tasks and operate through SYSADMIN and custom functional roles, which limits blast radius.

Where do I see credit consumption? SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY for per-warehouse credits, and QUERY_HISTORY for per-query cost and bytes scanned.