Skip to main content

SQL Console

When you need a quick answer that widgets do not surface — a one-off count, a join across objects, an export for an auditor — the SQL Console lets you run SQL against your app database from the Builder. You keep using logical object and field names (the labels you already know), while Bobuild translates them safely behind the scenes.

Typical scenarios:

  • investigate “how many open tickets were created last month?” without building a temporary grid;
  • export a custom CSV for finance or compliance;
  • validate that an import landed correctly before users see it;
  • explore relationships while designing auto fields or filters.

The console is marked Experimental: powerful for builders, with guardrails so everyday apps stay safe.

Opening the console​

From an object in the Builder, open the SQL Console (also listed among builder tools). You get an editor, Run, paginated results (50 rows per page), schema-assisted autocomplete, and Export CSV.

Writing queries​

Prefer object and field names as you see them in the Builder, for example:

SELECT users.email, users."Full name"
FROM users
WHERE users.active = true
ORDER BY users.email
LIMIT 100

Short names and quoted labels are both accepted where configured.

Limits and protections​

  • Only an allowlisted set of SQL functions is permitted (string helpers, aggregates, date conversion helpers, window functions such as row_number, JSON helpers such as jsonb_agg / jsonb_build_object, GREATEST / LEAST / NULLIF, CARDINALITY, and similar). Dangerous or exotic functions are rejected.
  • Password fields: omitted from schema hints and from broad SELECT results so secrets do not leak into the console. You can set them with INSERT / UPDATE — Bobuild hashes the value and enforces the same password strength rules as the live app (at least 16 characters, or at least 8 with a number, a lowercase letter, and an uppercase letter).
  • Global objects: INSERT and DELETE are blocked; UPDATE of the single shared row remains possible.
  • Export CSV is for SELECT results and is capped (up to 100,000 rows) — use filters for very large extracts.

Using the console responsibly​

  • Prefer SELECT for exploration; keep writes rare and intentional.
  • Do not use the console as your everyday operator UI — build grids and forms for recurring work.
  • Password values are never returned in result grids, but other sensitive columns are not masked — avoid exporting more than you need.
  • Test destructive ideas on a snapshot restore first, never on production “to see what happens”.
  • For routine CSV extracts operators can run themselves, prefer grid export or a documented API endpoint.

Run SQL command in a task​

When you need the same kind of SQL as part of a workflow — not only from the Builder — add a Run SQL command action to a task. Typical uses: a one-off data fix you trigger from a grid button, a maintenance update on a schedule, or a bulk write that widgets cannot express.

Configure it like this:

  • Write the command with logical object and field names, the same way as in the console (for example UPDATE tickets SET status = 'closed' WHERE status = 'resolved').
  • Test the statement in the SQL Console first (validation and autocomplete).
  • Use Repeat this action so the command runs once, or once per input record.
  • Task conditions still decide whether the action runs at all.

The action uses the same allowlist and protections as the console, and it may write (insert, update, delete). It runs outside the rest of the task’s database transaction: if a later action fails, changes made by this SQL are not rolled back.

Failed commands are recorded under Error Logs in the Builder sidebar (type SQL command, with the statement that failed). Open that page to inspect recent failures.

tip

For admin CSV loads and exports outside SQL, see Builder import and export.