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=requireFinding your Supabase credentials
Project Dashboard → Connect button (top of page)
Project Dashboard → Connect button (top of page)
| Field | Where to Find | Default |
|---|---|---|
| Server (Host) | Connect → View parameters under "Direct connection" | db.<project-ref>.supabase.co |
| Port | Same panel · Direct: 5432, Transaction pooler: 6543 | 5432 |
| Database | Same panel | postgres |
| Schema | Not shown in UI; default is public | public |
| User | Same panel | postgres |
| Password | Set at project creation. Reset in Settings → Database | (not displayed after creation) |
Quick steps
- 1.Log in at supabase.com/dashboard
- 2.Select your project
- 3.Click the Connect button at the top of the page
- 4.Click "View parameters" under the Direct connection string
- 5.All fields (host, port, database, user) are displayed individually
- 6.Password must be the one you set at project creation (or reset it in Settings → Database)
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.
- Supabase database connection guide
Direct vs pooler endpoints, ports, and connection-string formats.
- Supavisor transaction pooler
How transaction pooling on port 6543 differs from direct connections.
- Row Level Security
How RLS policies interact with the role Chion uses.
- PostgreSQL CREATE ROLE
Reference for the read-only role used by Chion.
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 modelFrequently asked questions
Common questions about using Chion with Supabase.
Should I use the anon key or service_role key?
Does Chion honor Supabase RLS policies?
Can I use the Supabase transaction pooler?
Does Chion work with Supabase Realtime, Edge Functions, or Storage?
Does Chion itself run on Supabase?
How do I query auth.users from Chion?
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