Query Safety Boundaries

Developer utilities can cause real risk if they allow unrestricted execution. SQL Runner addresses this with policy-first controls. Understanding these controls helps teams use the tool correctly and avoid false expectations.

Allowed vs Blocked Statements

Only SELECT and WITH patterns are allowed under the default policy. Mutation and DDL categories are rejected.

Semicolons and multi-statement chains are blocked to prevent statement stacking and ambiguous intent.

Timeout and Resource Limits

Request-level timeouts and bounded page sizes reduce runaway query impact.

Export operations use hard row limits to keep memory usage and cost predictable.

Rate Limiting

Per-route and per-IP rate controls reduce abuse potential and protect service availability for normal users.

Teams should still apply upstream controls such as network boundaries and credential scoping.

Audit Logging Principle

Operational logs should support investigation without storing full sensitive SQL payloads.

Hashing and preview truncation allow traceability while minimizing exposure risk.

Shared Responsibility

The platform enforces safety boundaries, but users remain responsible for query intent and downstream data sharing.

Use least-privilege DB credentials and avoid querying sensitive domains without a clear business need.

What happens when a rejected statement is submitted

When a query beginning with INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, TRUNCATE, GRANT, REVOKE, or EXEC is submitted, SQL Runner rejects it before opening a database connection. The validation happens at the application layer and the error message returned is: "Only SELECT statements are allowed." This behavior is intentional to keep execution scope explicit and prevent accidental mutation attempts through a browser utility surface.

Because validation is completed before connection and execution, rejection is effectively immediate. There is no database round-trip, no query planning phase, and no execution attempt against target tables. This reduces risk and lowers load under misuse conditions. It also gives users deterministic feedback quickly so they can rewrite inspection queries in allowed read-only form rather than waiting for backend timeout-style failures.

Rate limiting and abuse prevention

SQL Runner enforces a limit of 30 queries per minute per IP address. Requests exceeding this limit receive an HTTP 429 response with a Retry-After header indicating when the window resets, typically around 60 seconds from the first request in the current interval. This policy protects shared infrastructure from scripted bursts and preserves service responsiveness for normal interactive users who run bounded diagnostic queries.

Rate limiting should be treated as a design constraint, not an inconvenience to bypass. If you need to run a sequence of checks, add delay between requests and combine redundant probes into fewer targeted statements. Automated loops with no pacing will hit the limit quickly and provide less useful evidence than a compact, hypothesis-driven query set. For batch analytics or load-oriented testing, use dedicated environments outside SQL Runner operational boundaries.