Why We Use Supabase as Our Default Backend (and When We Do Not)
Every new project starts with the same question: what backend? For the past year, our default answer has been Supabase — and it has saved our clients hundreds of hours and thousands of dollars. But it is not always the right answer. Here is our decision framework.
What Supabase gives you for free
Supabase is an open-source Firebase alternative built on PostgreSQL. Out of the box you get: authentication (email, OAuth, magic links, phone), a full PostgreSQL database with a REST and GraphQL API auto-generated from your schema, real-time subscriptions via WebSockets, file storage with CDN, edge functions for serverless logic, and Row Level Security for fine-grained access control.
For a typical MVP, this covers 80-90% of your backend needs without writing a single line of server code. Your frontend talks directly to Supabase via their client SDKs (available for JavaScript, Flutter, Swift, Kotlin, and Python). Authentication, CRUD operations, file uploads, and real-time updates all work immediately.
The PostgreSQL foundation is the key differentiator from Firebase. You get proper relational data modeling, complex queries with JOINs, full-text search, JSON columns, and the entire PostgreSQL extension ecosystem (PostGIS for geospatial, pgvector for AI embeddings, pg_cron for scheduled jobs). When your app grows, you are not trapped in a proprietary database.
Real cost savings: a case study
For FinFlow (our personal finance app case study), using Supabase saved approximately 3 weeks of development time compared to building a custom Node.js backend. Auth would have taken 3-4 days. REST API scaffolding another 2-3 days. Real-time subscriptions 2-3 days. File storage and CDN configuration 1-2 days. Row Level Security would have required building a custom middleware layer.
On the hosting side, Supabase free tier covers most MVPs comfortably (500MB database, 1GB storage, 50,000 monthly active users). The Pro plan at $25/month handles production apps up to significant scale. Compare that to running your own PostgreSQL instance, authentication service, file storage, and WebSocket server — you are looking at $100-300/month minimum in infrastructure costs alone.
Row Level Security: the feature most teams underuse
Row Level Security (RLS) is Supabase killer feature and the one most teams either ignore or implement incorrectly. RLS lets you define access policies at the database level — users can only read or write rows that match their identity. This means your API cannot accidentally leak data even if your frontend code has a bug.
We enforce a strict rule on every Supabase project: RLS must be enabled on every table from day one, with explicit policies for every operation. No exceptions. This adds 15-20 minutes of setup per table but eliminates an entire class of security vulnerabilities. We have seen competitor apps ship with RLS disabled — meaning any authenticated user could read any other user data. Do not make this mistake.
When Supabase is not the right choice
Supabase is not a universal solution. We reach for custom backends in these scenarios: complex business logic that does not fit neatly into database policies (multi-step workflows, saga patterns), apps that need to integrate with multiple external APIs in orchestrated sequences, systems requiring event sourcing or CQRS patterns, and apps with heavy background processing (video transcoding, batch ML inference).
For these cases, we typically build a Node.js API with Prisma ORM, still using PostgreSQL as the database. The data layer stays the same — we just add a proper application layer on top. Sometimes we use a hybrid approach: Supabase for auth and real-time, with a custom API for complex business logic.
Our Supabase project template
We have built an internal Supabase project template that we use for every new project. It includes: a standard auth configuration with email and Google OAuth, a base migration with common tables (profiles, settings, audit_log), RLS policies for all tables, edge functions for Stripe webhook handling and email sending, and a seed script for development data.
This template lets us go from zero to a working authenticated app with proper security in about 30 minutes. If you are evaluating Supabase for your next project and want to see what a production-grade setup looks like, reach out — we are happy to walk you through our approach.