## TL;DR

Seed generators intentionally do per-row writes and reads in bulk; that traffic pattern does not exist in production and optimizing it like a hot endpoint is wasted work. Confirm the flagged traffic comes from the seed job, re-run the analysis on production-shaped traffic, and tag seed and backfill jobs so the detector excludes or separately analyzes them.

## The query

```text
agent flagged an N+1 from the staging seed-data generator -- a traffic pattern that doesn't exist in production
```

## Steps

### 1. Identify the source of the flagged traffic

Find which process or job issued the flagged queries: check the connection's application name, database user, or the timestamps against the seed job's schedule.

Expected: the flagged queries trace back to the seed-data generator run, not to user traffic.

### 2. Confirm the pattern is staging-only

Compare against production query patterns for the same tables over a representative window. Look for the seed job's signature (bulk per-row inserts, full-table reads in a tight loop) in production.

Expected: the pattern appears only in staging during seed runs; production shows nothing like it.

### 3. Re-run the analysis on production-shaped traffic

Point the detector at production traffic (or a production traffic replay) for the same code paths and re-evaluate.

Expected: the alert disappears because the pattern it flagged never occurs there.

### 4. Tag seed, migration, and backfill jobs

Give every non-user-traffic job an identifiable marker: a dedicated database user, an application name, or a query comment. Configure the detector to exclude tagged traffic from hot-path N+1 analysis, or to analyze it under a separate "batch job" profile with different thresholds.

Expected: future seed runs do not produce hot-endpoint N+1 alerts.

### 5. Decide whether the seed job itself needs help

If the seed run is painfully slow, that is a separate problem with separate fixes (bulk COPY instead of per-row inserts, batched reads), not an N+1 on a hot endpoint. Treat it as batch-job tuning.

Expected: either the seed job is accepted as-is, or it gets batch-tuned on its own terms.

## Use this when

- The flagged queries come from a seed generator, fixture loader, or bulk import
- The traffic pattern has no production equivalent
- The alert appeared right after a staging reseed
- The detector analyzes all database traffic without a source filter

## Not for this skill when

- The flagged traffic is real user traffic (genuine N+1)
- The seed job's slowness actually blocks deploys (tune the job itself)
- The duplicates are retries, instrumentation queries, or log-line miscounts
- Staging traffic faithfully mirrors production

## Variant phrasings

### N+1 on seed data

Seed data loading is bulk work by nature. Analyze it as a batch job, not a hot endpoint.

### bulk import flagged as N+1

Same answer: the import's per-row pattern is intentional and one-off. Exclude or re-profile.

### staging-only query pattern alert

Any alert on traffic that cannot occur in production is a detector scoping problem.

## Why it happens

Detectors usually watch the database, not the traffic source. Staging databases see a mix of user-like traffic and operational jobs, and the detector cannot tell a seed run from a rush hour. The agent saw a genuine query pattern (many similar queries in sequence) and applied hot-endpoint reasoning to batch work where per-row operations are the correct and intended shape.

## Edge cases

- Seed jobs that run against production (backfills): those do affect production and deserve analysis, but under batch-job thresholds, not hot-endpoint ones.
- Shared staging databases: another team's seed run can trigger your detector. Source tagging (step 4) fixes this regardless of who runs the job.
- Seed data used for load tests: if the load test itself replays seed-shaped traffic, the test is unrepresentative. Fix the test's traffic model.
- Slow seeds blocking CI: a seed that takes 30 minutes is worth tuning with bulk loading, but that is throughput work, not N+1 work.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6iZgFbQPUt1HSAWYsX1XAg