Backend-as-a-Service 2026 — Supabase vs Firebase vs Pocketbase vs Appwrite vs Convex vs InstantDB Deep Dive (The 1-Person SaaS Backbone) (english)

Prologue — What Will the "1-Person SaaS" Be Built On?

May 2026. The first meeting on a new project looks weirdly similar to 2020, and yet different.

"Backend — building it yourself or using a BaaS?"

The difference: almost no team builds backend from scratch anymore. One-person SaaS, indie games, side projects, even seed-stage startups. Writing your own auth, storage, realtime, vector, DB, and edge functions is too expensive — and frontally collides with the 2026 vibe of "one person ships a SaaS with AI."

The BaaS landscape itself is different from five years ago.

• The Firebase monoculture is over. Google's giant tool still owns big mindshare, but a real number two has emerged — Supabase, the Postgres-based open-source alternative.
• Self-host BaaS is now a real category. Appwrite and Pocketbase each found their niche and both reached stable v1.x territory.
• A new model — the "reactive backend" — landed. Convex turned function results into client subscriptions, claiming a slot as a "backend that lives with server components."
• InstantDB took the 'Firebase + Linear' path. Tagged templates and realtime graph queries — widely framed as "what Firebase would look like if it were reborn in the Vercel era."

This article compares seven tools as of May 2026.

• Supabase — the de-facto open-source Postgres-based BaaS standard
• Firebase — still the biggest BaaS, Google Cloud integration, AI era via Genkit
• Pocketbase — single Go binary on SQLite, first pick for indie projects
• Appwrite — multi-feature full BaaS, self-host friendly
• Convex — reactive backend, TypeScript-native functions
• InstantDB — realtime TS-first queries, "Firebase for the Vercel era"
• PlanetScale + Clerk + custom — the build-your-own-stack alternative

We compare across seven axes — data model, realtime, auth, vector and AI, self-host, vendor lock-in, and pricing at scale — and end with honest scenario-based picks.

1. The Landscape — What Counts as BaaS, Who Fights Whom

First, taxonomy. They all say "BaaS" but the shapes differ.

This article focuses on the bolded six — Supabase, Firebase, Pocketbase, Appwrite, Convex, InstantDB. Build-your-own gets a short chapter at the end.

Why these six

• Supabase — number two in BaaS. GitHub stars over 78k, the de-facto open-source full-BaaS standard. DataLab, SQL Editor v2, and Branching are the big last-year changes.
• Firebase — Google's massive BaaS, mobile-first. App Hosting and Genkit moved it into the AI era. Firestore still dominates the hosted document-DB slot.
• Pocketbase — single Go binary, SQLite-based. The v0.22 line stabilized it and made it the default first pick for solo indie projects. GitHub stars over 42k.
• Appwrite — self-host-friendly full BaaS. Functions, Realtime, and Storage all stabilized in v1.6 and v1.7. Appwrite Cloud is now GA as a hosted option.
• Convex — TypeScript-native reactive backend. Functions + auto cache + WebSocket subscriptions, pitched as "a backend that lives next to your server components."
• InstantDB — grew fast in 2025 and 2026 after its 2024 beta. TS-first queries (useQuery({ todos: {} })) and a strong rules model are the core.

2. Data Model — SQL, Document, or Reactive Graph

The first fork in BaaS choice is the data model. Get it wrong and you regret it six months in.

Relational (SQL)             Document               Graph/Reactive
     |                           |                       |
Supabase   Appwrite(SQL)    Firebase(Firestore)   InstantDB   Convex
Pocketbase(SQLite)          Appwrite(Docs)        Firestore Datastore

2.1 Supabase — Postgres, full stop

Supabase's essence is "Postgres with a BaaS skin." Data lives in real Postgres tables, and you keep JOINs, triggers, materialized views, CTEs, the whole language.

-- Supabase is actually Postgres, so this works as-is
CREATE TABLE posts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  author_id uuid REFERENCES auth.users (id),
  title text NOT NULL,
  body text,
  created_at timestamptz DEFAULT now()
);

-- Row Level Security is the heart of the permission model
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
CREATE POLICY "own_posts" ON posts
  USING (author_id = auth.uid());

Strengths

• Natural for relationship-heavy SaaS, B2B, CRUD apps.
• Ops knowledge transfers — it's just Postgres (exports, tuning, indexes).
• pgvector extension built in for AI apps.

Weaknesses

• Document and embedded-graph models feel awkward.
• The interaction between transactions, realtime, and RLS can be confusing at first.

2.2 Firebase Firestore — Emperor of Documents

Firestore is collections + documents + subcollections — a NoSQL document DB. Schemaless, with direct client reads and writes as the default model.

import { getFirestore, collection, addDoc } from 'firebase/firestore'

const db = getFirestore()
await addDoc(collection(db, 'posts'), {
  authorId: 'user_123',
  title: 'Hello',
  createdAt: serverTimestamp(),
})

Strengths

• The de-facto standard for mobile and offline sync.
• Permissions through declarative Security Rules.
• Auto-scaling that almost never dies under traffic spikes.

Weaknesses

• No JOINs. Relational data is denormalized and duplicated.
• Limited query expressiveness — predefined indexes, OR constraints, etc.
• Pricing scales with "document reads" — pricing modeling at scale is hard.

2.3 Pocketbase — Clean Relational on SQLite

Pocketbase is a collection model on top of SQLite. "Looks like documents, is actually relational" — a hybrid.

• Collection = SQLite table (with schema).
• Relations between records use the relation field type.
• Schema and records managed visually in the admin UI.

Strengths

• One binary. Run with ./pocketbase serve and you are done.
• SQLite simplicity — backup is file copy, ops cost is near zero.

Weaknesses

• Single node. Horizontal scaling is hard by design (LiteFS is a workaround).
• SQLite limits — concurrent writes, complex queries, and extension modules trail Postgres.

2.4 Appwrite — Documents, Multi-Backend

Appwrite uses a document/collection model but supports MariaDB, MySQL, and MongoDB as the underlying backend. Choice is strength and complexity at the same time.

2.5 Convex — Documents + Reactive Views

Convex's data model is documents + indexes + functions. Data is never exposed directly — always through a TypeScript function.

// convex/posts.ts
import { query } from './_generated/server'

export const list = query(async (ctx) => {
  return await ctx.db.query('posts').order('desc').take(20)
})

// Clients subscribe to function results — realtime by default
const posts = useQuery(api.posts.list)

2.6 InstantDB — Triple Store + Graph Queries

InstantDB sits on an entity-attribute-value (triple store) model with a graph query layer on top.

import { useQuery } from '@instantdb/react'

// "Fetch todos and include each owner"
const { data } = useQuery({ todos: { owner: {} } })

Schema is optional — start without one, add structure gradually.

3. Realtime — Default or Optional?

In 2026 BaaS, realtime is default, not an option. The implementation models differ.

3.1 Supabase — RLS Meets Realtime

Supabase Realtime listens to Postgres logical replication and only pushes changes that pass RLS policy.

const channel = supabase
  .channel('posts')
  .on('postgres_changes',
      { event: '*', schema: 'public', table: 'posts' },
      (payload) => { /* ... */ })
  .subscribe()

The key is that RLS applies to realtime too — write the policy once, and it covers read, write, and realtime in the same place.

3.2 Firestore — The Smoothest Mobile Realtime

onSnapshot is the de-facto realtime API on mobile. Offline queue, auto-reconnect, collection indexes — all bundled.

3.3 Convex — Function Results Are the Subscription Unit

Convex's twist is that the result of a query function is itself a subscription unit. Convex tracks the data a function reads, and when that data changes, it re-runs the function and pushes the new result to subscribed clients.

This makes the "which channel do I subscribe to?" question go away. But the pricing model and function authoring style differ from a typical BaaS, so there is a learning curve.

3.4 InstantDB — Push the Graph Diff

InstantDB lets clients subscribe directly to the graph query they wrote ({ todos: { owner: {} } }). The server knows which attribute changed.

4. Auth and Permissions — Are They Really Ops-Ready?

The real value of a BaaS lives in its auth and permission system. Anyone who has rolled their own knows — token rotation, OAuth callbacks, email verification, MFA, and RLS are tedious.

4.1 Supabase Auth + RLS

The core is JWT + Postgres RLS. The sub claim is exposed as auth.uid() inside any query.

CREATE POLICY "select_own" ON posts FOR SELECT
  USING (author_id = auth.uid());

CREATE POLICY "insert_own" ON posts FOR INSERT
  WITH CHECK (author_id = auth.uid());

RLS is powerful because permission lives with the data itself, but it has a debug curve — a misconfigured policy yields silent empty results.

4.2 Firebase Security Rules

A declarative DSL.

match /posts/{postId} {
  allow read: if true;
  allow write: if request.auth.uid == resource.data.authorId;
}

Learning curve exists, but once you know it, it is very powerful.

4.3 Convex — Per-Function Checks

Convex has no DB-level RLS. All permission checks are inside functions.

export const updatePost = mutation(async (ctx, { id, body }) => {
  const identity = await ctx.auth.getUserIdentity()
  if (!identity) throw new Error('unauthorized')
  const post = await ctx.db.get(id)
  if (post.authorId !== identity.subject) throw new Error('forbidden')
  await ctx.db.patch(id, { body })
})

The pro is explicitness — permission lives visibly in code. The con is consistency — every function has to do it.

4.4 InstantDB Rules

InstantDB uses a Datalog-ish rules DSL. Because the underlying model is a triple store, the rule language matches that shape.

5. AI and Vector — The 2026 Differentiator

The fastest-evolving BaaS area in 2026 is vector, embedding, and AI features.

5.1 Supabase — pgvector's Home Base

Supabase has arguably the most AI-friendly story because pgvector is a first-class citizen.

CREATE EXTENSION vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

RAG, embedding search, and semantic search read like normal Postgres queries. No separate vector DB needed.

5.2 Firebase Genkit — Google's Answer

Genkit is the Firebase-side AI framework, now GA. Vertex AI integration, Gemini models, retrieval, flow definitions, and evaluation — all bundled. Natural for teams that want Firebase backend plus Genkit AI flows together.

5.3 Convex — LLM Calls Inside Functions Are Standard

Calling OpenAI or Anthropic APIs directly inside a Convex function is the standard pattern. Vector indexes are built in, so RAG pipelines stay short.

// convex/rag.ts
export const search = query(async (ctx, { q }) => {
  const embedding = await embed(q)
  const docs = await ctx.db
    .query('docs')
    .withIndex('by_embedding', q => q.vectorSearch('embedding', embedding))
    .take(5)
  return docs
})

6. Self-Host Story — Core Concern for "1-Person SaaS"

Self-hosting is not just a cost story — it is insurance against vendor lock-in.

6.1 Pocketbase — The Simplest Self-Host

Pocketbase self-host takes one minute.

# After downloading the binary
./pocketbase serve --http=0.0.0.0:8090

Fly.io, Railway, any VPS — a single binary and a SQLite file is the whole deployment. Backup is copying that file.

6.2 Supabase — Powerful but Ops-Heavy

Supabase self-hosting works, but you run several services together (Postgres + GoTrue + Realtime + Storage + Studio + ...). A Docker compose gets you started, but production-grade self-hosting takes serious ops effort.

6.3 Appwrite — Docker-Friendly

Appwrite is built self-host-first. docker-compose up -d and a full stack is alive. Natural for indies and small teams.

6.4 Convex — OSS Arrives

In late 2025 Convex shipped an OSS self-host version. It is not 100% feature-parity with hosted, but it seriously reduces lock-in.

6.5 Firebase — Not Possible

Firebase has no self-host. The local emulator is dev only. This is Firebase's single biggest weakness.

7. Vendor Lock-In — Can You Leave?

Beyond self-hosting, the real lock-in is portability of data, code, and ops knowledge.

Why Supabase Lock-In Is Lowest

Supabase's real strength is that the data is just Postgres. pg_dump and import elsewhere works. SDKs sit on standards (PostgREST, GoTrue), so swap cost is low.

Why Firebase Lock-In Is Highest

Firestore export → another DB is not automatic. The model is different (documents to relational mapping is manual), and Security Rules, triggers, and Functions are wired into Google Cloud. Lock-in is structural.

8. Pricing and Scale — Edge Cases Decide

Pricing comparison is not a flat table. What unit is billed? is the real question.

Pricing Traps

The most common mistake is looking only at the generous free tier.

• Firebase bills per "document read." An app showing 50 docs per page reads 50 docs per user-per-pageview. Scale curves steeply.
• Supabase is Postgres + Egress centric, so heavy payloads (images, big JSON blobs) blow up Egress.
• Convex bills function calls + WebSocket connection time. Many always-on mobile clients curve steeply.

1-Person SaaS Scenario (1,000 users/month)

Rough estimates (always check the latest pricing page).

• Supabase Pro — $25/month base + usage + Egress.
• Firebase — Free tier + Blaze pay-as-you-go after, depends on read counts.
• Pocketbase — VPS at $5–$10/month. Other costs effectively zero.
• Appwrite Cloud — Free + usage. Self-host is zero.
• Convex — $25/month base + usage.
• InstantDB — Free + usage.

At this scale Pocketbase or self-hosted Appwrite is dramatically cheaper. The cost is your ops time.

Seed-Stage SaaS Scenario (50,000 users/month)

• Solo self-hosting starts to bite. VPS monitoring, backups, upgrades.
• Supabase Pro, Convex, or Firebase Blaze become the natural choices.
• Firebase, if you have not modeled read counts, gets expensive fast.
• Supabase needs consistent Postgres operations + Egress management.

9. Seven-Axis Comparison — At a Glance

9.1 Core Matrix

9.2 Scenario-Based Picks

AI app (RAG, embeddings, LLM flows)

1. Supabase — pgvector + Edge Functions, smoothest path.
2. Convex — functions + built-in vectors, TS-first.
3. Firebase + Genkit — natural if you are already in Google's stack.

B2B SaaS (relational, complex queries)

1. Supabase — Postgres is the first pick.
2. PlanetScale or Neon + Clerk + your backend — the build-your-own camp.
3. Convex — for TS-first teams that want reactivity.

Mobile-first (offline, push notifications)

1. Firebase — still the de-facto standard. Mature offline sync.
2. Supabase — mobile SDK evolving, but offline is not yet at Firebase level.
3. InstantDB — realtime graph fits mobile UX.

1-person SaaS, indie, side projects

1. Pocketbase — overwhelming value in simplicity.
2. Supabase — free tier + reusable Postgres ops knowledge.
3. InstantDB — small team + realtime friendly.

Self-host first (regulation, security, cost)

1. Appwrite — Docker, full stack.
2. Supabase self-host — powerful but ops-heavy.
3. Pocketbase — simplest.

10. Build-Your-Own — Refusing BaaS

The final card. Some teams deliberately refuse BaaS and assemble responsibilities from discrete services.

Auth        Clerk / WorkOS / Auth.js
DB          PlanetScale / Neon / Supabase Postgres (only)
Realtime    Liveblocks / Ably / your own WS
Storage     S3 / R2 / UploadThing
Functions   Inngest / Cloudflare Workers
Email       Resend
Vector      Pinecone / Turbopuffer / pgvector

Strengths

• Best-in-class for each responsibility.
• An incident in one service does not freeze the whole stack.
• Fine-grained cost control.

Weaknesses

• Integration cost. You write the glue between auth, DB, and realtime.
• Wider debug surface when things break.
• Onboarding new teammates means teaching N tools.

When it is right

• Series A onward, more than 10 engineers.
• After clearly hitting the limits of a specific tool.
• Strong regulatory, SLA, or on-prem requirements.

11. What Changed in the Last Year

Big shifts per tool, 2025–2026.

Supabase

• DataLab — notebook-style SQL exploration with Postgres + AI assistant.
• SQL Editor v2 — faster, stronger AI autocomplete.
• Branching — DB branching went GA. Isolated DB per PR.
• pgvector + HNSW indexes stabilized.
• Edge Functions cold-start improvements.

Firebase

• App Hosting GA — first-class Next.js and Angular hosting.
• Genkit GA — AI flow framework formally launched.
• Data Connect — relational (Postgres) integration built in.
• Firestore pricing adjustments in places.

Pocketbase

• v0.22 line stabilized.
• Realtime SSE performance improved.
• More external OAuth providers.
• Cleaner Go API.

Appwrite

• v1.6 → v1.7 — Functions, Realtime, and Sites stabilized.
• Appwrite Cloud went GA.
• Sites — static site hosting built in.

Convex

• OSS self-host released.
• Vector search hit GA.
• HTTP Actions, Crons, and Scheduling stabilized.
• Next.js and TanStack Start integrations.

InstantDB

• Beta → GA (in stages).
• Permission rules system strengthened.
• Self-host beta available.
• Clerk and Auth.js integrations.

Epilogue — Tool Choice in the "One-Person SaaS" Era

Picking a BaaS is also deciding what unit of work you accept as a billing line. Picturing next year's bill matters more than memorizing today's price page.

Conclusion as of May 2026.

• If you can sit on Postgres, sit on Supabase — low lock-in, ops knowledge is just Postgres knowledge.
• If mobile and offline are the product, Firebase — expensive lock-in, unmatched maturity.
• For 1-person, indie, small teams, Pocketbase is often the right answer — simplicity is speed.
• Self-host full-stack means Appwrite — Docker-friendly, run it on your own infra.
• TS-first reactive backend is Convex — once the function-plus-subscription model clicks, it is delightful.
• Realtime graph plus small code is InstantDB — growing fast.
• Build-your-own if you really know what you are building — integration cost is real.

Decision Checklist

• Is the data model relational or document? — Relational → Supabase or Pocketbase. Document → Firebase, Appwrite, Convex, InstantDB.
• Is realtime core? — Yes → Convex, InstantDB, Supabase, Firestore.
• Mobile + offline sync? — Yes → Firebase first.
• AI, vector, RAG core? — Supabase, Convex.
• Self-host required? — Pocketbase, Appwrite, Supabase, Convex.
• Minimum lock-in? — Supabase, Pocketbase.
• Fastest MVP? — Firebase, Pocketbase, Convex.

Anti-Patterns

1. Choosing by free tier alone. Next year's bill is a curve. Watch the billing unit.
2. Switching tools on vibes alone. Many teams move to Convex because it looks cool and then miss RLS-style permission.
3. Solo self-hosting without an SLA budget. Backups, monitoring, and upgrades all eat your hours.
4. Assuming 300,000 reads per day fits Firebase's free tier. Model the billing first.
5. Running two BaaS at once. "Auth in Firebase, DB in Supabase." Integration cost burns a season.
6. Optimizing for zero lock-in and shipping nothing. Lock-in is a trade-off, zero is impossible.
7. An AI app on a BaaS with no built-in vector. You lose half the value.

Next-Article Candidates

• Supabase Branching + Drizzle ORM after one year — what isolated-DB-per-PR is actually like
• Firebase Genkit vs Vercel AI SDK — same RAG flow, head-to-head
• Six months running a SaaS on Pocketbase — the honest review
• Convex OSS self-host — what is actually different from hosted

"BaaS is not the work of writing a backend. It is the work of deciding not to write one."

— BaaS 2026, fin.

References

• Supabase — Official
• Supabase Docs
• Supabase GitHub
• Supabase Branching
• Supabase pgvector
• Firebase — Official
• Firebase App Hosting
• Firebase Genkit
• Firebase Data Connect
• Firestore Security Rules
• Pocketbase — Official
• Pocketbase GitHub
• Pocketbase Docs
• Appwrite — Official
• Appwrite GitHub
• Appwrite Cloud
• Convex — Official
• Convex Docs
• Convex GitHub
• Convex Self-Hosting
• InstantDB — Official
• InstantDB Docs
• InstantDB GitHub
• Clerk — Auth
• PlanetScale
• Neon — Serverless Postgres
• Inngest — Background Jobs
• Liveblocks — Realtime
• Vercel AI SDK