Query History
What is Query History?
Query history records every SQL query that runs inside a data warehouse, along with execution time, status, user, warehouse, and resource usage.
Teams use query history to understand who ran what, when it ran, how long it took, and how much it cost.
How Query History Works
A data warehouse logs each query at execution time.
The system captures metadata such as:
- Query text and query ID
- User or role that triggered the query
- Start and end timestamps
- Warehouse or compute resource
- Execution status, success, failure, or cancellation
- Resource usage like credits, slots, or CPU time
In Snowflake, query history lives in ACCOUNT_USAGE.QUERY_HISTORY and INFORMATION_SCHEMA.QUERY_HISTORY, with different retention windows and latency.
Why Query History Matters
Query history answers uncomfortable but necessary questions.
Who keeps running the same heavy query every five minutes.
Which dashboard refresh burned half the daily compute budget.
Which failed query retried itself for hours without anyone noticing.
Without query history, teams argue based on assumptions. With query history, teams point to facts.
Common Use Cases for Query History
Cost Attribution
Query history links queries to warehouses, users, and roles.
That connection lets teams assign spend to teams, dashboards, or workloads instead of treating compute as a shared black box.
Finance teams care about that linkage. Engineering teams depend on it during cost reviews.
Performance Debugging
Slow dashboards almost always trace back to a small set of expensive queries.
Query history shows execution time, queue time, and retries.
Engineers use that data to decide whether to tune SQL, resize warehouses, or change scheduling.
Incident Investigation
Production dashboards fail at 9:12 AM.
Query history shows exactly which query failed, which upstream query triggered it, and what ran right before the failure.
That timeline cuts hours from root cause analysis.
Governance and Access Reviews
Query history exposes who accessed which tables and when.
Security and compliance teams use it to validate access patterns and audit sensitive datasets.
Query History in Snowflake
Snowflake stores query history in two primary places.
INFORMATION_SCHEMA.QUERY_HISTORY
- Near real-time visibility
- Short retention window
- Useful for operational debugging
ACCOUNT_USAGE.QUERY_HISTORY
- Longer retention
- Slight reporting delay
- Used for cost analysis, governance, and historical reporting
Both views provide raw metadata. Neither provides context by default.
Limitations of Native Query History
Query history answers what happened.
It struggles to answer why it happened.
Common gaps include:
- No direct mapping between queries and business dashboards
- No ownership context beyond username or role
- No explanation of downstream impact
- No prioritization between harmless and dangerous queries
Teams often export query history into spreadsheets or BI tools. That approach breaks down once volume grows.
Query History vs Query Monitoring
Query history records past events.
Query monitoring reacts to active or upcoming problems.
Teams use history to analyze trends and monitoring to trigger alerts. Both matter, but history sets the foundation.
Metrics Pulled From Query History
Query history feeds several operational metrics:
- Total queries per day
- Average execution time
- Failed query rate
- Top cost drivers
- Warehouse utilization patterns
Without query history, these metrics rely on estimates.
Query History and Cost Control
Cost spikes rarely come from infrastructure changes alone.
They come from behavior.
Repeated retries, inefficient joins, runaway dashboards, or forgotten scheduled jobs.
Query history exposes those patterns early, before monthly invoices turn into escalation calls.
Where Query History Breaks at Scale
As usage grows, query history turns noisy.
Thousands of queries blur together. The important ones hide behind background traffic.
Teams lose time filtering, joining tables, and rebuilding context that never existed in the first place.
At that point, raw history stops being enough.
Query History With SeemoreData
SeemoreData builds on top of native query history.
Instead of treating queries as isolated events, SeemoreData connects them to:
- Dashboards and reports
- Data pipelines and lineage
- Teams and owners
- Actual compute spend
That connection turns query history from a log into an operating system for data cost and performance decisions.
Engineers stop guessing which queries matter. Leaders stop debating where the money went.
Best Practices for Using Query History
- Review top queries weekly by cost, not count
- Tag warehouses and roles consistently
- Separate ad-hoc and production workloads
- Track failed and retried queries as first-class signals
- Add ownership context early, before incidents force it
Teams that treat query history as an operational asset move faster and spend less.
Related Glossary Terms
- Query Tag
- Warehouse
- Compute Cost
- Cost Attribution
- Query Optimization
- Data Lineage
Summary
Query history records every query. The value comes from understanding which ones matter.
Raw logs help engineers debug. Connected context helps organizations control cost, reliability, and accountability.
At scale, query history stops being optional. It becomes the baseline for running data responsibly.
