Supabase Review (2026): Honest Assessment from BearPlex Engineers
Supabase is our default backend for product builds where a small team needs Postgres, auth, storage, realtime, and serverless functions on day one, and we trust it enough to run our own SaaS (PeoplePlus) on it. The database underneath is standard Postgres, which means row-level security is a real security boundary and the exit path is a pg_dump away, not a rewrite. The honest caveat is operational: native backups and PITR cover the database only (Storage buckets are excluded), the free tier has no automatic backups at all, and PITR is a paid add-on, so production readiness means an external backup pipeline and a rehearsed restore. We run Supabase as a dedicated practice; the receipts and the full playbook live on our Supabase development service page.
Based on
6+ production projects
Supabase is our default backend for product builds where a small team needs Postgres, auth, storage, realtime, and serverless functions on day one, and we trust it enough to run our own SaaS (PeoplePlus) on it. The database underneath is standard Postgres, which means row-level security is a real security boundary and the exit path is a pg_dump away, not a rewrite. The honest caveat is operational: native backups and PITR cover the database only (Storage buckets are excluded), the free tier has no automatic backups at all, and PITR is a paid add-on, so production readiness means an external backup pipeline and a rehearsed restore. We run Supabase as a dedicated practice; the receipts and the full playbook live on our Supabase development service page.
What is Supabase?
Supabase is an open-source backend platform built on PostgreSQL. Each project is a real Postgres database wrapped with the platform services a product team needs: authentication (email, magic links, SSO, OAuth) issuing JWTs that Postgres row-level security policies can read, auto-generated REST and GraphQL APIs over the schema, Realtime (Postgres changes streamed over websockets), Storage (S3-backed object storage with policy-based access), and Edge Functions (Deno-based serverless functions). The hosted platform runs the whole stack as a managed service; the core is open source and can be self-hosted. Because the database is standard Postgres, the full extension ecosystem applies, including pgvector for semantic search. Supabase has become the default 'Firebase alternative' for teams whose data is relational, which in our client work is nearly all of them.
| License | Apache 2.0 core (open source); hosted platform is the commercial product |
| Database | Standard PostgreSQL with the full extension ecosystem (pgvector, PostGIS, etc.) |
| Platform services | Auth (JWT), auto-generated APIs, Realtime, Storage, Edge Functions (Deno) |
| Security model | Row-level security policies against JWT claims: the boundary lives in the database |
| Backups | Native backups and PITR cover the DATABASE ONLY; Storage buckets are excluded (as of mid-2026) |
| Best for | Relational SaaS products, multi-tenant platforms, small teams shipping fast |
| Worst for | VPC-only data residency, offline-first mobile sync, non-relational workloads at scale |
| Portability | High: pg_dump / logical replication moves the data; Auth, Storage, and functions need a planned migration |
| Active alternatives | Firebase, plain Postgres (RDS / Cloud SQL) + custom backend, Neon + custom auth |
Hands-on findings from 6+ production projects
We've shipped 6 production Supabase systems that are published on this site, including our own SaaS: PeoplePlus (multi-tenant HR platform, complete per-organisation isolation via RLS, four role levels, magic links and SSO, public careers API on edge functions), CleverCoach (React + Supabase tutoring platform, RLS on all 13+ tables, three JWT roles, real-time subscriptions, five storage buckets), Letti AI (Supabase + Postgres + pgvector with 3072-dimensional embeddings), Yaay365 (Node backend on Supabase with 30+ payment webhook handlers and Supabase Storage), the Ticketmaster scraping system (six-table schema, real-time upserts with deduplication), and bearplex.com's own careers system (PeoplePlus ATS served through a Supabase edge function with Cloudflare Turnstile verified server-side). The patterns that emerged: (1) RLS is the whole game. Designed first, with a tenancy key on every table and policies written per role against JWT claims, it is a genuine security boundary; bolted on later, it is a minefield of policy gaps and tables with no protection at all. We prove policies with per-role integration tests that attempt cross-tenant access and must fail. (2) The operational sharp edges are documented but rarely read: native backups and PITR cover the Postgres database only, Storage objects are excluded, the free tier has zero automatic backups, and PITR is a paid add-on running roughly $100 to $400 per month by retention window as of mid-2026. Every production project we run gets an external pipeline: scheduled dumps plus Storage sync to a client-owned S3 bucket, and a restore rehearsal on a calendar. (3) Edge functions are genuinely production-grade for webhooks and public APIs; our own careers API runs on them in production with bot protection. (4) Realtime needs deliberate channel design; subscribing everything to everything is how it falls over. (5) Portability is real: it is standard Postgres, so choosing Supabase is not a one-way door, which is exactly why we recommend it. Full practice details at bearplex.com/services/supabase-development.
Pros
- It is real Postgres: SQL, joins, extensions (pgvector included), and full data portability
- RLS against JWT claims makes the database itself the security boundary for multi-tenant SaaS
- Auth, APIs, Realtime, Storage, and Edge Functions on day one saves months of undifferentiated backend work
- Edge functions are production-grade for webhooks and public APIs (we run one on this site's careers system)
- Realtime subscriptions work well when the channel model is designed deliberately
- Open-source core means no proprietary data model shaping your schema
- Excellent local development story (CLI, migrations, local stack)
- Low exit cost keeps the architecture honest: pg_dump plus a planned Auth/Storage migration
Cons
- Native backups and PITR cover the database only: Storage buckets are excluded (officially documented)
- Free tier has zero automatic backups; teams discover this after the incident
- PITR is a paid add-on, roughly $100 to $400 per month by retention window as of mid-2026
- RLS added late to a project is painful to retrofit and easy to get subtly wrong
- No built-in offline-first sync engine (Firestore is stronger for offline mobile)
- Managed platform only fits when data may leave your network; self-hosting shifts real ops burden onto you
- Scales as far as one Postgres deployment scales: horizontal sharding across regions is not the platform's story
Supabase compared to alternatives
| Alternative | Score | Best for | Worst for |
|---|---|---|---|
| Firebase (Firestore) | 3.5/5 | Mobile-first apps needing offline sync and the Google ecosystem | Relational data, SQL reporting, and portability |
| Plain Postgres (RDS / Cloud SQL) + custom backend | 4/5 | VPC-only requirements and teams with an existing platform team | Small teams that need auth, APIs, and storage on day one |
| Neon + custom auth/storage | 3.5/5 | Serverless Postgres with branching for dev workflows | Teams wanting the integrated auth/storage/realtime layer |
| Self-hosted Supabase | 3/5 | Hard data-residency requirements with real ops capacity | Teams hoping to keep the managed platform's low ops burden |
Pricing analysis
The free tier is genuinely useful for development but has no automatic backups and pauses inactive projects: never production. The Pro plan starts at $25/month per project plus compute sized to the workload, and includes daily database backups with days-level retention. Point-in-time recovery is an add-on priced by retention window, roughly $100 to $400 per month as of mid-2026, and covers the database only. Storage and egress bill by usage. For a typical mid-market SaaS the platform bill is a rounding error next to the engineering it replaces; the line item teams forget is the external backup pipeline (S3 storage plus a scheduled job), which costs almost nothing and is the difference between an incident and a disaster. Compared to running Postgres, an auth service, an object store, and a websocket layer yourself, Supabase's TCO wins for small teams and stays competitive until you have a platform team who would run those anyway.
When to use
- Relational SaaS products where a small team needs the full backend on day one
- Multi-tenant platforms where RLS-based isolation is designed in from the start
- Products adding semantic search: pgvector on Supabase keeps vectors next to the data
- Webhook-heavy integrations and public APIs on edge functions
- Teams that want low exit cost as an explicit architectural property
When NOT to use
- Data-residency requirements that keep everything inside your own VPC: use plain Postgres in your network
- Mobile-first products that live or die on offline sync: Firestore is stronger there
- Non-relational workloads at scale (event streams, telemetry, graphs): pick the right store
- Organisations already operating Postgres with a real platform team: the convenience layer buys less
- Roadmaps that credibly require horizontal sharding across regions within the year
Supabase: questions answered
No. As of mid-2026, native backups and point-in-time recovery cover the Postgres database only, and Supabase documents this. The free tier has no automatic backups at all. For every production project we set up scheduled database dumps plus a sync of all Storage buckets to a client-owned S3 bucket, and we rehearse the restore.
For most B2B and SaaS products, Supabase: real Postgres with SQL, joins, RLS, and portability beats a proprietary document store shaped by its query limits. Firebase wins for mobile-first apps that depend on its offline sync and for teams deep in the Google ecosystem.
Less than with almost any comparable platform. The database is standard Postgres, so pg_dump or logical replication moves the data to RDS, Cloud SQL, or self-hosted Postgres. The planned work in a migration off is Auth (user export, password hashes, JWT reissue), Storage objects, realtime consumers, and edge functions. We have scoped that path; it is work, not a trap.
A tenancy key on every table, policies written per role against JWT claims, no table left unprotected, and per-role integration tests that attempt cross-tenant reads and writes and must fail. PeoplePlus isolates every organisation this way with four permission levels; CleverCoach runs three JWT roles over 13+ RLS-protected tables.
Yes. This site's own careers system serves job listings and applications through a Supabase edge function with Cloudflare Turnstile verified server-side, and PeoplePlus's public careers API runs the same way. Treat them like any production service: versioning, secrets management, and observability.
Yes, pgvector is natively supported and it is a pattern we ship: Letti AI runs semantic job matching on Supabase Postgres with 3072-dimensional embeddings. For workloads under roughly 5-10M vectors, keeping vectors next to the relational data usually beats operating a separate vector database.
Yes. A takeover starts with an audit of RLS coverage, auth flows, query performance, and backup posture, then a fixed-scope hardening plan. Details at bearplex.com/services/supabase-development.
Related reviews
Related services
Featured case studies
Research basis
- Supabase database backup documentation · Official statement that backups (and PITR) cover the database and do not include Storage objects.
- Supabase pricing · Plan tiers, backup retention by plan, and the PITR add-on priced by retention window.
- BearPlex Supabase development service · Our full Supabase practice: builds, rescues, multi-tenant RLS, migrations, and the backup/DR setup described in this review.
Last researched: 2026-07-02
Disclosure: BearPlex is not affiliated with Supabase Inc. We have shipped 6 production Supabase systems that are published on this site, including our own SaaS. We do not receive any compensation, referral fees, or partnership benefits from Supabase Inc. Reviewed by Hamad Pervaiz, Founder & CEO, BearPlex.
Need help implementing Supabase at scale?
BearPlex builds production AI systems with Supabase and its alternatives. Outcome-based pricing.