Choosing between PocketBase, Supabase, and Firebase

PocketBase is a lightweight solution that is quick to set up and includes an intuitive GUI for non-technical collaborators. It works as a single-binary wonder that eliminates the need for separate database servers or containers. You can run a single command to start the server, making it an unmatched choice for speed-to-deploy in indie projects. PocketBase uses a 20 MB Go binary to handle authentication, file storage, and real-time subscriptions. I find that developers targeting MVPs or internal tools often prefer this single-file approach because they can run ./pocketbase serve to have an admin UI ready to use. This simplicity contrasts with Supabase, which requires managing at least six containers like PostgREST, GoTrue, Realtime, Storage, Kong, and the Studio dashboard when you self-host. Firebase remains the proprietary Google-backed alternative, using a NoSQL Firestore database that suits massive mobile workloads but lacks the relational power of PostgreSQL. While Supabase relies on PostgreSQL to provide complex JOINs and relational integrity, PocketBase uses SQLite in WAL mode, which allows for fast reads but limits the system to a single writer. I would skip PocketBase if your project needs to handle thousands of concurrent editors in a collaborative tool because SQLite cannot manage those high-write workloads. PocketBase remains stable in the sense that major bugs are fixed as they are identified, but you must prepare for manual migration steps because backward compatibility is not guaranteed. Developers extend the framework by writing Go or JavaScript hooks. Appwrite uses MariaDB behind a document-style API. It is useful for teams that want simplicity without learning SQL and targets users with 10K to 500K monthly active users. Its Flutter SDK is first-class, making it a strong contender for mobile developers.

Costs for these services deviate significantly as user counts climb from hundreds to millions. PocketBase runs on a $4 VPS, and a Hetzner CAX11 with 2 vCPUs and 4 GB RAM handles over 10,000 real-time connections. I think this predictability makes it the best choice for solo developers who want to avoid the "surprise bills" that often come with Firebase. Firebase uses a pay-as-you-go Blaze plan, where costs scale with read and write operations, and a single poorly optimized query can multiply expenses 100x. Firebase’s free tier includes 1GB of Firestore storage and 1GB of Cloud Storage, while Supabase’s free tier provides up to 500MB of database and 2GB of storage. Supabase’s Pro tier costs $25/mo and includes 8GB of database and 20GB of storage. Appwrite’s pricing is $25/month per project. For those seeking managed hosting without the complexity of manual Docker Compose setups, Elestio provides Supabase, Appwrite, and PocketBase starting at roughly $16/month.

You should choose Firebase if you need the Google ecosystem or if your data model is non-relational. Supabase is better if you need PostgreSQL or want to avoid vendor lock-in.

Migration from Supabase to PocketBase involves rebuilding your entire schema because PostgreSQL dependencies like views and complex functions do not exist in SQLite. If you rely on Row Level Security (RLS) in Supabase, you must rewrite those rules for PocketBase’s collection-based permission model. I prefer PocketBase for rapid prototyping where the priority is minimizing fixed expenses while you test product market fit. You can deploy PocketBase to Fly.io using a Dockerfile and a single volume for your pb_data directory to ensure persistence. If you need to scale horizontally to multiple instances, do you have a plan for handling SQLite’s single-writer constraint? You already know that scaling a single-node database becomes difficult once you hit high concurrency. When upgrading to version 23, you must delete existing local migration files and generate a new collections snapshot. This process requires you to manually update the deployed SQLite data.db file using a tool like sqlite3 to insert initialization migrations into the _migrations table. PocketBase version 0.37.4 added features like a backups list scroll container and updated OAuth2 providers for GitHub, GitLab, and Gitea. I would use Litestream if I needed to manage SQLite replication for backups. For file management, PocketBase allows for local storage or S3-compatible storage, but you must provide your own image transformation and CDN solutions. You can also authenticate with user-specific tokens generated from the admin. If you plan to migrate from PocketBase to Supabase later, structure your collections to avoid excessive nesting and keep authentication logic replaceable in the application layer.