Convex vs Supabase vs Firebase: Which One to Choose for Your SaaS

Convex vs Supabase vs Firebase: Which One to Choose for Your SaaS

TL;DR

• Firebase is fastest for MVP, but you get strong coupling with Google and unpredictable costs at scale. Suits prototyping, not SaaS with margin.
• Supabase is managed PostgreSQL with authentication and realtime. Much more control, linear pricing, but read replicas are premium. Ideal for B2B SaaS with complex data.
• Convex is a modern realtime database, no SQL, fair compute-based pricing. Less mature in 2024, but the best trade-off between simplicity and control for real-time collaborative products.
• The choice is not technical, it's about margin, data retention (lock-in), and development speed. Three very different paths.

The Real Problem: It's Not Technology, It's Economics

When a founder asks me this, they've usually already started building on Firebase one weekend. They have 2000 users, realise they're locked in, and question themselves.

The truth is none of these three platforms simply "wins". What varies is your business: stage, margin, data complexity, volume, commitment to control.

Firebase is the golden trap. Google's documentation is impeccable, Firestore scales magically, authentication works without configuring anything. But in production, with 50k active users and complex queries, you get read costs that nobody predicted. A client of mine spent €800/month on reads because the product had unusable denormalisations. They migrated and saved €400 in a month. That's margin that disappears.

Supabase fixes this with transparency: PostgreSQL with clear pricing. You know exactly what it costs. But you need to architect better (indices, data replication), it's not magical.

Convex is the technical bet: less mature, but built for the right problem (realtime, no SQL dentistry, compute-based pricing not storage-based).

Firebase: Fast Until Reality

Firebase was made for prototypes. And it works perfectly for that.

What works well:

• Integrated authentication: Google, Apple, anonymous, custom tokens. You have this in production in 30 minutes.
• Firestore has automatic global replication. Write in one region, read in others with sub-100ms latency (p99).
• Rules engine for authorisation: it's an integrated DSL, no extra backend.
• Google Cloud integration: logs, monitoring, Cloud Functions, native.

Real costs (Firestore):

• Read: $0.06 per 100k docs (€0.055). With complex queries that fan-out, it explodes quickly.
• Write: $0.18 per 100k (€0.165).
• Storage: $0.18 per GB/month.
• Delete also costs a read. This is a gotcha I see all the time: fields with null values accumulate, and cleaning is expensive.

Concrete example of a problem: A B2B SaaS with 10k active users and 500M historical documents. Each user makes a query that returns 100 docs. That's 1M reads/day just from that. On Firebase, that's about €180/month just from that query. If you double the denormalisation for performance, you double costs.

Critical trap: Firestore doesn't support JOINs. Everything is denormalisation. This means duplicate data, and each update is a write in 3 places. Costs grow with complexity, not with value.

Supabase in this scenario: PostgreSQL with indices and normal JOINs. About €30/month in storage, queries are CPU-bound not IO-bound.

When Firebase works: Prototyping, MVPs in 2-4 weeks, mobile apps with simple synchronisation, real-time chat, consumer products with little transactional context.

Supabase: The Conservative (and Smart) Path

Supabase is "PostgreSQL + Authentication + Realtime + REST API, all managed".

PostgreSQL is stable, you know the cost (compute + storage), and there are 25 years of proven patterns. This matters in a SaaS: predictability.

Pricing (Supabase Pro, 2024):

• €119/month: 4GB storage, 1GB filestore, auto-scaling compute.
• Each 1GB extra: €1.20/month.
• Realtime: included, but each subscriber costs bandwidth. It's not infinite.
• Database replicas (read-only): €750/month extra per replica.

Why it's cheaper at scale: PostgreSQL costs by what you compute, not by what you read. Ten queries at 100ms each is the same as 1000 queries at 10ms. Firebase pays per read.

A typical B2B SaaS with 20k users on Supabase:

• Pro plan: €119.
• 2 database replicas (one in EU, one in US): €1500.
• Total: around €1600/month.

Same SaaS on Firebase Blaze:

• 100M read operations/month: around €5500.
• Firestore storage (500GB): around €90.
• Egress (data to clients): around €300.
• Total: around €5900/month.

This isn't speculation. I've seen this reproduced three times.

What you need to do differently:

• Architect queries with smart JOINs (don't denormalise everything).
• Configure indices. Firebase doesn't ask for this, PostgreSQL demands it.
• Manage concurrency with RLS (Row Level Security) in Supabase or simple triggers.
• Realtime in Supabase is websocket, so heartbeat rate matters. Many open clients means bandwidth comes out of budget.

Trap in Supabase: Realtime is expensive if not architected properly. If you have 5k users online listening to the same table, you ban subscriptions. You need narrow columns, client-side filters, or extra Redis caching (but now you have another infrastructure).

When Supabase works: B2B SaaS with related data, query accuracy, usage-based billing, cost control needed, data protection (GDPR compliance is simpler, everything in your PostgreSQL), long-term plans without surprises.

Convex: The Future, Today, But with an Asterisk

Convex was born 3 years ago. Backend-as-a-service without SQL, focused on realtime and developer experience.

Architecture: client (JS/TS) connects to Convex backend. You define functions (queries, mutations, actions). Convex manages synchronisation, caching, permissions.

You don't use SQL. You use JavaScript.

// Convex: typical query
export const getMessages = query({
  args: { roomId: v.id("rooms") },
  handler: async (ctx, { roomId }) => {
    return await ctx.db
      .query("messages")
      .filter(q => q.eq(q.field("roomId"), roomId))
      .order("_creationTime", "desc")
      .take(50);
  }
});

Compare with Supabase:

SELECT * FROM messages WHERE room_id = $1 ORDER BY created_at DESC LIMIT 50;

Supabase is straightforward. Convex abstracts the query engine, caches intelligently, synchronises in realtime automatically.

Pricing (Convex, 2024):

• Free: 1M function calls/month, 1GB storage.
• Pro: $20/month, then $0.50 per 1M calls excess, $0.25 per GB storage excess.
• Database: JSONB de facto (like Firestore, but with relations).

A typical collaborative SaaS (e.g. Figma-like, Notion-like):

• 5k users.
• 100 function calls/user/day.
• Total: 500k calls/month.
• On Convex Pro: $20/month.

Same on Supabase Pro: €119/month (more expensive, but you get more resources).

Real gain from Convex: Developer experience. You don't write REST APIs. You define handlers, and the client synchronises automatically. No auth boilerplate, no permission middleware (it uses integrated patterns).

Maturity: In 2024, Convex is stable in production, but not Firebase/AWS in terms of ecosystem. Missing integrations (Stripe, SendGrid need custom actions). Documentation is good, but fewer deep-dives than Firebase/Supabase.

Trap: Lock-in in Convex is real. There's no easy raw data export. Significant migrations mean rewriting entire queries. In Firebase/Supabase exports to JSON/SQL are trivial.

When Convex works: Real-time collaborative products (Notion-like, Figma-like), teams coding in TypeScript (no alternative in Python/Go), focus on development speed above all, low data volume (<5GB), limited budget but competent technical team.

Side-by-Side Comparison: Concrete Numbers

The Real Decision: It's Not Technical

Here's the truth nobody tells you in YouTube videos: the choice depends on three things.

1. Company stage

MVP, seed, Series A differ completely.

• MVP (validation): Firebase is great. You don't spend on infrastructure, you don't have tech debt, you iterate fast. When you hit 10k users and costs spike, you migrate to Supabase or Convex (yes, it's possible, more in "Migrations").
• Seed (product-market fit): Supabase starts making sense. You have revenue, you need predictable margin, data integrity matters. Firebase creates cost problems here.
• Series A+: Convex for realtime products; Supabase for traditional B2B. Firebase only if logic is very simple or global distribution is critical.

2. SaaS margin

This is brutal: what's your MRR target versus product margin?

• If target margin is 70%+, Firebase kills you because infrastructure costs grow with users, not with price. Supabase/Convex let you keep 90% margin with smart infrastructure.
• If margin is 40-50%, Firebase might survive if logic is simple (e.g. simple list app).

3. Data complexity

• Simple data (chat, notifications, boilerplate): Firebase.
• Related data (billing, user accounts, audit logs, reports): Supabase.
• Complex realtime data (collaborative editing, multiplayer games): Convex.

Migrations: Yes, It's Possible (and Easier than You Think)

Firebase -> Supabase is typically done in 2-3 sprints.

Process:

1. Export Firestore to JSON (firebase-export-cli or custom script).
2. Transform to CSV/SQL and import to PostgreSQL.
3. Rewrite queries (Firestore DSL to SQL).
4. Migrate realtime (Firebase listeners to Supabase realtime subscriptions).
5. End-to-end testing (2 weeks).

Convex -> Supabase is harder because Convex doesn't have easy schema export. You need to map handlers to SQL queries manually.

Supabase -> Firebase is rare but possible (SQL to Firestore denormalisation).

Final Traps I've Seen in Production

1. Firebase with heavy deletes: Each delete is a read. If you have data churn (temp sessions, draft documents), you spend a lot. Solution: soft-deletes or TTL.

2. Supabase realtime without filters: Subscribe to entire tables, sync 1000 rows when you need 10. Bandwidth rate explodes. Solution: filters on subscribe, or Redis caching.

3. Convex without function name length in queries: Convex uses function name as cache index. Generic names cause cache collisions. Solution: explicit names (getOrdersByUserId not getOrders).

4. Firebase auth in B2B SaaS: Firebase OAuth is consumer-first. SAML doesn't exist. If the customer wants enterprise SAML/OIDC, it doesn't work. You need an Auth0 wrapper. Supabase does this better.

5. Supabase row-level security without understanding permissions: RLS is powerful but complexity grows. One rule with 3 AND/OR conditions on 50k rows is slow. Needs indices. Many founders skip this.

Conclusion: My Vote

For a new B2B SaaS in 2024:

Start on Firebase if you're pure prototype (2-4 weeks, no revenue). Move to Supabase in 3-6 months if you've nailed the value proposition. Only go to Convex if you need complex realtime and your team dominates TypeScript.

If you have revenue and data complexity, Supabase is the canonical choice. Predictable costs, data is yours, total control, robust community.

If you're building a multiplayer collaborative app (Figma-like), Convex is the honest answer. Less boilerplate, fair pricing, superior dev experience.

Firebase is a comfort trap. Very good until it stops being good (always unexpectedly).

If you're facing a similar problem, book a conversation at https://impact-origin.com/agendamento.