Appwrite vs PocketBase

Last reviewed Aug 26, 2026 · 692 words

The cleanest way to separate these two is to count the apps you are going to build. PocketBase is one backend for one application: a single Go executable that carries its SQLite database, realtime API, auth and file storage, and serves an admin dashboard at /_/ on port 8090. Appwrite is a console for many: you create projects, invite team members, register platforms and API keys, and each project gets its own auth, databases, storage, functions and messaging. A solo developer with a side project will find Appwrite's structure ceremonial. A small studio shipping three client apps will find PocketBase's lack of it a problem by the second one. Both sit in the dev-platforms category, at opposite ends of it.

The 64 MB binary is not a toy

PocketBase's catalogue figures are 64 MB minimum RAM, Easy difficulty, MIT and 60,806 stars for a project first released in 2022 and still labelled pre-1.0. In practice that means ./pocketbase serve on a VPS in the $5-a-month class, a pb_data folder to back up, and a pb_migrations folder you can commit to git. Custom logic goes in Go (use it as a library) or in JavaScript hooks the binary runs itself, so "serverless functions" becomes "a file next to the binary." The two stated limits, SQLite and no horizontal scaling, are real; the question is whether you will ever reach them, and for a personal app, an internal tool or an MVP the answer is usually no. What pre-1.0 does mean is occasional breaking changes between minor versions, so read the release notes before every upgrade.

What 2 GB of Appwrite buys

Appwrite's install script writes a compose file and brings up MariaDB, Redis, Traefik and a row of workers; the catalogue's 2,048 MB and Medium describe that baseline, and its own con line warns it gets hungrier once function runtimes are enabled. For that you get official SDKs for Web, Flutter, Apple, Android and React Native alongside server SDKs, functions in a dozen languages, a messaging service for email, SMS and push, document-level permissions, a relationships attribute type and multi-project, multi-team organisation with a proper console. PocketBase's official client SDKs are JavaScript and Dart, with community ports covering the rest; if you write Swift or Kotlin for a living, Appwrite's first-party support is the difference between an afternoon and a week.

Operations and exits

A PocketBase upgrade is replacing one file and restarting. An Appwrite upgrade is a documented migration run across a stack of containers, fine on a laptop, not something you do from a phone. Backups follow the same shape: copy a directory, versus dump MariaDB and the storage volumes. Leaving is easier from PocketBase too; SQLite opens in any tool, whereas Appwrite's data lives in its own schema and comes out through its API or its backup tooling. Neither is Postgres; if that is what you actually want, PocketBase vs Supabase and Appwrite vs Supabase cover the heavier option from each side.

Decision table

What I'd do

Start every new project on PocketBase, and I mean that literally: the cost of being wrong is an afternoon, and most projects never outgrow it. Move to Appwrite on one of two triggers: a second product that needs its own auth and data but shares your infrastructure, or a mobile team that wants official SDKs and a console instead of a Go binary and a JSON API. If you already know at the first commit that you are building for a team of developers across several apps, skip the PocketBase phase and take Appwrite from the start.