Supabase vs Convex vs PocketBase vs Appwrite: Which BaaS Wins in 2026?

Picking a Backend-as-a-Service in 2026 feels harder than it should. Four serious contenders dominate the conversation right now: Supabase, Convex, PocketBase, and Appwrite. Each one solves the same problem (auth, database, storage, realtime) with very different opinions about how a backend should feel.

Across the 50+ projects we've shipped at Warung Digital Teknologi (wardigi.com), I've reached for at least three of these four for production work. From small client MVPs to internal aggregator sites, the right BaaS is the difference between an MVP that ships in a weekend and one that drags through a month of plumbing. This comparison is not a press-release recap — it is what I'd tell a developer friend who asked me which one to pick this week.

The 30-Second Verdict

Before I dig into specifics, here is the short answer most people are looking for:

• Supabase — pick it when you want Postgres, want to scale past hobby traffic, and want a managed cloud you can also self-host later.
• Convex — pick it when realtime reactivity is the core feature of your app and your team writes TypeScript end-to-end.
• PocketBase — pick it when you want a single binary, SQLite, and the lowest hosting bill humanly possible. Great for MVPs and internal tools.
• Appwrite — pick it when you need first-class mobile SDKs (Flutter, iOS, Android) and prefer a document-style API on top of MariaDB.

The deeper you go, the more these tools diverge. Let me walk through each one with the angle of someone who has actually deployed them.

Supabase: The Postgres-First Heavy-Hitter

Supabase is the closest thing the BaaS world has to a "default choice" in 2026. The pitch is simple: take a real PostgreSQL database, wrap it with a generated REST API (PostgREST), add auth, storage, edge functions, and realtime — and ship it as a managed service that is also fully open-source.

What it costs in 2026

The Free tier covers two projects with 500 MB database storage and 50K monthly active users. The Pro plan starts at $25/month per project and includes 8 GB of database storage, 100 GB of object storage, and 100K monthly active users, plus a $10 monthly compute credit that covers a Micro instance. Upgrading to a dedicated 2-core / 8 GB instance is $110/month, and the high-end 16-core / 64 GB jumps to $960/month.

The pricing reality I keep hitting in client work: the $25 sticker price is honest for traffic under the Pro caps, but compute add-ons creep up fast once you push past Micro. For a SaaS doing more than light read workloads, budget $60-$120/month, not $25.

Where Supabase actually shines

Three things make me reach for Supabase first when the problem looks relational:

1. Real Postgres, not a wrapper. You get the entire PostgreSQL ecosystem — extensions like pgvector, pg_cron, and PostGIS work as advertised. Two of our internal aggregator sites (one tracking ~3,000 records, another running daily imports of 100-200 records) lean on this.
2. Row-Level Security by default. For tables created via the dashboard, RLS is now enabled out of the box in 2026. That single change has saved me at least three "oops, the API is wide open" moments since the rollout.
3. The Realtime engine is no longer a toy. The 2026 release notes claim 10,000+ concurrent websocket connections per project, and the new Presence Authorization gives fine-grained control over who sees who is online — useful for chat-style or collaboration features.

Where Supabase frustrates me

The honest tradeoff: Postgres is powerful, but the learning curve is real. Junior devs on my team consistently hit walls writing RLS policies. The new API key model (publishable keys for client-side, multiple revocable secret keys for server-side) is safer than the old anon/service_role pair, but migrating an existing project is a careful afternoon — not a one-line change.

Cold-start latency on the Micro tier is also a recurring complaint. If your Pro project sits idle for hours, the first request after that pause can spike past 2 seconds. Bumping to the next compute tier removes the issue but also bumps the bill.

Convex: TypeScript-Native, Reactive by Default

Convex is the most opinionated of the four. Instead of "here is a database with a REST wrapper," Convex says: write TypeScript functions that read and write data, and we will handle reactivity, transactions, and caching automatically. Queries are reactive end-to-end — when underlying data changes, your React component re-renders without a manual subscription.

What it costs in 2026

Convex revamped its pricing this past year. The free Starter plan now supports up to 6 team members and includes the full platform — TypeScript functions, reactive queries, file storage, vector search, and authentication — under usage-based limits. Going past those limits triggers warning emails first, then HTTP errors if you ignore them. Paid plans move to pay-per-use rather than rigid tiers, which is a friendlier model for projects that grow unpredictably.

Where Convex actually shines

I tested Convex on a small client prototype (a real-time content moderation queue) and the developer experience genuinely surprised me. Three things stood out:

1. Type safety from schema to React. Define a schema.ts, run npx convex dev, and the generated dataModel.d.ts propagates types into every query, mutation, and React hook. No tRPC ceremony, no manually-typed Zod parsers, no GraphQL codegen.
2. Reactive queries without boilerplate. A list of items in your UI updates the moment another user inserts or edits something. With Supabase or Appwrite you'd wire up a websocket subscription and reconcile state manually. With Convex, the React hook does it.
3. Transactions you can trust. Mutations are serializable transactions by default. I've watched junior devs write race-conditiony Postgres code that silently double-charges users; Convex's model makes that class of bug much harder to introduce.

Where Convex frustrates me

The cost of all that opinion: vendor lock-in. Convex is not Postgres or MySQL — it is its own document store with its own query language. Migrating off Convex is rewriting your data layer from scratch. For a long-lived enterprise codebase, that risk is real.

You also need TypeScript 5.0.3 or newer, which is fine for new projects but a nuisance for older monorepos still pinned to 4.x. And the self-hosting story is weaker than the other three — Convex is essentially a hosted product first, OSS second.

PocketBase: One File, Zero Drama

PocketBase is the underdog favorite. It is a single Go binary — yes, one file — that bundles SQLite, auth, file storage, realtime subscriptions, and an admin dashboard. You drop the binary on any Linux box, run it, and you have a backend.

What it costs in 2026

PocketBase itself is free. There is no managed cloud — you pay only for the server you run it on. On a $4/month Hostinger VPS, I've run a PocketBase instance serving an internal client tool with no measurable performance issues for months.

What changed in v0.23

Version 0.23.0 was a major refactor of the internals. The team replaced the old echo router with one built on Go 1.22's enhanced net/http mux, merged the daos packages into core.App to simplify DB operations, and added a custom DBConnect function so you can swap SQLite for libsql/Turso, sqlcipher, or other drivers. That last change unlocks edge-distributed PocketBase deployments via Turso, which is genuinely interesting for global apps.

Where PocketBase actually shines

For MVPs, internal tools, and "I just need a backend for my weekend project" use cases, PocketBase is the lowest-friction option I've ever used. Three reasons it keeps winning:

1. Deployment is one scp. No Docker compose, no PaaS, no environment variables ritual. Upload the binary, run it under systemd, point a reverse proxy at it.
2. Schema-builder UI that stays out of the way. The admin dashboard lets non-developers build collections without touching SQL. I've handed PocketBase to designers and watched them prototype data models before I finished my coffee.
3. SQLite is fine, actually. For projects under ~1M rows and moderate write traffic, SQLite outperforms most teams' assumptions. WAL mode, sensible indexes, and PocketBase's prepared statements keep p50 query latency under 5ms in my testing.

Where PocketBase frustrates me

It is single-node by default. If you outgrow one VPS, your options are vertical scaling, the new Turso-backed setup, or migrating to something else. Compared to Supabase or Convex, the realtime subscription system is also less mature — fine for chat-style features, but I would not bet a real-time gaming backend on it.

The other gap is auth. PocketBase covers email/password, OAuth2 providers, and OTP, but you will not find Supabase's magic-link UX or Appwrite's device-management dashboard out of the box. For most projects, that is fine. For consumer apps with sophisticated identity needs, it is a constraint.

Appwrite: The Mobile-First Document Backend

Appwrite plays a different game from the others. It is a document-style API on top of MariaDB, with a heavy focus on first-class SDKs for Flutter, Swift, Kotlin, React Native, and the standard web stack. If your app is mobile-first or cross-platform, Appwrite's SDK story is a real differentiator.

What it costs in 2026

Appwrite restructured its pricing in late 2025. As of September 1st, 2025, the Pro base price moved from $15 to $25 per project per month, with the per-seat model replaced by per-project billing. The compensation: additional bandwidth dropped by 62% (from $40 to $15 per 100 GB), GB-hours decreased by 33% (from $0.09 to $0.06), and additional storage came down 6.7% (from $3 to $2.80 per 100 GB).

Net effect: the new pricing is friendlier for high-traffic projects with few collaborators, and slightly more expensive for tiny teams running a side project. Self-hosting Appwrite remains free and is the route I see most independent developers take.

Where Appwrite actually shines

If I were starting a Flutter app tomorrow, Appwrite would be my first call. Three reasons:

1. SDK quality. Flutter and React Native devs report fewer rough edges with Appwrite than with the equivalent community packages for Supabase or PocketBase. The team treats mobile as a first-class citizen, not an afterthought.
2. Functions runtime. Appwrite Functions support Node.js, Python, PHP, Dart, Ruby, and more — a wider language menu than Supabase Edge Functions (Deno-only) or Convex (TypeScript-only).
3. Self-hosting that does not feel like a science project. The Docker compose setup is friendly, and the admin console gives you everything the cloud version does. We use the self-hosted version internally for one client project on a $12/month VPS.

Where Appwrite frustrates me

The document model is fine for most use cases, but if your data is genuinely relational — joins, foreign keys, complex aggregations — you will fight Appwrite the same way you would fight Firestore. For those workloads, Supabase is a saner pick.

The other gripe: the Appwrite admin console is feature-rich but heavier than PocketBase or Supabase Studio. On slow connections, I've seen 3-4 second initial loads. Not a dealbreaker, but worth noting.

Head-to-Head Feature Comparison

Feature	Supabase	Convex	PocketBase	Appwrite
Database	PostgreSQL	Document store (TS-native)	SQLite (or Turso)	MariaDB (document API)
Realtime	Postgres CDC + websockets	Reactive queries (built-in)	Built-in subscriptions	Realtime API (websockets)
Auth providers	20+ social, magic links, OTP	Clerk integration, OAuth	Email/password, OAuth2, OTP	30+ providers, MFA, devices
Storage	S3-compatible	File storage built-in	Local filesystem, S3	Local + S3-compatible
Edge functions	Deno-based	TypeScript only	JS hooks (Goja runtime)	Node, Python, PHP, Dart, more
Free tier	2 projects, 500 MB DB, 50K MAU	Starter: 6 team, usage-based	Free, self-host only	1 project, 75K users, 2 GB
Paid entry	$25/mo Pro	Pay-per-use	$0 (VPS cost only)	$25/mo Pro (per project)
Self-host	Yes, OSS	Limited	Yes, single binary	Yes, Docker compose
Mobile SDK quality	Decent (community-led on some)	Web/RN focus	Community SDKs	First-class
Vendor lock-in risk	Low (it is Postgres)	High	Low	Medium

How I'd Pick — A Decision Framework

From 11+ years of evaluating backend tooling, here is the heuristic I run through when a client asks "which BaaS?":

Pick Supabase if

• Your data model is naturally relational (orders, users, line-items, invoices)
• You expect to need full SQL eventually (reporting, analytics, ad-hoc queries)
• You want one cloud now and the option to self-host later without rewriting your app
• You will use pgvector, PostGIS, or other Postgres extensions

Pick Convex if

• You write TypeScript end-to-end and want type safety from DB to React component
• Your app is fundamentally collaborative or realtime (multiplayer docs, dashboards, queues)
• You are okay paying for opinion and convenience instead of managing primitives
• You can accept the lock-in tradeoff for the velocity gain

Pick PocketBase if

• You are shipping an MVP, an internal tool, or a side project
• Your traffic and data fit comfortably under ~1M rows and a single VPS
• You want the lowest possible hosting cost (think: $4-12/month total)
• You value simplicity over features

Pick Appwrite if

• You are building a mobile-first or cross-platform app (Flutter, RN, native)
• Your data is document-shaped, not deeply relational
• You want a wide range of language runtimes for your serverless functions
• You want a self-hosted option that mirrors the cloud version exactly

What I'd Avoid

Two patterns I'd recommend against, having watched them play out on real projects:

1. Don't pick Convex for a CRUD app. If your app is "list of things, edit a thing, delete a thing," Convex's reactivity does not earn its lock-in cost. Use PocketBase or Supabase.
2. Don't pick PocketBase for anything that needs horizontal scaling on day one. Single-binary is a feature until it is a ceiling. If you know you'll need multi-region from launch, start with Supabase or Appwrite.

Frequently Asked Questions

Is Supabase still cheaper than Firebase in 2026?

For most workloads, yes — Supabase's flat $25 Pro tier with predictable add-ons beats Firebase's pay-per-read pricing once your app gets real usage. Firebase remains cheaper for very low-traffic apps that stay inside the free tier.

Can I run PocketBase in production for a paying-customer SaaS?

Yes, with caveats. Single-VPS PocketBase is fine for SaaS up to a few thousand active users. Beyond that, plan for a migration or use the libsql/Turso integration introduced in v0.23 to push the ceiling further.

Does Convex support SQL?

No. Convex uses its own TypeScript-native query API. If your team needs SQL access for analytics or BI tools, this is a real limitation — pick Supabase instead.

How does Appwrite's new pricing affect existing customers?

Existing Pro accounts moved from $15/seat to $25/project starting September 2025. For solo developers, the change is roughly neutral. For teams of 5+ on a single project, it is a significant savings.

Which one has the best community support?

Supabase has the largest community by GitHub stars and Discord size. PocketBase has a smaller but unusually friendly community. Convex and Appwrite are growing fast but smaller in absolute terms.

Bottom Line

None of these four are bad choices — that is the unusual thing about the BaaS market in 2026. The right pick depends almost entirely on your data shape, your team, and your tolerance for vendor opinion. My quick gut-check, after shipping with three of the four:

• Default to Supabase for serious SaaS work that may scale.
• Reach for Convex when realtime is the product, not a feature.
• Reach for PocketBase for MVPs and internal tools where simplicity beats everything.
• Reach for Appwrite when mobile or document-shaped data is the core constraint.

The worst choice is paralysis. Pick one, ship a prototype this week, and iterate. All four export your data; none of them will trap you forever — except Convex, which is honest about its tradeoffs upfront.