Warehouses
Snowflake — planned
ACCOUNT_USAGE gives a year of query, copy and task history — including rows loaded and rows rejected. This integration is planned: documented here as reference, not connectable from the admin today.
Snowflake has the best retrospective metadata of any platform here.
SNOWFLAKE.ACCOUNT_USAGE retains up to 365 days of query history, copy history and
task history, which means an investigation into something that happened three months ago is
actually possible — a sentence that is false almost everywhere else.
COPY_HISTORY is the standout for ETL specifically: it records
ROW_COUNT, ROW_PARSED and ERROR_COUNT per file per
load, which is a file-level reconciliation recorded automatically.
Snowflake today
Decim does not connect to warehouses today. Transformation SQL kept in GitHub is read as code. When the deciding evidence is a count or a row in the warehouse, Decim writes a read-only query for your team to run — validated against a read-only allowlist, never executed by Decim — and the result triggers a new revision of the hypotheses.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned Snowflake integration: what it is designed to read, and why.
What Decim will read from Snowflake
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| Query history | ACCOUNT_USAGE.QUERY_HISTORY | Statement text, duration, rows produced, warehouse and user |
| Load history | ACCOUNT_USAGE.COPY_HISTORY | Per-file rows parsed, loaded and errored |
| Task runs | ACCOUNT_USAGE.TASK_HISTORY | Scheduled task outcomes and their dependency graph |
| Object access | ACCOUNT_USAGE.ACCESS_HISTORY | Which query read and wrote which object — lineage |
| Table metadata | ACCOUNT_USAGE.TABLES | Row counts and bytes, refreshed periodically |
| Pipe activity | ACCOUNT_USAGE.PIPE_USAGE_HISTORY | Snowpipe ingestion volumes |
| Dynamic tables | INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY | Refresh outcomes and lag |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
CREATE ROLE decim_agent;
-- ACCOUNT_USAGE is the shared database of account metadata.
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE decim_agent;
-- A small warehouse for Decim's own queries, so its usage is
-- attributable and separately capped.
CREATE WAREHOUSE decim_wh WITH WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 60 AUTO_RESUME = TRUE;
GRANT USAGE ON WAREHOUSE decim_wh TO ROLE decim_agent;
-- Reconciliation tables only.
GRANT USAGE ON DATABASE sales TO ROLE decim_agent;
GRANT USAGE ON SCHEMA sales.public TO ROLE decim_agent;
GRANT SELECT ON TABLE sales.public.rejected_transactions TO ROLE decim_agent;
CREATE USER decim_agent DEFAULT_ROLE = decim_agent
DEFAULT_WAREHOUSE = decim_wh;
GRANT ROLE decim_agent TO USER decim_agent;What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Object-level lineage from ACCESS_HISTORY, covering ad-hoc work as well as scheduled
- File-level load reconciliation from COPY_HISTORY
- Task dependency graphs and their run outcomes
- Up to a year of history, which makes slow-burn investigations viable
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Rows rejected during load | ERROR_COUNT non-zero with ON_ERROR = CONTINUE |
| File loaded twice | Same file name appearing twice in COPY_HISTORY |
| Task chain stopped | A root task suspended, so no downstream task runs |
| Ad-hoc write to production | ACCESS_HISTORY write with no corresponding task |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
ACCOUNT_USAGE.TABLES.ROW_COUNTis refreshed periodically and is not transactionally accurate- ACCESS_HISTORY requires Enterprise Edition or above
- Decim's own queries would consume credits — hence the separate, small, auto-suspending warehouse
Related integrations
- dbt — manifest.json is the model graph; run_results.json is what actually happened. Both are artefacts, not APIs.
- Fivetran — Will read sync history and schema change events via API, plus the _fivetran_synced column in every target.
- BigQuery — INFORMATION_SCHEMA.JOBS gives every statement, its referenced tables and its output row count.
- ClickHouse — system.query_log carries read_rows and written_rows per statement; system.parts carries real write activity.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a Snowflake pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.