Supabase
Good enough to bet a product on, with one condition
We run Supabase in four client systems: Shift Link, Trading CoPilot, ExtraaJe and Lexpair. This is what maintaining them has taught us.
The short answer
Supabase is the right default for a product needing Postgres, auth and realtime on day one, provided your team writes SQL and treats row-level security as tested application code rather than a setting.
Choose differently in two situations. If your workload is long-running or CPU-heavy, the serverless functions will not hold it and you need a worker elsewhere. If nobody on the team is comfortable reasoning about SQL access rules, the feature that makes Supabase safe becomes the thing that leaks your data.
What decides this
4 things that decide this
- 01It is ordinary Postgres underneath, so your exit is a database dump rather than a rewrite.
- 02Row-level security is the best thing about it and the sharpest edge. Written well it removes a whole class of data leak. Written carelessly it fails quietly.
- 03Edge Functions cap CPU time at 2 seconds per request and memory at 256MB, so anything heavy belongs on a worker you run yourself.
- 04Realtime on the Pro plan starts at 500 concurrent connections and 500 messages per second, which is a design constraint rather than a footnote.
A hosted Postgres with the usual backend parts attached
Supabase gives you a Postgres database with authentication, file storage, realtime subscriptions and serverless functions already wired together. The pitch is that you skip assembling those pieces yourself at the start of a build.
The detail that matters commercially is what sits underneath. There is no proprietary query layer, so your schema, your extensions and your migration tooling are all standard. That makes the platform a convenience rather than a dependency. It is a rare property in this category, and the main reason we reach for it.
Where it holds up and where it does not
Strengths
- Access rules live in the database, so a bug in one API route cannot leak another tenant's rows. Trading CoPilot and Shift Link both depend on this.
- Auth, storage and realtime arrive already connected, which removes weeks of assembly at the start of a build.
- It is Postgres, so ordinary SQL, extensions and migration tooling all work, and the people you hire already know it.
- Row-level security is enabled by default on tables created in the dashboard table editor, so the safe state is the starting state.
Trade-offs
- Access policies are hard to review and easy to get subtly wrong. Supabase itself warns that a policy reading user metadata is unsafe, because an authenticated user can modify that data.
- Written naively, those policies get slow. Supabase documents wrapping the auth call in a subquery, and its own benchmark moves one policy from 179ms to 9ms and another from 11 seconds to 10ms.
- Edge Functions cap CPU time at 2 seconds and memory at 256MB per request. Anything long-running or compute-heavy needs a separate worker, which we run on EC2.
- The service key bypasses access rules entirely. It is a single credential that undoes the whole model if it reaches a browser.
Limits worth knowing before you architect around them
Taken from Supabase's own documentation on 12 August 2026. These are the figures that change a design decision rather than a billing line.
| Limit | Free | Pro | Why it matters |
|---|---|---|---|
| Edge Function wall clock | 150s | 400s | A request with no response by the idle timeout returns a 504 |
| Edge Function CPU time | 2s | 2s | Does not rise with the plan. Heavy compute needs a worker |
| Edge Function memory | 256MB | 256MB | Rules out loading large files into memory |
| Realtime concurrent connections | 200 | 500 | Raises to 10,000 once the spend cap is removed |
| Realtime messages per second | 100 | 500 | A chatty client design hits this before user numbers look large |
| Direct database connections | 60 | 90 (Small) | Pooler clients run far higher, at 200 and 400 |
- Policy writtenReads user metadata a user can edit
- No testNothing proves the rule denies
- Service keyOne leak bypasses everything
- Unindexed columnPolicy scans every row
- Silent passData leaks with no error
Every failure we have hit on this platform was ours, not the vendor's. The pattern is the same each time: an access rule that nothing tested, so the failure surfaced as data appearing where it should not rather than as an error somebody could see.
What we use it for, and what each one taught us
Shift Link runs UK workforce compliance on Supabase auth, realtime and storage. Employers there must never see each other's staff records, so the tenant boundary sits in the database rather than in the API layer. Trading CoPilot stores encrypted broker API keys with per-user isolation enforced the same way.
ExtraaJe uses it for auth and business logic across a European workforce, and Lexpair for its legal matching data. In all four, the decision that mattered was the same. Access rules get written as code, reviewed in a pull request, and covered by tests that assert a denial as well as an allow. A test proving somebody can read their own row proves nothing about whether they can read yours.
- 01Index the columns your policies filter on. Supabase reports over 100x improvement on large tables from that change alone.
- 02Write the auth call as a subquery so it evaluates once rather than per row.
- 03An update policy also needs a matching select policy, or the update silently does nothing.
Systems running on this stack
Shift Link
AI workforce compliance and shift management for healthcare and logistics.
Read the case study →
Trading CoPilot
Real-time AI trading alerts and execution companion for forex traders.
Read the case study →
ExtraaJe
Gamified employee rewards platform for a European workforce.
Read the case study →
What teams ask before committing
01Supabase or Firebase?
Pick Supabase if your data is relational and you want to keep SQL. Pick Firebase if your data is document-shaped and you already live inside Google's tooling. The deciding question is whether you will ever need a join. Retrofitting relational thinking onto a document store is the expensive direction to be wrong in.
02Is Supabase production ready?
Yes, with the caveat that you own your access-control design. We have run it in four client products without an outage caused by the platform. Every failure we have seen came from our own policies. Tests written against those policies are what now catch the bug before release.
03Can we move off it later?
Yes, and this is the strongest argument for choosing it. The database is standard Postgres, so migrating is a dump and restore plus replacing the auth and storage calls. That is real work and it is not a rewrite, which is not true of platforms with a proprietary query layer.
04What breaks first as we grow?
Realtime connection design, usually before anything else. The Pro plan allows 500 concurrent connections and 500 messages per second. A client that opens a channel per component reaches that with a modest number of real users. Past a few thousand subscribers, channel design has to be deliberate rather than default.
05Do we still need a backend?
For most products, yes, though a smaller one. Supabase covers auth, storage, realtime and the database well. What remains is the work that will not fit a 2-second CPU budget. Scheduled jobs, document processing, and third-party integrations with retries all fall there. We run those on a small service alongside instead of forcing them into Edge Functions.
