Firebase → PocketBase
What it saves, what actually moves, what you rebuild — and the thing that catches people.
What it costs, and what it saves
PocketBase is one Go binary with embedded SQLite — it runs on a $5 VPS. Against a $50–200/month Firebase bill for a small app, that is the whole saving.
Moves cleanly
Data, via JSON import. Auth users need re-registration or a password reset flow — PocketBase cannot import Firebase hashes.
You rebuild
All queries and rules, though PocketBase's API rules are simpler than Firestore's.
What Firebase costs you today
The Spark tier is free with hard quotas. Beyond it, Blaze is pay-as-you-go and metered on operations rather than seats: roughly $0.06 per 100,000 document reads, $0.18 per 100,000 writes and $0.02 per 100,000 deletes on Firestore, with Realtime Database around $5 per GB stored and $1 per GB downloaded. A modest app at 5,000 daily users lands near $12 a month. The number that surprises people is not the rate, it is the shape — a badly written listener that re-reads a collection on every render costs the same as a feature nobody asked for. Figures checked 2026-07-31.
What actually holds you in
High, and it is the query layer rather than the data. Exporting documents from Firestore is straightforward; rewriting every query, security rule and Cloud Function that assumed a document store is not. Firebase Authentication is the sharper hook — user records and password hashes are exportable, but any app depending on Firebase's client SDKs for session handling needs its auth flow rebuilt, not repointed. Teams that keep business logic out of Cloud Functions and behind their own API keep the exit affordable.
What you are moving to
PocketBase is a single Go binary containing an embedded SQLite database, authentication, file storage, realtime subscriptions and an admin UI. There is no Docker, no cluster, no dependency list — you download one executable, run it, and you have a backend. For a side project, an internal tool or an MVP it is the least ceremony available anywhere, and the fact that your entire production database is a file you can copy is a real feature rather than a limitation. MIT, about 60.4k stars. The honest constraint is SQLite: superb up to a point, and that point is a single machine.
Free and open source. You pay for a server, and a very small one will do.
PocketBase strengths
- One binary, no dependencies — the simplest deployment in this comparison
- Your whole database is a file you can copy, back up and version
- Extremely fast for read-heavy workloads on modest hardware
- MIT, no enterprise edition, no upsell path
What you give up
- SQLite means one machine — no horizontal scaling story
- Smaller feature surface than Firebase or Supabase
- Effectively a single-maintainer project, which is a real risk to weigh
- Not the right choice for an app expecting millions of concurrent users
The migration, step by step
- 1Confirm your scale honestly: PocketBase is SQLite on one machine, which is a real ceiling
- 2Export Firestore to JSON and define PocketBase collections with proper types
- 3Import via the admin UI or the API
- 4Rewrite client calls against the PocketBase SDK
- 5Plan the auth transition — a forced password reset is the usual answer and needs communicating
The gotcha
One machine, no horizontal scaling. That is fine for a side project or an internal tool and wrong for anything expecting real concurrency. Choosing PocketBase for an app that succeeds means migrating twice.
When to stay on Firebase
You expect meaningful growth, or you need offline sync.
Other ways off Firebase
More Layer 3 migrations
Figures verified 2026-07-31 against vendor pricing pages. Prices change and migrations differ by estate — treat the cost delta as a starting model, not a quote. Rankings and recommendations here are merit-only; affiliate income never changes a verdict. See our methodology.