PocketBase, Appwrite, and Convex: Backend-as-a-Service Beyond Firebase and Supabase

Firebase and Supabase solved the “I need a backend but I do not want to build one from scratch” problem for a lot of projects. Firebase did it with a NoSQL real-time database and a tightly integrated authentication system. Supabase did it with Postgres, an auto-generated REST API, and a solid developer experience.

Both have real limitations. Firebase’s NoSQL data model creates pain when your data is inherently relational. Firebase’s pricing can spike unexpectedly at scale. Supabase assumes Postgres and SQL — correct choice for many projects, wrong choice for others. And both are primarily cloud services, which means your data lives on someone else’s infrastructure.

Three alternatives have matured enough to be serious production options: PocketBase, Appwrite, and Convex. They are not trying to replace Firebase or Supabase. They are filling different shapes.

PocketBase

PocketBase is a single executable file written in Go. Download it, run it, and you have a complete backend: a SQLite database with a visual admin UI, REST and real-time APIs auto-generated from your collections, email/password and OAuth2 authentication, file storage, and an extension system that lets you add Go code to the binary.

The key word is single. No Docker Compose. No managed services. No npm install. A VPS running PocketBase with a couple gigabytes of RAM can handle tens of thousands of users for typical read-heavy workloads. SQLite’s performance characteristics are often underestimated — for single-server deployments where you control the hardware, it handles significant concurrent read load efficiently.

Where PocketBase shines: Internal tools, solo developer projects, prototypes, apps that will never need horizontal scaling, and teams that want the simplicity of a file-based deployment. PocketBase’s admin UI is surprisingly polished — non-technical teammates can browse and edit data without writing SQL. For a small team that wants backend control without ops overhead, it is hard to beat.

Where it does not fit: Applications that need to scale horizontally (multiple servers) — SQLite is a single-file database, and PocketBase inherits that constraint. At high write throughput, the SQLite model becomes a bottleneck. It also lacks features Appwrite has matured: team-based permissions, more OAuth providers, and function execution.

A simple PocketBase setup for a web app:

// Client-side with the PocketBase JS SDK
import PocketBase from 'pocketbase';

const pb = new PocketBase('https://your-pocketbase.example.com');

// Login
await pb.collection('users').authWithPassword('user@example.com', 'password');

// Subscribe to real-time changes on a collection
pb.collection('posts').subscribe('*', (e) => {
  console.log(e.action, e.record); // 'create', 'update', 'delete'
});

// Create a record
const post = await pb.collection('posts').create({
  title: 'Hello world',
  body: 'Content here',
  author: pb.authStore.model.id,
});

Appwrite

Appwrite is the most Firebase-equivalent open-source option. It offers: authentication (including 30+ OAuth2 providers), databases (document-style), file storage with image transformation, serverless functions in any language, real-time subscriptions, and team-based permission management. Deployed via Docker.

The feature breadth is Appwrite’s strength. Teams coming from Firebase find the mental model familiar — collections, documents, rules — but with the control of self-hosting. Appwrite’s SDKs cover iOS, Android, Flutter, React Native, and every major web framework. The developer experience has improved substantially in versions 1.4–1.6.

Where Appwrite shines: Multi-platform apps (web + mobile), projects that need team/organization permission hierarchies, teams familiar with Firebase’s data model that want self-hosted control. Appwrite Cloud (the managed service) is now stable enough for production use if you prefer not to operate Docker yourself.

Where it does not fit: Projects that need SQL — Appwrite’s databases are document-style, not relational. Heavy data querying with joins, aggregations, or complex filtering is harder to express than it would be in SQL or even Firestore’s query system. At that point, Supabase or a dedicated Postgres service is a better tool.

The Docker Compose setup for self-hosting:

# One-line setup
curl -sL https://appwrite.io/install/self-hosted | bash

# Sets up Appwrite with:
# - Web console at http://localhost
# - API at http://localhost/v1
# - MariaDB for metadata, Redis for caching, MinIO for storage

Convex

Convex is the most architecturally different of the three, and the most interesting for a specific class of problem.

The core idea: instead of building an API layer that your client queries, you write functions in TypeScript that run in Convex’s sandboxed environment. Those functions are split into queries (read-only, reactive) and mutations (write). When a mutation changes data, every client subscribed to a query that depends on that data gets an automatic update. No polling, no websocket management, no cache invalidation code.

// In Convex, a query function runs server-side and pushes to clients
// convex/tasks.ts
import { query, mutation } from './_generated/server';
import { v } from 'convex/values';

export const list = query({
  args: {},
  handler: async (ctx) => {
    return await ctx.db.query('tasks').order('desc').take(100);
  },
});

export const create = mutation({
  args: { text: v.string() },
  handler: async (ctx, { text }) => {
    await ctx.db.insert('tasks', { text, done: false });
  },
});

// In the React client, useQuery subscribes automatically
import { useQuery, useMutation } from 'convex/react';
import { api } from '../convex/_generated/api';

export function TaskList() {
  const tasks = useQuery(api.tasks.list); // auto-updates when data changes
  const createTask = useMutation(api.tasks.create);

  return (/* ... */);
}

Every component subscribed to api.tasks.list updates in real time without any manual synchronization code. This removes an entire class of bugs around stale client state.

Where Convex shines: Collaborative applications — documents where multiple users edit simultaneously, shared project boards, real-time dashboards, chat. Apps where keeping client state in sync with server state is the hard problem. Convex solves that problem at the framework level, which means application developers spend less time on synchronization logic and more time on product features.

Where it does not fit: Applications with heavy, complex queries (joins across many tables, complex aggregations) — Convex’s query model is built for reactive reads, not analytical workloads. Projects where TypeScript is not the primary language on the backend — Convex functions are TypeScript-only. And projects that need strict data portability without going through Convex’s export system.

Convex’s self-hosted backend launched in 2024 (open-source at github.com/get-convex/convex-backend), though the hosted cloud product remains more mature for production use.

How to choose

Factor	PocketBase	Appwrite	Convex
Data model	SQLite tables (schema-based)	Document collections	TypeScript-defined tables
Real-time	Yes	Yes	Yes, core feature
Self-hostable	Yes, one binary	Yes, Docker Compose	Yes (convex-backend), hosted recommended
Horizontal scaling	No (SQLite constraint)	Yes	Yes
Language requirements	Any client	Any client	TypeScript functions
Best use case	Simple apps, internal tools	Multi-platform apps, Firebase migration	Real-time collaborative apps
Ops complexity	Minimal	Moderate	Low (cloud) or Moderate (self-hosted)

The honest decision tree: if you need real-time collaboration as a core feature and TypeScript is your language, try Convex. If you need Firebase’s breadth of features but want self-hosted control, Appwrite. If you want the simplest possible backend deployment for a small-to-medium app, PocketBase.

For apps with genuinely complex relational data, none of these replace Neon’s serverless Postgres or Supabase — those are the right tools when SQL is the right model.

Production considerations

All three are open-source and actively maintained, but maturity differs:

Backup strategy: PocketBase’s SQLite database is a single file — trivially backed up with a cron job and a cloud storage bucket. Appwrite’s data spans MariaDB, MinIO, and Redis, which requires more orchestration. Convex’s hosted product handles backups; self-hosted requires managing the backup process for its own storage layer.

Monitoring: None of the three ships with observability out of the box. Add Prometheus metrics, structured logs, and uptime checks as you would for any self-hosted service.

Updates: PocketBase has an upgrade path that is as simple as replacing the binary. Appwrite’s Docker-based deployment upgrades more carefully — read the migration notes between major versions. Convex Cloud handles upgrades automatically; self-hosted upgrades require following the release process.

Small operational bets are worth taking when they meaningfully reduce the complexity budget for your project. Any of these three can run in production. The question is whether the trade-offs match what you are building.