Skip to content
[ PIER ]

SQL Runner

The SQL Runner executes an arbitrary statement against the selected database. It sits below the browser in the Data tab as a collapsible panel — closed by default, so you browse first and drop into the runner when you need it.

Running a statement requires the Editor role on the resource, because it can mutate data. (Browsing only needs Viewer — see Access & audit.)

Reads vs. writes

Section titled “Reads vs. writes”

Pier classifies each statement by its leading keyword (after stripping leading comments):

  • Reads — SELECT, WITH, VALUES, TABLE, SHOW, EXPLAIN, DESCRIBE/DESC. The result comes back as a grid.
  • Writes — anything else (INSERT, UPDATE, DELETE, DDL, …). The result is the affected-row count.

The classification is conservative: anything not clearly a read is run as a write. A trailing semicolon is stripped automatically so single statements just work.

Result grid & limits

Section titled “Result grid & limits”
  • Row cap. A read is capped at 1,000 rows. If the result is larger, the grid shows the first 1,000 and flags the result as truncated — narrow it with a WHERE or LIMIT to see the rest.
  • Every column is text. Results are cast to text so any column type renders in the grid. If your statement returns unnamed or duplicate columns, add explicit aliases — Pier asks for them rather than guessing.
  • Statement timeout. Each connection sets a 15-second statement timeout (statement_timeout on Postgres, max_execution_time on MySQL), so a runaway query can’t pin the database.
  • Duration. Every run reports how long it took.

Tips

Section titled “Tips”
  • Use the Database selector to target a specific database; leave it on the default to use the service’s primary database.
  • For large tables, prefer LIMIT/OFFSET or a WHERE clause over scrolling the full grid.
  • Statements that return no rowset (for example a bare SET) are executed and reported as an affected-row count.

Auditing

Section titled “Auditing”

Every runner execution — success or failure — is written to the db_query_log audit table: who ran it, the database, the SQL text, whether it was a read or write, the status, row count and duration. See Access & audit for the full picture.

Next steps

Section titled “Next steps”