Snowflake platform review: cost, performance, and security

I conducted a read-only review of the company's Snowflake platform while documenting it for the documentation library. Reading the account's own telemetry, rather than asking someone what the setup looked like, surfaced cost, performance, and access findings that did not match the accepted picture of the environment.

The whole pass was read-only and done through Claude Cowork with the browser extension, driving queries against ACCOUNT_USAGE from an authenticated session. No new credentials, no connector to provision, no access request to justify: the same read a platform owner could run themselves, just actually run.

What the platform actually looked like

The documented view came out of introspection rather than recollection: the database, warehouse, user, and integration inventory, along with the role model and how the BI layer connects. That last part corrected the record. The documentation had assumed Power BI reached Snowflake over single sign-on; it does not, and identifying the service account it actually authenticates with mattered for the access finding below.

Three findings

• Cost is concentrated in reporting, and idle time is a real line item. Reporting workloads accounted for roughly half of all compute credits. More actionable: several warehouses were idling ten to thirteen minutes before auto-suspending, against a norm of one to two minutes for interactive use, so the account was paying for warehouses doing nothing. On top of that, warehouses had accumulated with overlapping and legacy purposes, several clearly test or development leftovers.
• The Power BI warehouse was undersized for both concurrency and memory. Over two weeks it showed millions of seconds of cumulative queue time, an average wait of several minutes per query, alongside terabytes of local spill to disk. Those are two different problems with two different fixes: queueing calls for a multi-cluster auto-scaling warehouse, spilling calls for a larger size. The useful part is that this was also the single largest cost line, so right-sizing it addressed the platform's worst user-facing latency and its biggest expense in the same change.
• The access model needed tightening. The review surfaced service-account and consultant-access scoping that had drifted wider than its purpose required, along with role assignments that had accumulated beyond their original intent. The fixes were contained ones: purpose-specific roles, tighter authentication, and scoping each identity to what it actually needs. All of it went to the platform owner with recommended remediation, and none of it required privileged access to find.

Why it mattered that IT ran it

None of these findings needed privileged access or a tool the owning team lacked. They needed someone to sit down and read the account's own usage data end to end, which is the kind of pass that is easy to defer when a team is heads-down on delivery. The findings went to the BI and data team as the platform owner, framed as observations with recommended fixes rather than as an audit result.

This is a fair illustration of a pattern in how I work: documentation done properly is an audit. You cannot write down what a system actually does without noticing where it is wasteful, slow, or over-permissioned.

What this demonstrates

• Reading a platform from its own telemetry rather than from tribal knowledge, and correcting the documented record when the two disagreed.
• Connecting cost and performance instead of treating them separately The undersized warehouse was simultaneously the latency complaint and the largest bill; naming that link is what made the fix easy to approve.
• Security review as part of ordinary work Access-scoping gaps found by looking at the platform's own telemetry rather than by scheduling an assessment.
• Working credibly across a team boundary Technical findings on someone else's platform, delivered as recommendations to the owner.