# Snowpipe

> Snowpipe bills serverless credits per file processed plus per byte ingested, not per warehouse-second, so 10,000 tiny files cost far more to load than 1 large file carrying the same data. ZopNight discovers pipes with SHOW PIPES IN ACCOUNT and attributes Snowpipe credits inside account cost so ingestion spend stays visible.

Source: https://zop.dev/integrations/snowflake/pipe
Updated: 2026-08-19

---

A pipe continuously loads files into a table as they land in a stage. Its meter is unlike anything else in Snowflake: serverless credits charged per file processed and per byte ingested, with no warehouse involved. That makes the shape of your files a first-order cost input, not just their total volume.

## Files are the unit of billing

Because Snowpipe charging includes a per-file component, 10,000 one-kilobyte files cost dramatically more to ingest than a single 10 MB file carrying the same rows. Event-driven producers that flush a tiny object every few seconds are the classic expensive pattern, and batching upstream into larger files is usually the entire fix, with no Snowflake-side tuning required.

## A meter that scales with noise

A pipe attached to a chatty, low-value feed converts every upstream event into spend, regardless of whether anyone ever queries the target table. Unlike a warehouse there is nothing to suspend: ingestion cost is controlled at the source, by sizing files sensibly and by deciding which feeds deserve continuous loading at all.

## Discovery and attribution

ZopNight lists pipes with `SHOW PIPES IN ACCOUNT`, parenting each to its database and skipping pipes inside Snowflake-provided shares. Snowpipe is one of the four serverless credit streams priced within account cost, so per-file ingestion charges never hide inside an undifferentiated total where nobody owns them.

## Small-file symptoms show in the history

The ratio of files to bytes is the diagnostic. Healthy batch ingestion shows few files and many bytes per file; the failure signature is the reverse. An enormous file count moving very little data means the per-file component of the meter dominates.

## Trace pipe spend to its files

```sql
SELECT pipe_name,
       SUM(credits_used)   AS credits_30d,
       SUM(files_inserted) AS files_30d,
       SUM(bytes_inserted) AS bytes_30d
FROM SNOWFLAKE.ACCOUNT_USAGE.PIPE_USAGE_HISTORY
WHERE start_time > DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY pipe_name
ORDER BY credits_30d DESC;
```

Rows here can lag live ingestion by 45 minutes to 3 hours. Divide bytes by files per pipe: a small quotient on a big credit number is the upstream-batching conversation, ready-made.