Integration
Supabase Integration
Authentication, row level security, storage and realtime over managed PostgreSQL, with policies as the authorisation layer rather than checks scattered through code.
- Multi tenant applications where isolation must survive an application bug
- Progressive web apps needing authentication and offline capable data access
- Client portals where each customer sees only their own records
- Products with realtime presence or live updating views
- Applications that store user uploaded files with per user access
Overview
What this integration involves
Supabase is managed PostgreSQL with a set of services built around it: authentication, an auto generated data API, object storage, realtime subscriptions and edge functions.
The part that changes how an application is built is row level security. Authorisation lives in the database as policies, which means it applies to every client, every function and every query rather than being reimplemented at each endpoint.
That is also the part most often got wrong. A table with row level security enabled and no policy returns nothing. A table without it enabled returns everything to anyone holding the anonymous key.
Surface
Capabilities we use
Authentication
Email and password, magic links, one time codes and provider login, with session handling, refresh tokens, email verification and password reset. The authenticated user identifier is available inside the database, which is what makes policies possible.
Row level security
Policies per table and per operation, expressed in SQL, evaluated for every request. A policy can reference the current user, a membership table, or any expression the database can evaluate.
Data API
A REST interface generated from the schema, with filtering, ordering, pagination and embedded relations. Every request runs as the authenticated user, so policies apply.
Storage
Object storage in buckets with their own policies, signed URLs for time limited access, image transformation, and resumable upload for large files.
Realtime
Subscriptions to database changes, broadcast channels for ephemeral messages, and presence for showing who is connected. Change subscriptions respect row level security.
Edge functions
Server side functions for work that must not run in the browser: calling a third party with a secret, verifying a webhook, or performing a multi step operation as a trusted actor.
Data flow
Step by step
- 01
Authenticate
The client signs in and receives a short lived access token and a refresh token. The access token is a signed JWT carrying the user identifier and role.
- 02
Attach the token to every request
The client library sends the access token with each request. The database receives it and exposes the user identifier to policy expressions.
- 03
Evaluate policies
For each row the query would touch, the relevant policy is evaluated. Rows that fail are invisible rather than producing an error, which is the correct behaviour for a read and needs explicit handling for a write.
- 04
Return or reject
Reads return the permitted subset. Writes that violate a policy are rejected. No filtering happens in the client.
- 05
Serve files through signed URLs
Storage objects are private. The application requests a signed URL with a short expiry, and the browser fetches directly from storage without the file passing through your server.
- 06
Do privileged work in functions
Operations that must bypass user scope, such as an administrative action or a webhook handler, run in an edge function or a server route with the service role key, which never reaches the browser.
Architecture
How the pieces connect
- 01Client apptoAuth service
sign in
- 02Client apptoData API
query with token
- 03Data APItoPostgreSQL
policy checked
- 04Client apptoStorage
signed URL
- 05Client apptoEdge function
privileged action
- 06Edge functiontoPostgreSQL
bypasses policy
Events
Webhooks we handle
- Database webhooks on insert, update and delete for downstream integration
- Auth hooks on sign up and sign in for provisioning and audit
- Storage events for post upload processing such as thumbnail or text extraction
- Third party webhooks received in edge functions with signature verification
Reliability
What makes it hold
Connection pooling from serverless runtimes
A serverless function can create connections faster than PostgreSQL will accept them. Server side access goes through the pooled connection string rather than the direct one, and the direct connection is reserved for migrations.
Policies tested as code
Tests attempt cross tenant access with a real user token and assert that nothing is returned. Reading the policy and believing it is not the same as proving it.
Migrations in version control
Schema and policy changes are versioned files applied by the pipeline. Changes made in the dashboard drift between environments and are invisible in review.
Realtime as a signal, not a source
A change subscription tells the client something happened. The client then reads through the normal path, so a missed message is a stale view rather than a lost record.
Token refresh handled explicitly
Access tokens are short lived. The client refreshes ahead of expiry and handles a failed refresh by returning the user to sign in rather than looping on rejected requests.
Security
How it is secured
- Row level security enabled on every table holding user data, with an explicit policy per operation.
- The service role key is used only in server code and never shipped to the browser.
- Storage buckets are private by default and served through short lived signed URLs.
- Policies reference membership tables rather than values the client can supply.
- Sensitive columns are separated into tables with their own policies where only some fields are restricted.
- Auth redirect URLs are restricted to known hosts to prevent token interception.
Evidence
Where we have built this
- White-Label Fitness & Revenue-Sharing PlatformA multi tenant fitness SaaS for influencers using Next.js 14, Supabase, Prisma, subdomain routing, Stripe Connect revenue splits, and AI-generated 12 week training programs.
- AI Fitness Coaching ApplicationAn AI coaching PWA with Supabase authentication and data, Groq inference using Llama 3.3 70B, and private network deployment.
FAQ
Questions people actually ask
Is row level security enough on its own?
It is the strongest layer, and it should not be the only one. Server routes still validate input and enforce business rules. Policies stop data leaking. They do not stop a user doing something they are permitted to do at the wrong time.
What happens if we forget a policy?
With row level security enabled and no policy, the table returns nothing. That is the safe failure. The dangerous case is a table where row level security was never enabled, which is checked in review and in tests.
Can we migrate off Supabase later?
The database is standard PostgreSQL, so the schema and data move. Authentication and storage would need replacing, which is why applications are structured with those behind their own boundary.
Do we call the database directly from the browser?
For reads and simple writes covered by policy, yes, and it removes a layer of pass through code. Anything involving a secret, a third party, or a multi step invariant runs on the server.
How do you handle admin access?
Through server code using the service role key, with an audit record of the actor and the action. Never by relaxing a policy.
Does realtime scale?
It depends on subscription count and change volume. Broad subscriptions on high write tables are the failure mode, so subscriptions are scoped narrowly and used as a refresh signal rather than a data channel.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.