CLI workflow

Query Supabase Safely with a CLI

Inspect local project state first, identify the linked project explicitly, and use a read-only database path for production data.

DatabasesRead only

Prepare tools, authentication, and evidence first

Install the recommended tools, confirm minimum permissions, and keep compatibility separate from real execution records.

supabasedocs-verified
Manage local Supabase development, migrations, functions, and linked projects with explicit environment risk.

Recommended install

$ shell
npm install --save-dev supabase
Authentication
access token, database password, local development
Tested agents
No agent-specific execution record
Evidence status
docs-verified · Documentation checked 2026-07-10
Independent CLI execution
No independently executed version recorded
psqlverified
Query PostgreSQL non-interactively with explicit credentials, output, transactions, and write boundaries.

Recommended install

$ shell
brew install libpq
Authentication
connection URI, password file, service file, peer authentication
Tested agents
No agent-specific execution record
Evidence status
verified · Documentation checked 2026-07-10
Independent CLI execution
18.1 · 2 checks

Copy or download this workflow Skill

The Skill includes input and output contracts, recommended tools, approval points, rollback, and evidence boundaries. Review it against the active environment before saving.

query-supabase-SKILL.md
---
name: query-supabase-workflow
description: "Inspect local project state first, identify the linked project explicitly, and use a read-only database path for production data."
---

# Query Supabase

## Intended outcome

Answer Supabase project or database questions without crossing project boundaries or bypassing data protections.

## Evidence boundary

- Tool status distinguishes `docs-verified` material from independent execution; the two are not interchangeable.
- The current registry does not attribute a tool execution to a particular agent, so compatible agents cannot be called tested agents.
- Reconfirm the target account, environment, version, and official documentation before execution.
- Never auto-execute an R2, R3, or confirmation-marked step; obtain explicit approval immediately before it runs.

## Recommended tools, installation, and authentication

- **Supabase CLI** (evidence: `docs-verified`, docs checked: `2026-07-10`, no independently executed version recorded)
  - Install: `npm install --save-dev supabase`
  - Authentication: access token, database password, local development
  - Minimum permissions: Use a token limited to the intended organization and verify the linked project before remote commands.
- **PostgreSQL psql** (evidence: `verified`, docs checked: `2026-07-10`, independently tested version 18.1 recorded)
  - Install: `brew install libpq`
  - Authentication: connection URI, password file, service file, peer authentication
  - Minimum permissions: Use a read-only database role, TLS, and a database/schema search path limited to the task.

## Input contract

- Project directory
- explicit project reference
- read-only database credentials
- bounded question

## Output contract

- Local service status
- confirmed project identity
- bounded query result
- risk-aware next steps

## Safe workflow

1. **Inspect local state** — Read project configuration and local service status before connecting remotely.
   - Input: Supabase project directory
   - Output: Local configuration and service state
   - Risk: `read-only`
   - Command: `supabase status --output json`
2. **Confirm the remote target** — Verify the project reference and credential scope without exposing secrets.
   - Input: Project reference and protected credentials
   - Output: Confirmed remote target
   - Risk: `read-only`
3. **Run a bounded read** — Use psql or an approved data API with a read-only identity and explicit limits.
   - Input: Reviewed query and confirmed target
   - Output: Structured result
   - Risk: `read-only`

## Ask before proceeding

- Linking or unlinking a project
- Database pushes, migrations, resets, or function deployments
- Using a service-role key or changing production data

## Rollback

- Keep local configuration changes in version control
- Use reversible migrations for approved schema changes
- Restore a database backup only through the project’s incident procedure

## Official sources

- [Supabase CLI documentation](https://supabase.com/docs/guides/cli) — Official Supabase CLI reference for local development and project operations.
- [PostgreSQL psql documentation](https://www.postgresql.org/docs/current/app-psql.html) — Official psql options, variables, output formats, and execution behavior.

Outcome, inputs, and outputs

Define the result and evidence before the agent selects a command.

Goal

Answer Supabase project or database questions without crossing project boundaries or bypassing data protections.

Required inputs

  • Project directory
  • explicit project reference
  • read-only database credentials
  • bounded question

Expected outputs

  • Local service status
  • confirmed project identity
  • bounded query result
  • risk-aware next steps

Query Supabase Safely with a CLI: safe workflow

Run each step inside its stated boundary and verify the output before continuing.

Step 1Read only

Inspect local state

Read project configuration and local service status before connecting remotely.
Input
Supabase project directory
Output
Local configuration and service state
$ Inspect local state
supabase status --output json
Step 2Read only

Confirm the remote target

Verify the project reference and credential scope without exposing secrets.
Input
Project reference and protected credentials
Output
Confirmed remote target
Step 3Read only

Run a bounded read

Use psql or an approved data API with a read-only identity and explicit limits.
Input
Reviewed query and confirmed target
Output
Structured result

Approval points and rollback

Pause at the listed decision points and keep recovery instructions beside the action.

Ask before these actions

  • Linking or unlinking a project
  • Database pushes, migrations, resets, or function deployments
  • Using a service-role key or changing production data

Recovery plan

  • Keep local configuration changes in version control
  • Use reversible migrations for approved schema changes
  • Restore a database backup only through the project’s incident procedure

CLI, MCP, or API?

Choose the interface by execution location, identity, output contract, and permission boundary.

CLI

Best for local Supabase lifecycle and explicit project operations.

MCP

Useful when tools can enforce a narrow project and action set.

API

Prefer the data API when row-level security and application identity should govern reads.

Recommended approach

Use Supabase CLI for project context and a least-privilege API or database role for data queries.

Official evidence and references

Use these primary or upstream sources to verify current command behavior before acting.

Supabase CLI documentation

Official Supabase CLI reference for local development and project operations.

PostgreSQL psql documentation

Official psql options, variables, output formats, and execution behavior.

Questions before you run it

Should an agent use the service-role key?

Avoid it for routine queries because it can bypass row-level policies; use the narrowest available identity.

Is a local database reset safe?

It is destructive to local data. Confirm the target and whether fixtures can restore the expected state.

Related tools and guides

Browse sibling guides and choose the next page that best matches the active task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Inspect installation, authentication, structured output, command risk, and official evidence.