Appwrite vs PocketBase in 2026: Which Self-Hosted Backend?

TL;DR

Appwrite is a full-featured BaaS platform running across multiple Docker containers — the right choice for production applications that need serverless functions, team workspaces, and horizontal scaling. PocketBase is a single 5 MB Go binary — the right choice for side projects, MVPs, and internal tools where operational simplicity matters more than feature breadth. Both give you auth, database, storage, and real-time subscriptions out of the box.

Key Takeaways

Appwrite (BSD-3, 45K+ stars) has 14 function runtimes, 12+ language SDKs, and team management — a Firebase replacement for production apps
PocketBase (MIT, 41K+ stars) is a single binary with SQLite — deploy in 30 seconds on any server with 128 MB RAM
Appwrite requires 2–4 GB RAM and 10+ Docker containers; PocketBase needs 128 MB and zero configuration
Both provide auth (email/password + OAuth), file storage, real-time subscriptions, and a REST API
Appwrite's functions run in Docker containers (Node.js, Python, PHP, Ruby, Go, Swift, Dart); PocketBase extends via Go hooks
PocketBase is better for rapid prototyping; Appwrite is better for multi-developer production teams

The Fundamental Architecture Difference

The most important distinction between Appwrite and PocketBase isn't a feature list — it's the deployment model and the operational complexity that comes with it.

Appwrite is built as a distributed system from the ground up. The default Docker Compose file starts 11+ containers: API server, scheduler, worker, realtime server, executor (for functions), database, Redis, InfluxDB, Telegraf, and several others. This architecture is designed for horizontal scaling — add more worker containers for function execution, separate the realtime server onto a dedicated instance. But it also means Appwrite requires meaningful infrastructure to run and dedicated time to maintain.

PocketBase is built around a different philosophy: the entire backend is one binary. The executable contains the API server, the admin UI, the database engine (SQLite), and the file storage handler. Run it on a $3/month VPS and you have a fully functional backend. Restart it to upgrade. Copy the data directory to back up.

This architectural difference determines which use cases each tool fits.

Appwrite — Production BaaS Platform

Appwrite's strength is breadth and flexibility. The platform was designed to cover every need a production mobile or web application might have, with first-party SDKs for every major platform.

SDK coverage is where Appwrite genuinely stands out. Official client SDKs for Web (JavaScript/TypeScript), Flutter, iOS (Swift), Android (Kotlin/Java), React Native, Vue.js, and Node.js means your entire cross-platform product shares the same backend with platform-optimized SDKs.

// Web SDK
import { Client, Account, Databases } from "appwrite";
const client = new Client()
  .setEndpoint('https://appwrite.yourdomain.com/v1')
  .setProject('your-project-id');

const account = new Account(client);
const databases = new Databases(client);

// Create user
const session = await account.create(
  ID.unique(), 'user@example.com', 'password123', 'John Doe'
);

// Query database with permissions
const posts = await databases.listDocuments(
  'main-db', 'posts',
  [Query.equal('published', true), Query.limit(10)]
);

Appwrite Functions run serverless code in Docker containers. Write in Node.js, Python, PHP, Ruby, Go, Swift, Dart, or Deno. Functions trigger on HTTP requests, cron schedules, or database/storage events. The executor container handles cold starts, resource limits, and execution isolation.

// Appwrite Function (Node.js runtime)
export default async ({ req, res, log, error }) => {
  const { userId } = JSON.parse(req.body);

  // Access other Appwrite services from inside a function
  const { Client, Databases } = require('node-appwrite');
  const client = new Client()
    .setEndpoint(process.env.APPWRITE_ENDPOINT)
    .setProject(process.env.APPWRITE_PROJECT_ID)
    .setKey(process.env.APPWRITE_API_KEY);

  const databases = new Databases(client);
  const user = await databases.getDocument('users-db', 'profiles', userId);

  return res.json({ user });
};

Teams and permissions handle multi-user access control. Users belong to teams; permissions on databases and storage collections are granted to teams or individual users. This model fits B2B SaaS applications where each customer organization needs isolated data.

Key features:

14 function runtimes (Node.js, Python, PHP, Ruby, Dart, Swift, Go, Deno, Bun, and more)
12+ client SDKs
Document database with filtering and sorting
30+ OAuth providers
File storage with image transformation API
Realtime subscriptions (WebSocket)
Teams and permission management
Rate limiting and abuse protection
Email and SMS templates
Webhooks for all events

PocketBase — Fastest Path to a Working Backend

PocketBase's value proposition is radical simplicity. The entire backend ships as a single binary. No Docker, no PostgreSQL, no Redis, no nginx — just one file that you run.

# Complete PocketBase setup on a Linux VPS
wget https://github.com/pocketbase/pocketbase/releases/latest/download/pocketbase_linux_amd64.zip
unzip pocketbase_linux_amd64.zip
./pocketbase serve --http="0.0.0.0:8090"
# Admin UI at :8090/_/
# API at :8090/api/

That's the complete installation. The binary starts an HTTP server, creates a SQLite database, and serves the admin UI. You can define your data schema through the UI in minutes.

PocketBase's type system is more opinionated than Appwrite's document model. Collections have typed fields (text, number, boolean, date, email, URL, select, file, relation, JSON). The type system generates optimized SQLite queries and provides input validation automatically.

// PocketBase can be extended via Go hooks
package main

import (
    "log"
    "os"
    "github.com/pocketbase/pocketbase"
    "github.com/pocketbase/pocketbase/core"
)

func main() {
    app := pocketbase.New()

    // Intercept record creation
    app.OnRecordCreate("orders").Add(func(e *core.RecordEvent) error {
        // Custom logic: validate inventory, send notification, etc.
        log.Printf("New order from user: %s", e.Record.Get("user_id"))
        return e.Next()
    })

    // Schedule a recurring task
    app.Cron().MustAdd("daily-cleanup", "0 2 * * *", func() {
        // Clean up expired sessions or old data
    })

    if err := app.Start(); err != nil {
        log.Fatal(err)
        os.Exit(1)
    }
}

Realtime subscriptions work via SSE (Server-Sent Events). Client SDKs wrap the subscriptions with automatic reconnection. The SDK is available for JavaScript/TypeScript and Dart (Flutter), making PocketBase particularly well-suited for Flutter apps.

// PocketBase JavaScript SDK
import PocketBase from 'pocketbase';

const pb = new PocketBase('https://backend.yourdomain.com');

// Authenticate
const authData = await pb.collection('users').authWithPassword(
  'user@example.com', 'password'
);

// Real-time subscription
pb.collection('messages').subscribe('*', function(e) {
  console.log(e.action); // 'create', 'update', 'delete'
  console.log(e.record);
});

Key features:

Single binary (5 MB), zero dependencies
SQLite database (typed collections, migrations)
Auth with email/password and OAuth2
File storage (local or S3)
Realtime via SSE
Admin UI
JavaScript and Dart SDKs
Go hooks for custom logic
Auto-generated migrations
128 MB RAM

Detailed Comparison

Feature	Appwrite	PocketBase
License	BSD-3	MIT
Stars	45K+	41K+
Deployment	Docker (10+ containers)	Single binary
Database	MariaDB (document model)	SQLite (typed collections)
Auth methods	30+ OAuth + email	Email + limited OAuth
Serverless functions	✅ 14 runtimes	✅ Go hooks
SDK platforms	12+ (all major platforms)	JS, Dart
Real-time	WebSocket	SSE
Teams/orgs	✅	❌
Horizontal scaling	✅	❌
Min RAM	2–4 GB	128 MB
Setup time	10–20 minutes	30 seconds
Backup strategy	Database + storage exports	Copy single directory

Decision Framework

Choose Appwrite if:

You're building a production app with multiple platforms (web + iOS + Android)
Your backend logic requires serverless functions in various languages
You need team workspaces for B2B multi-tenancy
You expect to scale horizontally
You need 30+ OAuth providers or complex auth flows

Choose PocketBase if:

You're building a side project, MVP, or internal tool
You want the fastest possible time from idea to working backend
Server resources are limited
Your team doesn't want to manage Docker infrastructure
Your app is single-server scale (up to ~100K MAU on a decent VPS)

Performance Considerations

PocketBase's SQLite backend is faster than many expect. SQLite read performance on a modern SSD exceeds what most web applications actually need — benchmarks consistently show SQLite handling thousands of reads/second without breaking a sweat. The bottleneck for most applications is network latency, not database I/O.

Where SQLite struggles is concurrent writes. SQLite uses write-ahead logging (WAL) mode by default, which allows multiple concurrent readers with a single writer. For applications with high write concurrency (multiple users writing simultaneously), SQLite's write locking can become a bottleneck. PocketBase is not the right choice for applications with sustained high-write workloads.

Appwrite's MariaDB backend handles concurrent writes natively and scales better under write-heavy workloads. The trade-off is the operational complexity of running and maintaining a separate database server.

Cost Comparison

Scale	Firebase	Appwrite (self-hosted)	PocketBase (self-hosted)
1K MAU	~$0 (free tier)	$15–20/month (VPS)	$5/month (VPS)
10K MAU	~$100/month	$20–30/month	$5–10/month
100K MAU	$500+/month	$30–60/month	$10–20/month

Both self-hosted options have flat, predictable costs that don't scale with MAU.

Database Model Differences: Document vs Relational

The data model each tool uses shapes how you design your application schema, write queries, and think about relationships between data.

Appwrite's database is built around a document model with an important constraint: it stores documents in collections with defined attribute schemas, enforced at the API level. Unlike pure document databases (MongoDB) where you can insert any arbitrary structure, Appwrite requires you to define your collection's schema ahead of time — field names, types, and validation rules. This hybrid approach (document flexibility with schema validation) means your data is type-safe but doesn't require SQL migrations in the traditional sense. Relationships between collections are expressed using document references (storing a document ID from another collection as an attribute), not foreign keys. Joins and relational queries happen at the application layer by fetching related documents via the SDK.

The practical implication is that Appwrite's query model is limited compared to relational databases. You can filter by attribute values, sort, paginate, and do basic comparisons. You cannot write complex JOIN queries, subqueries, or window functions. If your application requires complex reporting or analytics queries across related data, Appwrite's query capabilities may require significant application-layer workarounds.

PocketBase uses SQLite with a relational schema. Collections are SQL tables. Relationships use actual foreign keys. PocketBase's query API exposes a subset of SQL-like filtering and expansion syntax — you can expand related records (equivalent to a JOIN) in a single API call using the expand parameter. The underlying SQLite means you can also access the database directly with standard SQL tools if you need complex queries. For applications that grew beyond PocketBase's API query capabilities, direct SQLite access via the embedded database is a valid escape hatch. This relational foundation is more powerful for complex data relationships and analytics than Appwrite's document model.

The choice between models is ultimately about application type. Content-heavy applications with heterogeneous data structures (variable attributes per document) benefit from Appwrite's flexible document schema. Business applications with well-defined relationships (users have orders, orders have line items, line items have products) benefit from PocketBase's relational model. For a broader look at self-hosted backend alternatives including Supabase, see Best Open Source Alternatives to Supabase 2026.

Migration Between PocketBase and Appwrite

Application requirements evolve, and the tool that was right for an MVP may not be right at production scale. Understanding the migration path between PocketBase and Appwrite (in both directions) helps inform the initial tool choice.

Migrating from PocketBase to Appwrite typically happens when an application outgrows single-server scale. The data migration involves exporting PocketBase collections as JSON (using PocketBase's export API) and importing into Appwrite collections via the Appwrite Admin API. Schema translation is manual — you recreate each PocketBase collection as an Appwrite collection with equivalent attributes. The main challenge is relationship handling: PocketBase's relational expand queries need to be rewritten as separate API calls in Appwrite, since Appwrite doesn't support the same expand syntax. File/storage migration copies uploaded files from PocketBase's pb_data/storage directory to Appwrite's storage via the Files API. Authentication migration exports users and recreates them in Appwrite with temporary passwords and a forced password reset flow.

Migrating from Appwrite to PocketBase is less common but follows the reverse pattern. The conceptual challenge is mapping Appwrite's document collections to PocketBase's relational tables. If your Appwrite collections have document-style flexible schemas (different attributes per document), you need to normalize them into consistent table structures. For complex migrations involving Firebase (a common Appwrite adoption path), see How to Migrate from Firebase to Appwrite 2026, which covers data export formats and SDK migration patterns that apply to general BaaS migrations.

See open source alternatives to Appwrite on OSSAlt.

Appwrite vs PocketBase in 2026: Which Backend?