SupabaseSupabase + CHION

Ask your Supabase Postgres in plain English
get SQL you can verify

  • Verified read-only SQL
  • NL→SQL agent for Supabase Postgres
  • AI SQL skills you export to Claude Code, Cursor & Codex
  • No OpenAI key — runs on the Supabase Vault/Auth/RLS you already trust

Connect your Supabase Postgres and ask the questions you'd hand a senior analyst — and get back read-only SQL you can read line by line before it runs, plus an interactive chart. Unlike the in-dashboard AI assistant, every answer becomes a portable skill your team owns and exports to Claude Code, Cursor, or Codex. Two-minute setup, no OpenAI key, read-only by design — and Chion runs on Supabase ourselves.

Verified SQL in under 10 seconds · 1,000-row cap · read-only by design

Chion turns your Supabase Postgres into an AI SQL analyst for conversational analytics — connect read-only, ask in plain English, and turn every verified query into a reusable skill with the SQL skills generator. Credentials are wrapped in an AES-256-GCM vault, every query runs as a read-only SELECT capped at 1,000 rows, and the row-level security on the role you provide is honored on every call. It is the AI SQL workforce your team can point at a Supabase project in two minutes.

The Supabase dashboard's AI assistant writes SQL and runs it for you — Chion writes read-only SQL you can verify, then hands it back as a skill you own.

Every verified answer exports as a portable SQL skill you own.

Connect Supabase read-only in two minutes — no OpenAI key

What changes when your Postgres is a Supabase project.

Direct endpoint vs the Supavisor pooler

Use the direct endpoint (db.<ref>.supabase.co) on port 5432, or the Supavisor transaction pooler (aws-0-<region>.pooler.supabase.com) on port 6543 for high-concurrency teams. The pooler puts the project ref in the username.

Point Chion at a read-only role — never anon or service_role

The anon and service_role keys are for Supabase's API layer, not direct database connections. Create a dedicated read-only PostgreSQL role with CONNECT, USAGE, and SELECT grants and point Chion at that.

Your RLS policies hold on every query

Chion connects as the role you provide, so any row-level security policies on that role apply to every query. The same read-only posture runs through Chion's security model.

Querying auth.users

Signup analytics live in the auth schema. Grant USAGE ON SCHEMA auth and SELECT ON auth.users to your read-only role, then ask Chion how many users signed up each month against auth.users.

Chion runs on Supabase too — same Vault, Auth, RLS you trust

Chion is built on Supabase — Postgres, Auth, Edge Functions, and Vault. Your credentials sit in Supabase Vault under AES-256-GCM. See how Chion compiles a verified SQL pipeline end to end.

Example question & SQL

See what Chion generates from a plain-English question.

You ask

"How many active users signed up each month this year?"

Chion generates

SELECT
  date_trunc('month', created_at) AS month,
  COUNT(*) AS new_users
FROM auth.users
WHERE created_at >= date_trunc('year', now())
GROUP BY 1
ORDER BY 1;

Create a read-only Postgres role

Run this once before you connect. Chion enforces read-only at the SQL validator, but a least-privilege role is the canonical pattern.

CREATE ROLE chion_read LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE <dbname> TO chion_read;
GRANT USAGE ON SCHEMA public TO chion_read;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO chion_read;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO chion_read;

Replace <dbname> with your database name. The ALTER DEFAULT PRIVILEGES line ensures new tables are auto-readable.

Connection string format

Reference for parsing. Chion accepts the six fields directly, no string concatenation needed.

postgresql://chion_read:<password>@aws-0-<region>.pooler.supabase.com:6543/postgres?sslmode=require

Finding your Supabase credentials

Project Dashboard → Connect button (top of page)

Project Dashboard → Connect button (top of page)

FieldWhere to FindDefault
Server (Host)Connect → View parameters under "Direct connection"db.<project-ref>.supabase.co
PortSame panel · Direct: 5432, Transaction pooler: 65435432
DatabaseSame panelpostgres
SchemaNot shown in UI; default is publicpublic
UserSame panelpostgres
PasswordSet at project creation. Reset in Settings → Database(not displayed after creation)

Quick steps

  1. 1.Log in at supabase.com/dashboard
  2. 2.Select your project
  3. 3.Click the Connect button at the top of the page
  4. 4.Click "View parameters" under the Direct connection string
  5. 5.All fields (host, port, database, user) are displayed individually
  6. 6.Password must be the one you set at project creation (or reset it in Settings → Database)
Open Supabase console

Supabase troubleshooting

Common issues and how to fix them.

Direct vs transaction pooler: which port?

Use port 5432 for direct connections (supports all PostgreSQL features). Use port 6543 for the transaction pooler (better for high-concurrency). The host format differs: direct uses db.<ref>.supabase.co, the pooler uses aws-0-<region>.pooler.supabase.com with the project ref in the username.

Password not displayed after creation

Supabase shows the database password only at project creation. If you lost it, reset it in Settings → Database → Database password.

RLS blocking queries

If you use a role subject to RLS policies, Chion's queries will respect those policies. For full visibility, create a dedicated read-only role that bypasses RLS, or grant it the appropriate RLS exceptions.

auth.users schema not visible

The auth schema is owned by the supabase_auth_admin role. Grant USAGE on schema auth and SELECT on auth.users to chion_read so Chion can query signup analytics. Other auth.* tables follow the same pattern.

Official Supabase documentation

Authoritative references from the provider. Opens in a new tab.

Your credentials are encrypted

All connection credentials are encrypted with AES-256-GCM and stored in an isolated vault. Chion connects with read-only permissions. No INSERT, UPDATE, or DELETE is ever possible. Row-level security policies are honored on every query.

Read our security model

Frequently asked questions

Common questions about using Chion with Supabase.

Should I use the anon key or service_role key?
Neither. Create a dedicated read-only PostgreSQL role with CONNECT, USAGE, and SELECT grants. The anon and service_role keys are for Supabase's API layer, not direct database connections.
Does Chion honor Supabase RLS policies?
Yes. Chion connects as the PostgreSQL role you provide. If that role is subject to RLS policies, all queries respect those policies. The LLM never sees row data, only schema metadata and aggregated results.
Can I use the Supabase transaction pooler?
Yes. Use port 6543 and the pooler hostname. Chion's query pattern is compatible with Supavisor's transaction pooling mode.
Does Chion work with Supabase Realtime, Edge Functions, or Storage?
Chion connects directly to the PostgreSQL database. Realtime, Edge Functions, and Storage are separate Supabase services and are not queried by Chion. Anything stored in your Postgres tables is fair game for analysis.
Does Chion itself run on Supabase?
Yes. Chion is built on Supabase (Postgres, Auth, Edge Functions, Vault). Your credentials are encrypted in Supabase Vault with AES-256-GCM. We use the same security primitives we recommend to customers.
How do I query auth.users from Chion?
Grant SELECT on auth.users to your chion_read role: GRANT USAGE ON SCHEMA auth TO chion_read; GRANT SELECT ON auth.users TO chion_read. Then ask Chion questions like "how many users signed up this month?" against the auth.users table.

Other PostgreSQL providers

Chion connects to all major managed PostgreSQL services.

Ready to connect your Supabase database?

Open Chion, enter your credentials, and start asking questions in plain English.

Start your 7-day trial