SupabaseSupabase + CHION

Supabase text-to-SQL
that shows the query and supports promotion for reuse

Chion is Supabase text-to-SQL from outside the dashboard. The Supabase dashboard's own AI assistant writes SQL and runs it in the SQL editor, and it stays the shorter path when you are already there. Chion connects with the Postgres role you supply, code-validates every SELECT before it runs, shows the statement under the chart, and compiles the queries your team saved into skills you can move to Claude Code or Codex.

  • No OpenAI key of your own
  • Credentials sealed in an AES-256-GCM envelope, RLS by connected role

Read-only SELECT · 1,000-row cap · no OpenAI key of your own

Chion connects to your Supabase Postgres as an AI SQL analyst over the direct endpoint or either Supavisor pooler. Your password is sealed in an AES-256-GCM envelope. Plaintext is decrypted into memory for a single request, held for at most 60 seconds or five reads, then purged. Each result stops at 1,000 rows, and the policies on the role you supply filter what comes back. A query a reviewer saves compiles through the SQL skills generator for Claude Code or Codex. Thread enough of those saved queries together and the chat surface becomes an AI SQL workforce. Follow-up questions are covered on the multi-turn analytics page.

Chion writes a read-only SELECT and leaves the executed query beneath the chart, then hands the saved version back as a skill you own (see how Chion compares to BI dashboards).

A saved query compiles into a portable SQL skill you own.

Connect Supabase read-only without an OpenAI key

What changes when your Postgres is a Supabase project.

Direct endpoint, session mode, or transaction mode

Use the direct endpoint (db.<ref>.supabase.co) on port 5432, Supavisor session mode on port 5432 at the pooler host (aws-0-<region>.pooler.supabase.com), or Supavisor transaction mode on port 6543 for high-concurrency teams. Transaction mode drops prepared statements; Chion sends plain SELECT statements, so all three paths work. 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, the same Postgres and Auth you already use

Chion is built on Supabase Postgres, Auth, and Edge Functions. Your connection password is sealed in an AES-256-GCM envelope by Chion's own application code, not by Supabase Vault. See how Chion compiles a code-validated 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)

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, session, or transaction pooler: which port?

Supabase gives you three connection paths. The direct connection on port 5432 supports every PostgreSQL feature, including prepared statements. Supavisor session mode answers on port 5432 at the pooler host and holds one Postgres connection per client session. Supavisor transaction mode answers on port 6543 and does not support prepared statements; Chion sends plain SELECT statements, so transaction mode works. 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

Chion runs as the role you supply, so the policies attached to that role filter every result. For full visibility, either write policies that grant the read-only role access, or give the role the BYPASSRLS attribute and accept that policies no longer filter it.

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

The password for your read-only Postgres role is sealed in an AES-256-GCM envelope. Plaintext is decrypted into memory for a single request, held for at most 60 seconds or five reads, then purged. Chion connects read-only, and the validators drop anything that is not a single read-only SELECT before it runs. Your row-level security policies apply as the connected role carries them, so a role without BYPASSRLS stays filtered.

Read the full 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, to the extent the role carries them. Chion connects as the PostgreSQL role you supply, so the policies attached to that role are the ones that apply. A role with the BYPASSRLS attribute, a table owner, or a superuser is not filtered by RLS, so create the read-only role without those privileges when you want policies enforced.
Can I use the Supabase transaction pooler?
Yes. Use port 6543 and the pooler hostname. Transaction mode does not support prepared statements, and Chion sends plain SELECT statements, so that limit does not bite. Use session mode on port 5432 at the same host if something else on the connection needs prepared statements.
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, and Edge Functions. Your database password is sealed in an AES-256-GCM envelope written by Chion's own application code rather than by Supabase Vault. Plaintext is decrypted into memory for a single request, held for at most 60 seconds or five reads, then purged.
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.
How is Chion different from connecting Supabase to Claude with MCP?
MCP gives Claude raw access to your database. Chion sits behind read-only credentials in an encrypted vault, checks each SELECT in code before it runs, and keeps the executed query on screen beneath the chart.
How is Chion different from dashboard-first AI analytics tools for Supabase?
Dashboard-first tools ship prebuilt dashboards and alerting out of the box, and they remain the stronger pick if that is the whole job. Chion's difference is inspection and ownership: the executed read-only SELECT stays on screen line by line, and a query your team saves compiles into a portable skill that runs in Claude Code or Codex.

Other PostgreSQL providers

Chion connects to Neon, Supabase, Amazon RDS, Google Cloud SQL, and Azure Database for PostgreSQL.

Ready to connect your Supabase database?

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

Start your 7-day trial