Query Cost Guardrails

A governed layer shouldn't let an innocent question turn into a warehouse-melting scan. Before any generated query runs, Colrows estimates its cost, classifies it into a tier, and can block the runaway ones - so a badly-shaped question fails fast instead of running up a bill.

How it works

When a natural-language question is compiled into SQL, Colrows estimates the query's cost immediately before it runs - on both the AI Data Analyst path and the MCP askData (execute) path. The estimate is row-oriented ("how many rows would this touch"), classified into tiers, and logged. There's nothing to configure per query.

• Warn - large but allowed; recorded.
• High - unusually large; recorded and flagged.
• Blocked - beyond the ceiling, or an unbounded result with no limit.

Each estimate carries a confidence level and a plain-language list of the assumptions it made - for example, a table with no profiled row count, or a join with no statistics. A query the platform can't estimate always passes.

Report-only by default

Out of the box, guardrails are report-only: every query is estimated and logged, but nothing is refused. An operator turns on enforcement per deployment once the estimates are trusted. With enforcement on, a query classified blocked fails the request and the caller receives the estimate's summary; everything below the ceiling runs normally.

Thresholds (the warn level, the block level, the unbounded-result cap) and the enforcement toggle are deployment configuration, set by an operator - not per-user settings.

Row caps on data tools

Independently of the cost estimate, the MCP and REST data tools cap how many rows come back: maxRows defaults to 1,000 and cannot exceed 5,000, and any capped result is marked truncated: true so a caller never mistakes a partial set for the whole answer.