Scaling the solo backend without breaking the bank

I watch Firebase bills climb every time a developer implements an inefficient query. If you use the Blaze plan for Firestore, you pay $0.03 per 100,000 reads in the Iowa region. A single poorly optimized query that fetches 1,000 documents for 1,000 users costs money for every single read. Firebase also requires the Blaze plan for Cloud Storage usage since February 3, 2026. Firebase costs can spike fast. The Blaze plan bills per document read, write, and delete. If you forget to add a limit to a query, you might trigger millions of reads. A single user refreshing a page ten times can multiply your costs ten times over. You pay for what you use, and that usage can be unpredictable.

PocketBase avoids these per-request charges. You pay only for your VPS. A $5 Hetzner or DigitalOcean droplet handles tens of thousands of users for a flat monthly fee. PocketBase is free.

Supabase provides a middle ground. The Pro plan costs $25 per month and covers 8GB of database space and 100,000 monthly active users. This $25 fee includes $10 of compute credit for a Micro instance. If your project grows, you pay $0.09 per GB of egress beyond the 250GB limit. Supabase bills for resources like storage and bandwidth.

Database engines and the cost of migration

The choice of database engine changes your long-term freedom. PocketBase uses SQLite, which works well for read-heavy apps but hits a wall with high-concurrency writes because of the single-writer limitation. I find the simplicity of a single Go binary with a 30MB footprint refreshing for MVPs. PocketBase version 0.39.0 released in late May 2026.

Supabase uses PostgreSQL, which gives you relational power and Row Level Security. If you decide to move, you can run a standard Postgres dump to migrate your data. Firebase makes leaving difficult. You must export data into proprietary formats, and Google charges one document read for every document you export. If you build a product that grows from a few hundred users to a million, the decision to use a proprietary NoSQL store like Firestore instead of an open-source Postgres-based platform like Supabase will cost you weeks of refactoring.

I would skip Firebase if you want to avoid vendor lock-in.

How much time will you spend managing Docker containers for a self-hosted Supabase stack?

Supabase requires about 10 containers to run via Docker Compose. PocketBase requires nothing but a single command.

PocketBase uses a custom filter syntax for access rules per collection. This works well for simple "users can only see their own records" rules. Supabase uses Row Level Security in Postgres, which is more powerful for complex multi-tenant logic. PocketBase allows customization through Go hooks. Supabase uses Deno for Edge Functions.

The verdict for solo developers

Solo developers must choose based on their ambition. You already know that managing infrastructure is a real cost.

If you want to build an internal tool or a small side project with minimal overhead, PocketBase is the winner. You manage one file and one binary. It is perfect for hackathons or prototypes. PocketBase uses SSE for real-time subscriptions.

If you need a professional foundation that scales into a real SaaS, Supabase is the safer bet. The combination of PostgreSQL, Row Level Security, and managed hosting removes the operational burden of a multi-service stack. For most web and mobile apps with relational data, Supabase is the best choice.

Firebase remains a candidate only if you are already deep in the Google Cloud ecosystem or building a mobile app that requires specialized offline-first sync.

PocketBase stays cheap.
Supabase scales well.
Firebase remains the expensive choice.

Firebase remains the choice for mobile-first apps requiring offline-first sync and tight Google Cloud integration.