Whenever you drop into a new data project, you’re usually handed a graveyard of artifacts: job exports, static SQL scripts, and architecture diagrams that haven’t been updated in two years. You digest it all, map out a mental model of the pipeline, and start designing fixes based on that assumption. That’s exactly where Snowflake query history comes in.

Why the Repository Isn’t the Source of Truth

We faced this on one project where we spent weeks analyzing a job export, only to realize it was an outdated backup. The live production pipeline had evolved, but nobody had updated the repository. The code we were reviewing was flawless. It just wasn’t the code that was actually running.

The fix wasn’t a stricter code review process. It was a shift in mindset: before touching anything, force the platform to tell you what it’s doing. It turns out Snowflake is incredibly good at answering this, and it completely changed our workflow.

Snowflake Query History: See the SQL That Actually Ran

Snowflake query history is not just a basic audit log. We use it on day one to replace the most dangerous assumption in consulting: trusting the repo. When we look at the exact SQL that was executed, with all variables fully resolved, our analysis shifts from guessing to observing. We can finally reconcile the reference code against reality.

Snowflake Access History: Who’s Really Writing to Your Tables

Then there’s the question of who (or what) is actually writing to a table. Access history shows exactly which processes are writing objects and which identities are reading them. In that same engagement, it showed us that an entire environment people swore was driving production wasn’t writing anything at all. That single query saved us weeks of building elegant, well-tested data models that would have been completely useless for the overnight pipeline.

Use Execution History to Build a Timeline

If you rely on whoever touched a file last to figure out when things broke, you’re usually going to blame the wrong person. By grouping a year’s worth of execution history, you can spot the exact day a job’s behavior changed. You move from arguing about fault to simply establishing a timeline.

Snowflake Time Travel for Benchmarking, Not Just Recovery

Everyone sells Time Travel as a disaster recovery tool. We use it for benchmarking. If you build a fixed version of a table and compare it to the original, a silent upstream reload can completely skew your results. Pinning both sides of your comparison to the same Time Travel timestamp gives you a bulletproof “before and after” to defend in front of a client.

Solving the Mid-Run Problem

Time Travel also solves the mid-run problem. Some tables get overwritten multiple times in a single pipeline execution, so the data sitting there at 9:00 AM isn’t necessarily the state your fix needs to address. Anchoring to the specific query that performed a write lets you inspect the table exactly as it existed between steps. You get to validate your logic against the actual state it was meant to modify.

Snowflake Account Usage: Map Access Without a Meeting

Finally, Account Usage views let you map out the entire role, grant, and ownership structure without booking a single discovery meeting. Walking into a massive legacy data estate and accurately describing its access model on your second day builds more trust than a slide deck ever could.

The Catches

There are catches, of course. Execution history only knows what actually ran, so it won’t help you with code that exists but hasn’t been triggered. And Account Usage views have built-in latency. That’s well documented, but it’s incredibly easy to forget when you’re staring at a screen waiting for immediate confirmation.

Fix the System That Exists

None of these features are hidden. They ship out of the box, but most teams only remember they exist after something breaks. We pull them up first, before writing a single line of code. In mature estates, the pipelines are usually older than the tenure of the people maintaining them, and the repository has quietly drifted away from reality.

At the end of the day, the engineering work is the same. The only difference is whether you’re fixing the system that exists, or the one you assumed was there.

Work With Pomerol Partners

The good news is that we at Pomerol Partners can make this effort worthwhile. Our consultants are Snowflake specialists, certified through Snowflake and proven through experience.

At Pomerol Partners, we don’t just improve your data structure. We offer a DataOps 360 approach to your business.

Come and meet the human side of data.

More on what we do with Snowflake: pomerolpartners.com/partners/snowflake

Diego Brito
Senior Consultant

Snowflake Documentation

Monitor query activity with Query History

https://docs.snowflake.com/en/user-guide/ui-snowsight-activity

Understanding & using Time Travel

https://docs.snowflake.com/en/user-guide/data-time-travel

Account Usage

https://docs.snowflake.com/en/sql-reference/account-usage