Search docs
Docs searchValidation rule
Back to Rule CatalogAP-DQR-006Data / Query RiskLarge collection loaded then processed in memory
Flags query flows that load broad collections and filter or aggregate them in memory.
warningviolationNo auto-fix
How to fix
- Push filtering, projection, and aggregation into the query.
- Apply limits before loading records.
- Move large exports to explicit batch workflows.
What the rule validates
A workflow appears to fetch more rows than it needs before applying filtering or aggregation.
Why it matters
In-memory processing can degrade latency and memory use for large tenants or repositories.
Common causes
- Filtering was easier to express in application code.
- Pagination was applied after fetching all rows.
- A report path reused online request code.
Typical violation example
findMany(...) loads all findings, then filters open findings in JavaScript.Typical compliant example
findMany({ where: { status: 'open' }, take: pageSize }).Related rules
AP-DQR-001 - Missing tenant filter evidence in multi-tenant SQLAP-DQR-002 - Broad SELECT * usage in query pathAP-DQR-003 - Unbounded query risk without limit/pagination evidenceAP-DQR-004 - Cross-module direct database access bypasses module boundary
Adjacent categories
Related files/config
apps/api/srcpackages/db/prisma/schema.prisma
Related CLI commands
archpilot validatearchpilot validate --ci
Related docs