Switching to PocketBase for single-file backend deployments

Escaping the per-operation trap

PocketBase provides the most predictable cost path for teams fleeing Firebase’s per-operation pricing. I found that for a production app with 10,000 daily active users and 10 million daily reads, Firebase costs between $500 and $1,500 per month, while Supabase stays closer to $50 to $100. Firebase Spark users face strict limits like 50,000 daily reads, 20,000 writes, and 1GB of file storage. In contrast, the Supabase Pro tier costs $25 per month and includes 100,000 monthly active users and 8GB of database storage. PocketBase removes this uncertainty because you only pay for your VPS, such as a $5 Hetzner instance. You replace the complex, multi-container Docker stacks of Supabase with one 15 MB executable file. This single binary includes your database, authentication, file storage, and an admin dashboard. You can migrate Firestore collections to PocketBase collections via JSON, but you must map schemaless documents to strict schemas.

One binary for the entire stack

The deployment workflow remains simple because you do not need to manage a separate database server or complex container orchestration. You upload the binary to a server and run ./pocketbase serve domain.com to initiate the process. This command manages your TLS certificates through Let’s Encrypt and starts the web server. I prefer this approach for MVPs and internal tools because you avoid the network latency found when services like Supabase run in separate containers. You replace Firebase Cloud Functions with JavaScript hooks or Go hooks that run inside the binary next to your data. These hooks do not incur invocation fees. This solves the problem of hot code paths driving up your monthly bill.

You can implement custom logic using a JavaScript VM plugin or write Go code to intercept application events. You use the Admin UI at localhost:8090 to manage your collections, users, and application settings. This single-binary design, written in the Go programming language, produces highly performant and self-contained binaries. SQLite in WAL mode provides fast reads, but I noticed it handles only one writer at a time. This serialization means high-concurrency write workloads struggle compared to the horizontal scaling available in PostgreSQL. Real-time subscriptions use Server-Sent Events to push updates to the frontend, providing a lightweight communication layer that avoids the complexity of WebSockets. Can a single-writer database truly support a massive, collaborative real-time editor for millions of users?

Team workflows and technical limits

PocketBase Cloud Organizations fix the workflow bottleneck where teams previously shared a single account to collaborate on projects. You create an organization, add teammates by email, and share specific projects without giving them full account access. Developers can change domains and settings, manage environment variables, and stream logs, but they cannot delete projects or the organization itself. Owners retain control over billing. Every resource created by a teammate bills to the project owner. Every resource records who actually created it, and the portal shows attribution, such as "Created by Anna," to ensure accountability. The removal of a project from an organization is non-destructive and does not touch anything that is already deployed. If you delete an organization, the projects inside it simply revert to the owner’s personal projects.

You should check if your current deployment scripts rely on absolute file paths before moving to a new environment. The transition from Firebase to PocketBase requires a clear plan for your users. Since Firebase Auth users do not export with reusable password hashes, you must trigger a password reset flow for your users after you migrate their data to the new backend. This step ensures they set new passwords against your PocketBase instance. You will also need to convert your Firestore Security Rules into PocketBase API rules, which use short filter expressions.