Supabase.
An open-source back end built on Postgres, with sign-in, file storage and live updates included.
Talk to us about Supabase
Key features
What Supabase does well.
Generated APIs
Tables and views get a REST and GraphQL API automatically, with row level security applied to every request.
Postgres extensions
Projects can enable extensions such as pgvector for embeddings, PostGIS for maps and pg_cron for scheduled jobs.
Edge Functions
Server-side TypeScript runs on Deno, for webhooks, payments and logic that shouldn’t live in the client.
Preview branches
Each pull request can get its own preview database, with migrations and Edge Functions deployed to it.
What we build with it
A Postgres database with the back end already attached.
Supabase puts authentication, file storage, real-time subscriptions and edge functions around a full Postgres database. Access rules live in the database as row level security policies, so one rule covers every request, whether it comes from the app, a script or a report. The platform is open source, which keeps self-hosting open as an option.
Apps with accounts and roles
Email, magic-link and social sign-in, with database policies deciding who can see each row.
Live collaboration
Realtime channels that push database changes to every connected screen.
Search over your own records
The pgvector extension stores embeddings next to the records they describe, for AI search without a second database.
When it’s the right choice
Supabase suits products that want relational data and SQL from the first day, but would rather not build sign-in and file storage themselves.
When we’d pick something else
Row level security needs careful testing, because one wrong policy can expose data. When the back-end logic gets complex, we put a separate API in front instead of having the app call the database directly.
Our Supabase services
How we can help.
New Supabase builds
Schema design, row level security policies, auth and storage set up for a new web or mobile product.
RLS policy review
Testing every policy against each role to find rows that leak or requests that fail without a clear reason.
Migration to Supabase
Moving from Firebase or an older Postgres setup, including users, files and existing access rules.
Self-hosting setup
Running Supabase in your own cloud account where data residency requires it, with backups and monitoring.
How we work
Starting a Supabase project.
Review what exists
Code, data, hosting and the people who maintain it, before any Supabase decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
Where AI fits
AI in back-end work.
Model calls from your services
Node.js, Go and Python all have official SDKs from the major model providers, so AI steps sit inside your existing services.
AI workflow automation ↗Evaluation pipelines
Python’s data tooling makes it the usual choice for scoring a model against real examples before and after release.
AI evaluation & testing ↗
Where it stops: Retries, timeouts and fallbacks matter more for model calls than for most APIs, and every result that changes a record is validated first.
Where it fits
Related expertise.
- Web application development Browser-based tools for customers and staff, built for the data, roles and permissions behind them.
- Mobile app development iOS and Android apps that work offline, handle device permissions well and ship through the app stores.
- Knowledge assistants Answer questions from your approved documents, with sources shown and access rules respected.
Common questions
Supabase questions.
Is Supabase just Postgres?
Underneath, yes. Your data sits in a standard Postgres database that you can query, back up and connect to with ordinary tools, so you are not locked in.
Can Supabase be self-hosted?
Yes. It is open source and runs with Docker. Managed hosting is less work for most teams; self-hosting is worth it when data residency or cost demands it.
Further reading
- A database for every pull request: preview environments that work How to give each pull request its own database branch, with safe data, tested migrations and automatic clean-up.
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- Answers staff can trust: an assistant built on approved documents How to build a document assistant that cites its sources, respects permissions and says when it does not know.