Three backends walk into a startup.

Firebase says:

“I’ve been doing this for years.”

Supabase says:

“Cool. But have you heard of PostgreSQL?”

Convex walks in and says:

“Why are you thinking about your backend this much?”

And honestly... that pretty much describes the battle.

If you're starting a new SaaS, side project, AI app, mobile app, or one of those “this will take me one weekend” projects that mysteriously consumes the next three months of your life, you've probably considered at least one of these:

• Firebase
• Supabase
• Convex

I've spent a lot of time looking at backend-as-a-service platforms, and here's the thing:

There is no universal winner.

But there is a winner depending on what kind of developer you are and what you're building.

And in 2026, the comparison has become much more interesting.

Firebase now has a relational PostgreSQL option through Firebase SQL Connect. Supabase has grown far beyond being “the open-source Firebase alternative.” And Convex has become a genuinely interesting third option with its reactive backend model, TypeScript-first workflow, and even an open-source/self-hosting story.

So let's forget the marketing pages.

Let's talk about what it actually feels like to build with them.

The 30-Second Answer

If you don't want to read the whole article:

My simplified recommendation:

Choose Convex if:

You want ridiculous developer speed, TypeScript everywhere, and realtime is a core part of your product.

Choose Supabase if:

You want PostgreSQL, SQL, portability, powerful relational modelling, and a backend you can understand at every layer.

Choose Firebase if:

You're building heavily around mobile, Google Cloud, push notifications, analytics, Crashlytics, or the enormous Firebase ecosystem.

But that's the boring answer.

Let's go deeper.

1. Convex: The Backend That Feels Like React

Convex has a very different philosophy from the other two.

With most backend platforms, you think like this:

Frontend
   ↓
API
   ↓
Backend logic
   ↓
Database
   ↓
Realtime/WebSocket layer
   ↓
Frontend state update

Convex basically asks:

What if we removed half of that mental overhead?

A Convex backend revolves around three main concepts:

query()
mutation()
action()

A query reads data.

A mutation changes data.

An action handles things like calling Stripe, OpenAI, external APIs, etc.

That sounds simple.

The interesting part is what happens when you query data.

Convex queries are automatically reactive. When the underlying data changes, subscribed clients can receive updated query results without you manually building a synchronization system around them. Convex also caches query results automatically.

That means this:

const messages = useQuery(api.messages.list);

isn't mentally equivalent to:

GET /messages

It's closer to:

Keep this UI synchronized with the result of this query.

That's a subtle difference.

But once you're building:

• chat
• multiplayer experiences
• dashboards
• collaborative editors
• live notifications
• activity feeds
• shared todo apps
• project management systems

...it becomes a massive difference.

Convex's Biggest Advantage Isn't the Database

It's the amount of backend code you don't have to think about.

You aren't constantly asking:

Do I need a REST endpoint here?

Should this be WebSocket?

Should I invalidate this cache?

Should I refetch this query?

How do I keep two browser sessions synchronized?

Convex's answer is often:

Don't worry about it.

That's extremely attractive for small teams.

And even more attractive for solo developers.

But There Is a Catch

Convex asks you to adopt the Convex way of building backends.

Its database stores JSON-like documents and supports schemas, indexes, references and relational-style modelling, but you're not sitting directly on top of PostgreSQL writing arbitrary SQL.

For many applications, that's completely fine.

But if your brain immediately starts thinking:

SELECT
  customers.country,
  SUM(orders.total)
FROM orders
JOIN customers
  ON customers.id = orders.customer_id
GROUP BY customers.country;

Supabase is probably going to feel more natural.

Convex optimizes for:

application developers building products.

Supabase optimizes more toward:

developers who want a real database underneath their product.

Those sound similar.

They aren't.

2. Supabase: PostgreSQL Wearing a Really Nice Suit

Supabase started life with an easy marketing pitch:

Open-source Firebase alternative.

I don't think that description does it justice anymore.

The biggest difference is simple:

Supabase gives you PostgreSQL.

Not:

“A database inspired by relational databases.”

Not:

“A proprietary database with SQL-like functionality.”

A real PostgreSQL database.

Supabase builds Auth, Storage, Realtime, Edge Functions, APIs and other tooling around it.

That one architectural decision has enormous consequences.

You get:

• joins
• constraints
• foreign keys
• views
• triggers
• database functions
• extensions
• indexes
• transactions
• SQL
• decades of PostgreSQL knowledge from the internet

And when your cute little weekend SaaS suddenly becomes an actual business...

those boring database features become very sexy.

Supabase's Secret Weapon: Boring Technology

Software developers love shiny things.

Founders should sometimes love boring things.

PostgreSQL is boring in the best possible way.

If your application eventually contains:

users
organizations
memberships
subscriptions
products
orders
payments
invoices
permissions
audit_logs

you're going to start appreciating relational databases very quickly.

Imagine asking:

Give me every active organization on the Pro plan whose subscription renews this month and has more than five active members.

In PostgreSQL?

That's normal.

Complex relational querying is literally what the thing was designed to do.

And Then There Is Row Level Security

Supabase heavily uses PostgreSQL Row Level Security.

You can write policies such as:

create policy "Users can read their own documents"
on documents
for select
using (auth.uid() = user_id);

Now your authorization rule lives at the database layer.

That's powerful.

Even if somebody reaches the database through another permitted API path, PostgreSQL can still enforce the policy.

But...

RLS is also one of those technologies that starts like:

Wow, this is elegant!

and three weeks later becomes:

Why is this query returning zero rows?

😂

Power usually comes with complexity.

Supabase Realtime Is Good — But It's Not Convex Realtime

Supabase absolutely supports realtime.

But philosophically, it works differently.

Supabase currently offers mechanisms including Broadcast, Presence, and database-change subscriptions. Its documentation recommends Broadcast for scalable database-change subscriptions, while direct Postgres Changes is the simpler approach but has different scaling characteristics.

With Supabase, realtime feels like a capability you add.

With Convex, realtime feels like a property of the database.

That's probably the cleanest distinction I can make.

3. Firebase: The Backend Everyone Loves to Declare Dead

Every couple of years developers announce:

Firebase is dead.

Firebase:

continues running half the mobile apps on their phones

Okay, slight exaggeration.

But Firebase isn't going anywhere.

And dismissing it because Supabase and Convex are cooler on developer Twitter is silly.

Firebase's advantage is something startups underestimate:

Ecosystem.

Firebase isn't just a database.

You have a huge collection of tools around application development:

• Authentication
• Firestore
• Realtime Database
• Cloud Functions
• Cloud Messaging
• Hosting
• Analytics
• Crashlytics
• Remote Config
• App Distribution
• Performance Monitoring
• Google Cloud integrations

If you're building a serious mobile product, that collection is hard to ignore.

The Old Firebase Criticism Is Becoming Outdated

Historically, one of the easiest arguments against Firebase was:

“Firestore is NoSQL. My app needs relational data.”

That argument isn't completely valid anymore.

Firebase now has SQL Connect, backed by Cloud SQL for PostgreSQL.

You define a relational schema and operations through GraphQL-style definitions, and Firebase can generate strongly typed client SDKs around those operations.

That means Firebase in 2026 can effectively give you two very different database approaches:

Firestore
    ↓
Document-oriented, realtime-friendly database

SQL Connect
    ↓
PostgreSQL relational database

That's a pretty significant evolution.

Firebase is no longer simply:

“The NoSQL option.”

Firebase Still Has One Problem I Can't Ignore

Firebase projects can become...

very Firebase.

At first you use:

Firebase Auth
+
Firestore

Then:

Cloud Functions

Then:

Cloud Storage

Then:

Firebase Messaging

Then some Google Cloud service.

Then another Google Cloud service.

And suddenly your architecture diagram looks like Google's homepage had children.

None of this is necessarily bad.

In fact, it can be incredibly productive.

But leaving becomes increasingly painful.

That's vendor lock-in.

The Lock-In Question

This is where things get interesting.

Supabase

Probably the winner.

Your core database is PostgreSQL.

If one day you decide:

I'm done with Supabase.

Your data model is still PostgreSQL.

Obviously, migrating an entire production backend is never effortless, and Supabase-specific features still need replacements.

But PostgreSQL gives you a beautiful escape hatch.

Supabase also officially supports self-hosting.

Convex

This answer changed considerably.

Convex's backend is open source and can now be self-hosted.

That removes one of the strongest historical arguments against adopting a more opinionated backend.

However, your application architecture is still written around Convex's programming model.

So I would describe the lock-in as:

Infrastructure lock-in: lower than you might expect.

Programming-model lock-in: definitely present.

Firebase

Your database might be portable to some degree — especially if you're using PostgreSQL through SQL Connect — but Firebase itself remains deeply integrated with Google's managed ecosystem.

That's fantastic when you want the ecosystem.

Less fantastic when you're trying to escape it.

The Pricing Problem Nobody Can Answer With a Single Number

People love asking:

Which one is cheapest?

Wrong question.

The correct question is:

Which pricing model matches my workload?

Firestore's Standard pricing includes charges around document reads, writes, deletes, storage and network use. Realtime listeners can also generate billable reads as results change.

Supabase's hosted pricing behaves differently. Projects have PostgreSQL compute resources, while things like egress, storage, active users, Edge Function invocations and Realtime usage have their own quotas and overages depending on the plan.

Convex again has its own model, including resources such as database storage, database I/O, egress, function execution and search usage depending on your plan.

So don't compare them like:

Firebase = $X
Supabase = $Y
Convex = $Z

Instead model your application.

A chat app has a completely different access pattern from an accounting system.

A dashboard refreshing constantly behaves differently from a blog.

A marketplace behaves differently from an AI document processor.

Architecture determines your bill more than the logo on your dashboard.

Where Convex Absolutely Wins

Let's say I'm building:

A collaborative project-management application where multiple users are editing tasks and watching updates happen instantly.

I'd probably reach for Convex first.

Why?

Because synchronization is part of the programming model rather than something I'm assembling afterward.

The developer loop is beautiful:

Define schema
↓
Write TypeScript query
↓
Use query from React
↓
Data changes
↓
UI updates

Very little glue.

For a startup trying to discover whether anybody actually wants the product, that's powerful.

You can optimize architecture later.

You cannot optimize a startup that never ships.

Where Supabase Absolutely Wins

Now imagine I'm building:

A SaaS with customers, organizations, roles, subscriptions, invoices, reports and an admin dashboard.

I'm probably picking Supabase.

Not because Convex couldn't build it.

It absolutely could.

I'm choosing Supabase because I know where this product is heading:

More relationships
More reporting
More analytics
More migrations
More weird admin queries
More data integrations

At some point someone is going to ask:

Can you export all customers who purchased X but not Y between these two dates, grouped by organization?

And PostgreSQL will quietly sit in the corner smiling.

Where Firebase Absolutely Wins

Now imagine I'm building:

A consumer mobile app with push notifications, authentication, analytics, remote configuration, crash reporting and tight Google Cloud integration.

Firebase immediately becomes much more attractive.

Could I assemble those pieces elsewhere?

Absolutely.

But that's the point.

I'd have to assemble those pieces.

Firebase already has an absurd amount of application infrastructure under one roof.

Sometimes boring maturity beats architectural purity.

What About AI-Assisted Development?

This category has become surprisingly important.

We're increasingly not writing every line ourselves.

Claude Code, Codex, Cursor and similar agents are becoming part of the development loop.

And backend architecture matters a lot here.

Agents love:

• explicit schemas
• generated types
• predictable project structures
• local development environments
• clear authorization models

All three platforms have been moving aggressively in this direction.

Convex's current documentation has dedicated guidance for coding agents including Claude Code, Codex and Cursor.

Firebase now documents workflows where AI coding agents can generate SQL Connect schemas, secured operations, typed SDKs and even frontend integration.

Supabase, meanwhile, exposes a very agent-friendly world of PostgreSQL, generated APIs, migrations, CLI tooling and MCP integrations.

This matters.

The backend of the future isn't only being designed for humans.

It's increasingly being designed for humans supervising agents.

My Decision Tree

Here's the completely scientific decision tree I use:

Do you strongly want PostgreSQL?
│
├── YES → Supabase
│
└── NO
    │
    ├── Is realtime central to the product?
    │       │
    │       └── YES → Convex
    │
    └── Are you heavily invested in mobile / Google services?
            │
            └── YES → Firebase

Obviously reality is more complicated.

But honestly?

That gets you surprisingly far.

My Picks by Project Type

Realtime chat app

🥇 Convex

Collaborative SaaS

🥇 Convex

Supabase would be a very close second if the data model becomes heavily relational.

Traditional B2B SaaS

🥇 Supabase

Postgres wins this one for me.

E-commerce backend

🥇 Supabase

Again: relational data.

Products, orders, customers, payments, inventory.

Give me SQL.

Mobile consumer application

🥇 Firebase

Especially when Firebase Cloud Messaging, Analytics and Crashlytics are useful.

Weekend MVP

🥇 Convex

The fewer infrastructure decisions I have to make before getting users, the better.

Application requiring heavy reporting

🥇 Supabase

SQL.

Next question.

Existing Firebase application with real users

🥇 Firebase

Please don't rewrite your functioning production system because somebody posted a cool Convex demo.

Migration-driven development is a dangerous hobby.

So... Which One Would I Choose Today?

If you forced me to select one backend for every project I build for the next two years, I'd probably choose:

Supabase.

Not because it has the fanciest developer experience.

But because PostgreSQL gives me enormous flexibility.

I can build:

• SaaS
• marketplaces
• APIs
• internal tools
• AI applications
• dashboards
• mobile backends
• e-commerce
• data-heavy products

without worrying too much about whether my database model will eventually fight me.

But...

If you asked:

Which one makes me most excited to build something new?

I'd say:

Convex.

There's something incredibly satisfying about removing synchronization, caching and API boilerplate from your mental stack.

Convex feels like someone looked at modern React development and asked:

Why doesn't the backend feel like this?

And then tried to build exactly that.

And Firebase?

Firebase is the experienced engineer in the room that everyone keeps calling old while it quietly continues running production systems at ridiculous scale.

I wouldn't automatically choose Firebase for every new web SaaS.

But dismissing it would be equally foolish.

Especially now that Firebase has a serious relational PostgreSQL story.

Final Verdict

Here's how I see the three philosophies:

🔴 Convex

“Your backend should react to your data.”

Choose it for speed, TypeScript DX, real-time products, and minimal infrastructure thinking.

🟢 Supabase

“Your backend should be built on technologies you already understand.”

Choose it for PostgreSQL, relational data, control, portability and long-term flexibility.

🟡 Firebase

“Your backend should come with everything.”

Choose it for ecosystem maturity, mobile development, Google integrations and an enormous collection of production-ready services.

The mistake isn't choosing Firebase.

The mistake isn't choosing Supabase.

And the mistake isn't choosing Convex.

The mistake is choosing a backend because everyone on X is talking about it...

before understanding what kind of application you're actually building.

Now I'm curious:

If you were starting a SaaS today, which one would you pick — Convex, Supabase, or Firebase?

And more importantly...

why?