Integration
Connect Supabase to Polaris
Supabase is the connection where a careless key choice does the most damage, and the only one Polaris cannot yet check for you.
What connecting buys
Connecting Supabase gives a Polaris worker a project's database and auth through a project key from your Supabase dashboard. Supabase is the one connection in the catalog with no live verification call yet, so the key is stored and labelled as unvalidated rather than confirmed. Prefer a restricted key over a service-role key, which bypasses row-level security entirely.
- Credential
- Service-role or restricted key
- Live check
- None yet, and labelled as such
- Risk to weigh
- Service-role keys bypass RLS
Why the honest label matters
Nine of the thirteen credentialled connections are checked against the provider before Polaris writes anything. Slack, GitHub, Notion, Linear, Stripe, Figma, HubSpot, WhatsApp and Instagram all get a real API call, and a bad token is refused with the provider's own error.
Supabase does not have that check yet. The product says so in the stored label rather than showing a green state it has not earned. It is a small thing, and it is the difference between a connection you can reason about and one you have to test by watching a worker fail.
What the connection gives a worker
A product database, which is the most sensitive thing most companies own.
Your project data
Data-quality sweeps, metric definitions checked against reality, and the answer to a question that would otherwise become a ticket for whoever owns the schema.
Auth records
Signup and account state, useful for onboarding and support work and worth thinking twice about before you grant it.
A basis for reporting
Recurring reporting written from the source rather than from a dashboard export that drifted three weeks ago.
Choosing the key
Supabase issues several kinds. They are not interchangeable.
| Key | Reaches | Use it here? |
|---|---|---|
| Restricted key, scoped | Only what you granted it | Yes, this is the default worth taking |
| Service-role key | Every row, ignoring row-level security | Only if a task genuinely requires it, and knowingly |
| Publishable key | What an anonymous client can see | Fine when a worker only needs public data |
Workers and work this connection feeds
Hire an AI data analyst
It settles what active user means, writes the query that matches the definition, and turns the numbers you hand it into a paragraph an executive can read.
Hire an AI QA engineer
Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.
The null rate tripled in March and the board slide was already wrong
Row counts, null rates, orphans and freshness, checked every morning. Silence means clean.
The Monday metrics email that somebody writes on Sunday night
The numbers pulled and the paragraph written, delivered as a file rather than a link.
Three teams, three definitions of active user, one meeting
Every definition of a metric found and listed side by side, with the source of each.
Can you pull the numbers, sent as a direct message at 6pm
Every ask restated as a question, with the clarifying questions asked before anyone writes SQL.
Questions people ask
+Does Polaris check my Supabase key before storing it?
Not yet. Supabase is the one credentialled connection in the catalog without a live validation call, so the key is stored and the connection is labelled as not validated. Nine other connections do get a real API call and refuse a bad credential outright.
+Should I give a worker a service-role key?
Usually not. Service-role keys ignore row-level security and read everything in the project. A restricted key scoped to the tables a worker is briefed on does the same job for almost every task, with a fraction of the exposure.
+Is this how Polaris itself is built?
Yes, which is why the caution is specific rather than generic. Polaris runs on Supabase for Postgres, auth, realtime, row-level security and edge functions, and connection credentials are stored in that same database, written by an edge function and never read back into a browser.
+Can a worker write to my database?
That depends entirely on the key you stored. Supabase enforces the permissions, and Polaris uses the credential as issued. If you do not want writes, do not issue a key that can write.
Related
Every tool a Polaris worker can be given
One catalog, one credential per tool per organisation, authorized by an owner and used by every worker who carries it.
Hire an AI data analyst
It settles what active user means, writes the query that matches the definition, and turns the numbers you hand it into a paragraph an executive can read.
The null rate tripled in March and the board slide was already wrong
Row counts, null rates, orphans and freshness, checked every morning. Silence means clean.
The Monday metrics email that somebody writes on Sunday night
The numbers pulled and the paragraph written, delivered as a file rather than a link.
One analyst, thirty requests, and an AI worker in between
Five jobs that stand between a data team and the analysis they were hired to do.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.