Engineering integration guide
Supabase + UbiGrowth workflows
Supabase is an open-source Postgres platform providing database, auth, and storage for applications. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Supabase part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a engineering workflow around Supabase with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Table, Row, Row Level Security Policy, Auth User, Storage Object, and Edge Function. Supabase identity flows through Postgres Row Level Security, so what a query returns depends on the key it used. The service role bypasses RLS entirely — using it for convenience removes the tenant boundary the schema was built to enforce.
Supabase is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
Launch is the usual destination for this connection, because the value shows up as a tool, dashboard, or internal surface built on the connected data.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
Engineering systems produce more signal than any other part of the business and the least usable summary. Supabase knows exactly what happened; turning that into something the rest of the company can act on is manual work that nobody owns.
The second problem is direction of risk. An integration that reads engineering activity is low-risk and useful. An integration that can act on infrastructure or production systems is a different category entirely, and the two are often discussed as if they were the same project.
You're likely here because
- Engineering activity is invisible outside the engineering team
- Incident context has to be reassembled manually every time
- Internal tool requests sit behind product work indefinitely
Record model
What a Supabase integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Supabase's.
Identity and matching
Supabase identity flows through Postgres Row Level Security, so what a query returns depends on the key it used. The service role bypasses RLS entirely — using it for convenience removes the tenant boundary the schema was built to enforce.
Start here
Read one table through the anon key with RLS active and confirm the policy returns exactly the rows the tenant should see, before building anything on top.
What this will not do
It will not make RLS optional. Any workflow that needs the service role should be reviewed as a security decision, not as a configuration detail.
The constraint to plan around
Connection pooling limits apply per project and long-lived connections from a workflow can starve the application. Use the pooler endpoint and treat connections as scarce.
Build notes
What you actually have to reason about in Supabase.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| auth.uid() | the identity RLS policies evaluate against; policies that ignore it are not policies |
| RLS enabled flag per table | a table with RLS off is fully readable by the anon key, which is the classic exposure |
| service_role key | bypasses RLS entirely — its use is a security decision, never a convenience |
| created_at / updated_at | the sync cursors, needing a trigger to maintain updated_at reliably |
| foreign key relationships | PostgREST derives its nested query shape from them, so schema design is API design |
Authentication
Anon key for RLS-governed client access, service role for trusted server contexts only. The service role key in any client-reachable context exposes every row in the database, and it is the single most consequential mistake available here.
Events and delivery
Realtime streams Postgres changes over websockets, subject to replica identity configuration. Database webhooks fire from triggers, which means they run inside the transaction and can slow writes.
Workflow
How the Supabase workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Connect read-only first
Supabase is connected with scoped, read-only credentials so context and reporting value can be proven without any action risk.
Step 02
Assemble the engineering picture
Delivery, incident, or operational activity is summarized in a form the rest of the business can act on rather than a raw feed.
Step 03
Build the internal surface
Launch produces the dashboard or internal tool that was never going to clear the product backlog, reviewed like any other internal service.
Step 04
Bound any action path
If the workflow needs to act, that path is specified separately with explicit scope, approval, and a record of what ran.
Design decisions
The engineering decisions this connection forces.
Each of these has to be settled before the Supabase workflow is allowed to write anything.
Step 01
Separate read from act
Reading Supabase for context and reporting is a different risk decision from letting a workflow act on it. Do not bundle them into one project.
Step 02
Make execution paths explicit
Any action that reaches a real environment should run through a reviewable execution path with a record of what ran, not an implicit side effect.
Implementation path
How to implement the Supabase workflow.
- 01
Start read-only against Supabase and produce something the team already wants: delivery visibility, incident context, or an operational summary.
- 02
Use scoped credentials rather than a shared token, and confirm what the scope can actually reach.
- 03
Build the internal surface in Launch, and review the result as you would any other contribution.
- 04
Once one policy is verified end to end, extend the same verification to every tenant-scoped table as an automated check rather than a one-off review.
Governance
Controls that matter.
Control 01
Credentials are scoped and workspace-approved; no shared secret belongs in a prompt or in generated code.
Control 02
Actions that reach production systems run through explicit, reviewable execution paths.
Control 03
Generated code and configuration are reviewed on the same terms as any other change.
Failure modes
How a Supabase integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
A tenant can read another tenant's rows.
Cause
RLS was not enabled on the table, or the service role key was used for convenience.
Fix
Enable RLS on every table by default and treat any service-role use as a reviewed security decision.
Symptom 02
The application starts failing to get a database connection.
Cause
A long-running integration held connections from the same pool.
Fix
Use the pooler endpoint, keep connections short-lived, and cap integration concurrency explicitly.
Symptom 03
Realtime stops delivering changes for a table.
Cause
Replica identity or publication configuration does not include it.
Fix
Verify the publication includes the table and that replica identity is set appropriately.
What changes at scale
Connection count is the hard ceiling rather than request rate. Anything horizontally scaled must go through the pooler or it will exhaust the database before it saturates anything else.
Examples
What a working Supabase workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Application data
With Supabase connected read-only, delivery and operational activity can appear alongside commercial context instead of living in a separate report.
Internal tool that was stuck in the backlog
A small tool reading Supabase gets built in Launch and reviewed like any other internal service, without consuming sprint capacity.
Limitations and considerations
What to validate before you depend on this.
- Connection pooling limits apply per project and long-lived connections from a workflow can starve the application. Use the pooler endpoint and treat connections as scarce.
- Writing with the service role bypasses tenant isolation. A workflow that "just needed it to work" can write one tenant's data into another's rows with no policy to stop it and no error to reveal it.
- When the workflow would require the service role to function. That requirement is a design signal to revisit the policy model, not a configuration step to accept.
- Write or action access to Supabase is a materially different risk decision from read access and should be scoped, reviewed, and approved separately.
- Generated code and configuration still require review. Speed of production does not change ownership of what ships.
FAQ
Supabase integration questions.
What records does a Supabase integration actually work with?
The primary records are Table, Row, Row Level Security Policy, Auth User, Storage Object, and Edge Function. Supabase identity flows through Postgres Row Level Security, so what a query returns depends on the key it used. The service role bypasses RLS entirely — using it for convenience removes the tenant boundary the schema was built to enforce.
What should the first Supabase workflow be?
Read one table through the anon key with RLS active and confirm the policy returns exactly the rows the tenant should see, before building anything on top.
What will a Supabase integration not do?
It will not make RLS optional. Any workflow that needs the service role should be reviewed as a security decision, not as a configuration detail.
What is the main constraint to plan around?
Connection pooling limits apply per project and long-lived connections from a workflow can starve the application. Use the pooler endpoint and treat connections as scarce.
What changes about a Supabase integration at scale?
Connection count is the hard ceiling rather than request rate. Anything horizontally scaled must go through the pooler or it will exhaust the database before it saturates anything else.
How does authentication work for Supabase?
Anon key for RLS-governed client access, service role for trusted server contexts only. The service role key in any client-reachable context exposes every row in the database, and it is the single most consequential mistake available here.
Does Supabase support webhooks, and can they be trusted?
Realtime streams Postgres changes over websockets, subject to replica identity configuration. Database webhooks fire from triggers, which means they run inside the transaction and can slow writes.
What is the risk of writing to Supabase?
Writing with the service role bypasses tenant isolation. A workflow that "just needed it to work" can write one tenant's data into another's rows with no policy to stop it and no error to reveal it.
When is connecting Supabase the wrong call?
When the workflow would require the service role to function. That requirement is a design signal to revisit the policy model, not a configuration step to accept.
What should a Supabase integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Supabase to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Can the workflow act on Supabase, not just read it?
Action paths are possible but should be treated as a separate, bounded project with scoped credentials, explicit approval, and a record of what ran.
How are credentials handled?
Through workspace-approved, scoped grants. A shared secret pasted into a prompt or embedded in generated code is not an acceptable pattern.
What is a safe first integration?
A read-only workflow that produces something the team already wants from Supabase — delivery visibility or incident context — before any action path is considered.
How this access is governed
What ARIA is allowed to do in Supabase, and who decides.
Connecting Supabase is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.