Skip to main content
DataRidge
Category: Compliance and Monitoring

Query History

Also known as: QUERY_HISTORY
Simply put

Query History is a record of the database queries that have been run, capturing details about what was requested, by whom, and when. In platforms such as Snowflake, it is made available as a view or function that lets authorized users look back at past activity across dimensions like time, user, session, or compute resource. It is primarily an operational and auditing aid rather than a regulatory instrument in itself.

Formal definition

Query History refers to system-generated metadata describing executed queries against a data platform, typically exposed for retrospective analysis by dimensions such as time range, session, user, and warehouse. In the Snowflake platform specifically, it is surfaced through the Account Usage QUERY_HISTORY view and through table functions including QUERY_HISTORY and QUERY_HISTORY_BY_SESSION, which return queries within a specified time range (or a specified session and time range) subject to platform-defined retention windows and access privileges. From a governance perspective, query history can support data lineage understanding, access auditing, and demonstrable accountability, and it overlaps with information security monitoring where it informs access review and anomaly detection; the two domains should not be collapsed, as the record itself is a governance and observability artifact rather than a security control. This definition is scoped to the general concept and its Snowflake implementation as described in the evidence; it does not address the specific retention duration, the precise privileges required to access these objects, cross-platform equivalents, or whether captured query text may itself constitute personal data. Where query text or bound parameters contain personal or special category data, the history record may fall within data protection obligations, and such treatment depends on jurisdiction and implementation and is out of scope here.

Why it matters

Query History provides a retrospective record of what was asked of a data platform, by whom, and when, which underpins several governance functions at once. It supports data lineage understanding by showing how data was accessed and transformed, it enables access auditing by attributing queries to specific users and sessions, and it contributes to demonstrable accountability. That last point matters because accountability under most governance frameworks requires evidence of what actually happened rather than a stated intent to control access; a query history record is one form of such evidence, though it is not sufficient on its own.

Query History also sits at the boundary between data governance and information security without belonging entirely to either. The record itself is a governance and observability artifact, but it can feed security processes such as access reviews and anomaly detection. These domains overlap here, yet they should not be collapsed: query history informs security monitoring, but it is not itself a security control. Treating a passive record as though it enforced anything would misstate its function.

One further consideration deserves care. Where query text or bound parameters contain personal or special category data, the history record may itself fall within data protection obligations. Whether it does depends on jurisdiction and implementation, and that question is out of scope for this concept. Practitioners should not assume that query history is neutral metadata in every case; the content of the captured queries can change its regulatory treatment.

Who it's relevant to

Information Governance and Data Stewardship Leads
Those responsible for lineage, cataloging, and policy use query history to understand how data is actually accessed and transformed, supporting demonstrable accountability. They should note that the record is a governance artifact and evidence source, not a control that enforces policy on its own.
Security and Access Review Teams
Query history can inform access reviews and anomaly detection where it exposes who queried what and when. It supports these security processes rather than substituting for them, and the record should be understood as observability input rather than a security control.
Data Protection Officers and Privacy Professionals
Where query text or bound parameters contain personal or special category data, the history record may fall within data protection obligations. Whether it does depends on jurisdiction and implementation, so this group should assess the actual content captured rather than assuming query history is exempt as mere metadata.
Snowflake Platform Administrators and Engineers
Those operating the platform work directly with the Account Usage QUERY_HISTORY view and the QUERY_HISTORY and QUERY_HISTORY_BY_SESSION functions, and must account for platform-defined retention windows and access privileges when relying on these objects for auditing or investigation.

Inside Query History

Executed Query Text
The actual statements run against a data store, which may themselves reveal or embed personal data (for example identifiers in WHERE clauses), meaning the log can constitute personal data even when the queried results are not stored.
User or Principal Identity
The account, service principal, or role that issued each query, supporting attribution and accountability. This attribution data is generally personal data where it identifies a natural person.
Timestamp and Duration
When each query was submitted and how long it ran, used for auditability, performance review, and reconstructing who accessed what and when.
Target Objects and Scope
The tables, columns, views, or datasets touched by a query, which supports lineage and helps assess whether special category or sensitive data was accessed.
Access and Result Metadata
Outcome indicators such as rows returned, success or failure, and error states, which help distinguish routine access from anomalous or unauthorized activity without necessarily storing the returned data itself.
Governance and Security Overlap
Query history serves data governance purposes (lineage, stewardship evidence, demonstrable accountability) and information security purposes (detecting unauthorized access, supporting confidentiality and integrity controls). These purposes overlap but remain distinct.

Common questions

Answers to the questions practitioners most commonly ask about Query History.

Is query history the same thing as an audit log?
Not exactly, and treating them as interchangeable is a common mistake. Query history typically captures the queries executed against a data store, often for performance tuning, cost analysis, or debugging purposes. An audit log is generally a broader, tamper-resistant record maintained for accountability and security purposes that may include access events, configuration changes, and authentication events in addition to queries. Query history may form one input to an audit capability, but it does not on its own satisfy audit or accountability requirements. Under governance frameworks, accountability generally requires demonstrable, reliable evidence rather than an operational convenience log. Whether a given query history is sufficient as audit evidence depends on its integrity controls, retention, and completeness, which vary by implementation and are out of scope for this definition.
Does query history stop being personal data if the queries only reference columns rather than returning actual records?
Not necessarily. Query history can constitute personal data in several ways: the queries themselves may embed personal data in filter conditions or literal values, the returned results may contain personal data, and the record of who ran which query at what time can relate to an identifiable individual. The presence or absence of returned rows does not by itself determine whether the query history is personal data. This entry does not address which lawful basis, retention rule, or transfer mechanism applies to such logs; those determinations depend on jurisdiction, the applicable regime, and the specific content captured, and should be assessed separately.
How long should query history be retained?
This entry does not prescribe a retention period, and no single figure would be defensible across contexts. Retention should generally be driven by a documented purpose, such as troubleshooting, cost management, security investigation, or an accountability obligation, and be no longer than necessary for that purpose. Where query history contains or reveals personal data, retention typically needs to align with the organization's broader retention policy and applicable legal requirements. Retention mechanics, minimization obligations, and enforcement consequences are out of scope here and should be addressed under the relevant data protection and records management policies.
Who should have access to query history, and who is accountable for it?
Access should generally be restricted on a least-privilege basis, since query history can expose both the content of queries and information about individual users' activity. Accountability typically sits with the party that controls the data platform and determines the purposes and means of the logging. Where a platform is operated by a provider on behalf of an organization, the provider may act as a processor and the organization as controller, with contractual terms governing access and use; the precise allocation depends on the arrangement. Governance frameworks generally expect access controls and their rationale to be documented as demonstrable evidence rather than merely stated.
Should query history feed into data lineage or a data catalog?
Query history can be a useful input to lineage and cataloging efforts, because observed queries can reveal how datasets are actually joined, transformed, and consumed. This overlaps with data governance activities such as lineage and stewardship. However, query history is an operational security- and performance-oriented record, not itself a lineage tool or catalog, and inferring lineage from it requires validation. Using it this way does not remove any obligations that apply to the personal data the logs may contain.
What controls help protect query history that may contain personal data?
Because query history sits at the intersection of governance and information security, relevant measures generally include access restriction, integrity protection to prevent undetected alteration, and defined retention. Note that applying security controls such as encryption or tokenization to the log does not make its contents non-personal; it may reduce risk but does not remove the data from scope. The appropriateness of any specific control depends on the sensitivity of the captured content, the platform, and the applicable regime. This entry does not enumerate a complete control set or address cross-border transfer of such logs.

Common misconceptions

Query history is only a performance or operational log and does not implicate data protection obligations.
Because query text and issuing-user identity can identify natural persons or embed identifiers, query history generally constitutes personal data in most jurisdictions and is typically in scope for retention, access, and lawful-basis considerations. This entry does not cover specific retention periods or transfer mechanics.
Retaining detailed query history automatically demonstrates compliance or accountability.
Accountability under governance frameworks requires demonstrable, evidenced practices; a query log is one possible source of evidence but does not by itself satisfy accountability. It must be tied to defined policies, a lawful basis for retaining the log, and appropriate access controls.
A query history feature is equivalent to a records of processing activities obligation or a data inventory.
Query history records access events, not the structured description of processing activities that a records obligation typically requires, nor a curated data inventory. They may inform each other but should not be treated as interchangeable.

Best practices

Assess whether your query history constitutes personal data in the relevant jurisdiction, and define a documented lawful basis and purpose for retaining it rather than keeping it indefinitely by default.
Apply access controls and least-privilege to the query history itself, since it can expose issuing-user identities and query text that embed identifiers or reveal access to special category data.
Set and enforce a defined retention period for query logs aligned with stated governance and security purposes, and document the rationale as evidence for accountability.
Treat query history as one input to lineage and stewardship evidence, but maintain your records of processing activities and data inventory as separate, purpose-built artifacts.
Use query history for security monitoring (detecting anomalous or unauthorized access) while keeping that use distinct from governance uses, and log both without collapsing the two objectives.
Do not assume masking or redacting result sets removes personal data from the log; review query text and metadata separately, as these may still contain identifiers.