Supabase vs Firebase vs custom backend: which one for your startup

Supabase gives you a PostgreSQL database, auth, real-time subscriptions, and file storage for free until you hit 500MB. Firebase scales to millions of users with Google's infrastructure behind it but locks you into a proprietary NoSQL model. A custom backend costs $3,000-$8,000 upfront but gives you full control over your data architecture, hosting, and vendor relationships.

The short answer: Supabase for most startups building SaaS products with relational data. Firebase for mobile-first apps that need push notifications, offline sync, and deep Google Cloud integration. Custom backend when you have compliance requirements, multi-tenant data isolation needs, or business logic too complex for edge functions and database triggers.

Pricing and free tier limits reflect March 2026 published rates. Both Supabase and Firebase update pricing periodically; check their pricing pages for current numbers.

Supabase: PostgreSQL with batteries included

Supabase is an open-source Firebase alternative built on PostgreSQL. That distinction matters more than the marketing suggests. PostgreSQL is the most popular database for SaaS applications (used by 49% of professional developers, Stack Overflow 2025 survey). It supports relational queries, JSON columns, full-text search, and row-level security. You get a proper database with an API layer on top, not a document store pretending to be one.

The developer experience is strong. Create a table in the dashboard, and Supabase auto-generates a REST API and a TypeScript client library. Row-level security (RLS) policies run inside PostgreSQL, so your access control logic lives at the database level, not in application code. Auth handles email, OAuth, magic links, and phone verification out of the box.

Where Supabase wins

• Relational data. If your data has relationships (users have orders, orders have items, items belong to categories), PostgreSQL handles this natively. Firestore forces you to denormalize data and duplicate it across collections, which leads to consistency bugs at scale.
• SQL access. You can write raw SQL queries, use PostgreSQL extensions (pg_trgm for fuzzy search, PostGIS for geospatial), and run complex analytics without a separate data warehouse. Firebase's query language is limited to simple equality filters and range queries on indexed fields.
• Open source. Supabase is MIT-licensed. If the managed service shuts down or pricing changes drastically, you can self-host the entire stack on your own infrastructure. Firebase has no self-hosted option. Your data lives in Google's ecosystem on Google's terms.
• Row-level security. RLS policies enforce access control at the database level. Even if your application code has a bug that bypasses auth checks, the database rejects unauthorized queries. Firebase security rules provide similar protection, but RLS is more expressive for complex authorization logic.

Hidden costs and limitations

Supabase's free tier caps at 500 concurrent connections on the pooled connection mode. A Next.js app on Vercel spins up a new serverless function for every request, and each function opens a database connection. With 50 concurrent users, you can hit connection limits during traffic spikes. The fix: PgBouncer connection pooling (included in the Pro plan) or switching to Supabase's new "Supavisor" pooler.

Edge Functions run on Deno, not Node.js. If your team writes Node.js and relies on npm packages, some libraries won't work in Deno without modification. The Edge Functions execution limit is 150 seconds on the free tier and 540 seconds on Pro. Long-running background jobs (PDF generation, video processing, data migrations) need a separate compute layer.

Real-time performance has limits too. Supabase real-time broadcasts PostgreSQL changes over WebSocket, but it's not designed for high-frequency updates (1,000+ changes per second). For collaborative editing or live trading dashboards, you'll need a dedicated real-time service like Ably or Liveblocks alongside Supabase.

Firebase: Google's full-stack platform

Firebase launched in 2012 and powers over 3 million active apps globally (Google I/O 2025). It's the most battle-tested Backend-as-a-Service on the market. Firestore handles billions of reads per day across Google's global infrastructure. Cloud Functions scale to zero and spin up in milliseconds. Firebase Auth manages authentication for apps serving hundreds of millions of users.

The ecosystem is deep. Firebase Crashlytics catches app crashes. Firebase Analytics tracks user behavior. Cloud Messaging sends push notifications. Remote Config lets you toggle features without deploying. If you're building a mobile app and need all of these services, Firebase bundles them into a single SDK.

Where Firebase wins

• Mobile-first apps. Firebase's SDKs for iOS, Android, and Flutter are mature. Offline persistence works automatically; the app caches data locally and syncs when connectivity returns. Supabase's mobile SDKs are functional but less polished.
• Global scale without ops. Firestore runs on Google's infrastructure across 30+ regions. You don't manage replication, sharding, or failover. For apps that need to serve users on every continent with sub-100ms reads, Firebase handles this without a DevOps team.
• Push notifications. Firebase Cloud Messaging (FCM) is the industry standard for mobile push notifications. Supabase doesn't have a push notification service. If your app sends push notifications, you'll integrate FCM regardless of your backend choice.
• Mature ecosystem. 10+ years of production usage means extensive documentation, thousands of Stack Overflow answers, and community solutions for most problems. When you hit a Firebase issue at 2 AM, someone has solved it before.

Hidden costs and limitations

Firebase's pricing model penalizes read-heavy applications. Firestore charges $0.06 per 100,000 document reads on the Blaze plan. A dashboard that loads 100 documents per page view uses 100,000 reads per 1,000 page views. At 10,000 daily active users loading 5 pages each, you're burning 5 million reads per day, or $3/day ($90/month) on reads alone. Add writes, storage, and egress, and a moderately active SaaS app runs $200-800/month.

Egress costs are the other surprise. Firebase charges $0.12/GB for data transferred out of Google's network. A SaaS app serving 500KB of data per page load to 50,000 monthly users transfers 25GB of egress, costing $3/month. That sounds small, but add image serving, API responses, and file downloads, and egress costs scale to $50-200/month for active apps.

The vendor lock-in problem is structural. Firestore's document model doesn't map to SQL databases. Security rules use Firebase's proprietary language. Cloud Functions run in Google Cloud's environment. Migrating off Firebase means rewriting your data layer, auth system, and serverless functions. A Savi client spent 6 weeks migrating from Firebase to a custom PostgreSQL backend because Firestore's query limitations couldn't handle their reporting requirements.

Custom backend: full control, higher upfront cost

A custom backend means building your API layer, auth system, and data access patterns from scratch (or assembling them from well-tested libraries). The upfront cost is $3,000-$8,000 for a standard setup: Node.js/TypeScript API, PostgreSQL database, auth (Clerk or custom JWT), file storage (S3 or R2), and deployment to a managed platform like Railway or Vercel.

The ongoing cost is lower than BaaS platforms at scale. A custom backend on Railway costs $5-20/month for compute and $0-25/month for a managed PostgreSQL database. No per-read charges. No egress fees (on most platforms). No connection limits controlled by a third party. At 50,000 monthly active users, a custom backend costs $50-100/month in infrastructure. The same app on Supabase's Pro plan costs $25/month plus usage overages. On Firebase's Blaze plan, it costs $200-800/month.

When to build custom

• Multi-tenant SaaS. Supabase and Firebase don't natively support multi-tenant data isolation (separate schemas, row-level tenant scoping, per-tenant connection pooling). A custom backend lets you design the tenancy model that fits your product. DropTaxi needed tenant-scoped database queries on every request; a custom Turso setup with per-tenant SQLite databases made this clean and fast.
• Complex business logic. If your API has 20+ endpoints with business rules that span multiple database tables, conditional workflows, and external service calls, edge functions and database triggers become unmanageable. A proper API layer with typed routes, middleware, and service classes is easier to test, debug, and extend.
• Regulatory compliance. HIPAA, SOC 2, and PCI-DSS requirements often mandate specific infrastructure controls: encryption at rest with customer-managed keys, audit logging on every data access, and geographic data residency. BaaS platforms provide some compliance features, but you lose fine-grained control over the infrastructure.
• High-throughput event processing. If your app processes 10,000+ events per second (IoT data ingestion, real-time analytics, trading systems), BaaS platforms hit rate limits. A custom backend with Redis Streams, Kafka, or a dedicated event bus handles this workload at a fraction of the BaaS cost.

Security comparison

Supabase's row-level security (RLS) is enabled by default on new tables. You write PostgreSQL policies that check the user's JWT claims against the row's data. If the policy fails, the database returns no rows. This is the most secure default of the three options because the enforcement happens at the database level, below your application code.

Firebase security rules are powerful but notoriously error-prone. A 2024 study by Comparitech found that 4.8% of Firebase databases had misconfigured security rules that exposed user data. The rules syntax is its own language, separate from your application code, and testing requires the Firebase emulator suite. Small mistakes (forgetting to add an auth check on a subcollection) create data leaks that are hard to catch in code review.

Custom backends put security entirely in your hands. That's both the advantage and the risk. You control auth middleware, input validation, rate limiting, and access control. But every security decision is yours to make and yours to get wrong. Most custom backends use middleware-based auth (verify JWT on every request) and ORM-level query scoping (every database query includes a WHERE tenant_id = ? clause).

Migration difficulty

Leaving Supabase is straightforward. Your data lives in PostgreSQL. Export it with pg_dump. Import it into any other PostgreSQL host (Neon, Railway, AWS RDS). RLS policies port directly. Auth users can be migrated using Supabase's export tools. Total migration time: 1-2 weeks for most apps.

Leaving Firebase is painful. Firestore's document collections need to be restructured into relational tables. Security rules need rewriting as application-level middleware or RLS policies. Cloud Functions need porting from the Firebase SDK to a generic Node.js server. Firebase Auth users can be exported, but their password hashes use Firebase's proprietary algorithm, which complicates migration. Total migration time: 4-8 weeks for a moderately complex app.

Leaving a custom backend is the easiest; you already own every line of code and every infrastructure decision. Migrating between hosting providers (Railway to AWS, Vercel to Cloudflare) takes 1-3 days for most setups.

Real projects from Savi's portfolio

We've shipped products on all three approaches. Here's what drove each decision.

FotoLabs: Firebase for rapid mobile MVP

FotoLabs needed a photo management platform with user auth, image uploads, and real-time processing status updates. Firebase was the right choice because the app required push notifications (FCM), file storage with automatic image processing, and a launch timeline of 3 weeks. Firebase's pre-built SDKs for auth and storage cut the setup time from days to hours. The tradeoff: the team accepted the vendor lock-in because speed to market was the priority.

ZestAMC: Supabase for a data-heavy investment platform

ZestAMC manages $10M+ in crypto assets across 200K+ users with 5 role-based portals. The data model is heavily relational: investors own portfolios, portfolios contain fund allocations, fund managers have performance records, compliance officers review KYC submissions. This data has foreign key relationships, aggregate calculations, and complex reporting queries. PostgreSQL (via Supabase) handled all of this natively. Firestore's document model would have required extensive denormalization and consistency management across collections.

Row-level security was critical for ZestAMC. Investors can only see their own portfolios. Fund managers can only see funds they manage. Compliance officers see everything. RLS policies enforced this at the database level, so even an application-level bug couldn't expose investor data to unauthorized roles.

DropTaxi: custom backend for multi-tenant isolation

DropTaxi serves branded booking websites for dozens of taxi operators from a single deployment. Each operator needs isolated data (their drivers, their bookings, their pricing rules) and a distinct domain with separate SEO (unique meta tags, sitemaps, structured data). Supabase and Firebase don't support this level of multi-tenant isolation out of the box.

We built DropTaxi with a custom backend using Turso (distributed SQLite) for per-tenant database isolation. Each tenant gets a separate database instance that spins up automatically when they're onboarded. No shared tables. No tenant_id filtering. Full isolation. The 164-test suite validates that tenant data never leaks across boundaries. This architecture was impossible to build on Supabase or Firebase without extensive workarounds.

Decision framework

Answer these questions to pick your backend:

• Is your data relational? Users, orders, products with foreign keys and joins = Supabase or custom. Document-shaped data with few relationships = Firebase or Supabase.
• Do you need mobile push notifications and offline sync? Yes = Firebase (or Firebase Auth + FCM with any backend). No = Supabase or custom.
• Is multi-tenancy a core requirement? Yes = custom backend. Supabase can handle basic tenancy with RLS, but dedicated tenant isolation requires custom architecture.
• What's your launch timeline? Under 4 weeks = Supabase or Firebase (pre-built auth, storage, APIs). 6+ weeks = custom backend is viable.
• How important is avoiding vendor lock-in? Critical = Supabase (open source, self-hostable) or custom. Acceptable risk = Firebase.

For most startups building web-first SaaS products, Supabase is the default choice. It gives you a proper database, a generous free tier, and a clear migration path if you outgrow the managed service. Start with Supabase. Add custom backend components (dedicated API routes, background job queues, external integrations) as your product demands them.

Frequently asked questions