When PocketBase fits a small app better than Firebase
PocketBase fits a small app when it runs at low scale on a single server that your team can operate, while Firebase fits teams that want Google to manage scaling and accept Google's hosting. If your concern is a renewal, a move off the Blaze plan, or a data residency question, the decision turns on four things: expected scale, whether your team can run and patch a server, whether authentication must stay in the EU, and how much tolerance you have for upgrades on a pre-1.0 product. Firebase Authentication processes data only in the United States, so an EU requirement that covers user records alone rules Firebase out regardless of where Firestore is located.
The licensing and support models differ in ways that matter to a buyer. PocketBase is licensed under the MIT License, and its FAQ describes it as a personal open-source project developed on a volunteer basis with no paid team or company behind it and no promise of support beyond what is available. Firebase is a managed service run by Google, with a commercial relationship and a contract behind it. For a regulated team, ask whether an internal owner will accept the maintenance risk of a volunteer project, and whether your change management process can absorb upgrades that may need manual migration steps from the changelog.
Scale is the constraint to test first. PocketBase uses embedded SQLite in WAL mode and scales only vertically on a single server, so a practical check is to load-test your expected peak of concurrent realtime connections and writes on hardware you can afford to lose and restore. Confirm your backup and restore procedure before go-live, since PocketBase's dashboard backups can be stored locally or in S3-compatible storage and the production guide warns that performance can degrade slightly during backups. If your forecast needs multiple application servers or database failover, plan for Supabase or Appwrite instead, and confirm their self-hosted topology with the vendor before you commit.
Which option fits which app scenario
This table matches common Firebase scenarios to the option that usually fits best, with the reason tied to a supplied fact. Read each row against your own traffic, data residency rules and team capacity, since the fit depends on those inputs more than on feature lists.
| Scenario | Better fit | Reason |
|---|---|---|
| Prototype or internal tool with a few users | PocketBase | A single executable with embedded SQLite, a dashboard and built-in auth can be running quickly on one server, with no separate database or container stack to operate. |
| Small consumer app on one server | PocketBase | Realtime subscriptions and auth run in one process, and the FAQ describes 10,000+ persistent realtime connections on a $4 Hetzner CAX11 VPS (source: PocketBase FAQ). |
| Growing app expecting heavy concurrent load | Supabase or Appwrite | PocketBase scales only vertically on a single server, so plan for a multi-service stack with a Postgres-backed option if horizontal growth is likely. |
| Team needing managed scaling and a hosted option | Firebase or a hosted edition | PocketBase is self-hosted only with no paid company behind it, so managed operations must come from your own team or a partner. |
| EU data residency requirement | Supabase or Appwrite in an EU data center | Firebase Authentication processes data only in the United States, while self-hosted options let you keep auth, data and files in one location you choose. |
| Team with no ops capacity | Firebase, or a supported hosted plan | PocketBase is developed on a volunteer basis with no promises of maintenance or support, so unplanned upgrades and outages fall to your team. |
| Apps relying on Cloud Storage for Firebase | PocketBase file fields with local or S3-compatible storage | Cloud Storage for Firebase requires the Blaze plan, while PocketBase stores files on local disk by default and can switch to S3-compatible storage. |
| Production system needing a stable upgrade path | Supabase or Appwrite, confirm versions first | PocketBase documentation says full backward compatibility is not guaranteed before v1.0.0 and it is not recommended for production critical applications yet. |
Where data lives and who controls it
Location decisions in a hosted backend are made early and are hard to reverse, so they belong in the evaluation before any code moves. The four cards below compare where Firebase fixes data and identity processing with where PocketBase puts the database, files and operational control on servers you choose.
Firebase Authentication stays in the United States
Firebase Authentication processes data only in the United States, even when Firestore uses a European location. For a team with an EU residency requirement, this splits identity records from application data before any evaluation of the rest of the stack begins. Ask your data protection lead whether user identifiers, emails and login metadata count as personal data under your policy, and document the answer before choosing a replacement.
Firestore location is fixed at provisioning
A Cloud Firestore database's location cannot be changed after it is provisioned. Teams that chose a location for latency and later need a different one must export, provision a new database and reload data, which is a migration project in its own right. Check which location your current database uses, then confirm which regions your self-hosted target and its backups will occupy.
PocketBase data sits in pb_data
PocketBase keeps its SQLite database and related state in a pb_data directory on the server where the executable runs. You choose the host, disk, region and operating system, so residency becomes a property of the machine you rent or own. Confirm the server's physical location, who holds administrative access to the host, and whether the directory is covered by your encryption and backup policy.
Files local by default, S3 optional
Uploaded files are stored in pb_data/storage on local disk unless you switch to S3-compatible storage in the dashboard's file storage settings. Local disk keeps files on the same host as the database, which simplifies residency but ties capacity and recovery to one machine. If you choose external storage, confirm the bucket's region, access policy and whether the provider's administrators can reach object contents.
PocketBase is self-hosted only
PocketBase has no hosted edition, so every compliance control that a provider would otherwise supply becomes your responsibility: patching, access logging, backup testing and incident response. The PocketBase FAQ describes it as a volunteer project with no paid company behind it, so there is no vendor to contract for assurance. DeployOpen can plan, implement and document these controls and prepare evidence, but independent auditors and certification bodies issue any assessment, and no certification is implied by the work.
What vertical-only scaling and pre-1.0 releases mean for operations
PocketBase scales only vertically, on a single server. Its FAQ says it uses embedded SQLite in WAL mode, has no plans to support other databases, and grows by adding CPU, memory and disk to one machine. The same FAQ reports that it can serve 10,000+ persistent realtime connections on a $4 Hetzner CAX11 VPS, which is a useful capacity signal but not a benchmark for your workload. Before choosing it, confirm your peak concurrent connections, write rate and data size against that model, and decide what you will do when a single host is no longer enough. Firebase has no equivalent ceiling you manage, so this is the trade you accept in exchange for a simpler stack.
The practical condition is that traffic is predictable and a single host with tested backups is acceptable. PocketBase's production guide recommends a systemd service and offers dashboard backups to local storage or S3-compatible storage, with a warning that performance can degrade slightly while a backup runs. Plan the backup schedule, restore drills and host replacement as recurring operational work owned by your team, since no vendor operates the server for you. Also confirm how you will handle the host's own patching, monitoring and disaster recovery, because PocketBase has no failover built in.
Pre-1.0 releases carry an explicit compatibility warning. PocketBase's documentation says full backward compatibility is not guaranteed before v1.0.0 and that it is not yet recommended for production-critical applications. Version v0.40.5 shipped on October 8, 2026, and the older 0.22 line received a backported Go security fix the same day, so you may need to maintain both lines during upgrades. Each upgrade may require manual migration steps from the changelog, so budget a staging test with a copy of production data before every release. Treat that test as a standing step in your change process, and record which version each environment runs.
What drives the cost of each option
Firebase bills by usage across several meters, while PocketBase is free to license but shifts cost onto servers, backups and the people who operate it. The cards below separate what you pay a vendor from what you pay your own staff, and what to request in a written quote before comparing totals.
Firestore reads and writes
Firestore bills per document read, write and delete, so cost follows how many times your app queries and how often it updates records. Chatty listeners and unindexed queries can multiply that count without any change in user numbers. On PocketBase, the equivalent work runs against a local SQLite file on hardware you already pay for. Ask your team to measure real operation counts from a staging workload before comparing bills.
Auth, storage and functions on Blaze
Cloud Storage for Firebase requires the pay-as-you-go Blaze plan, and Cloud Functions also needs Blaze, so these meters start once you leave the free tier. Authentication, storage volume and function invocations each carry their own line on the bill. PocketBase bundles auth, file fields and JavaScript hooks in one executable, so these costs become disk, bandwidth and admin time instead.
Hosting transfer and egress
Firebase Hosting and file downloads are billed by data transferred out, so a popular media-heavy app pays more as traffic grows. On PocketBase, transfer depends on the bandwidth contract of your VPS or data center provider, which is usually priced differently and often includes a fixed allowance. Ask your provider which transfer allowance and overage rate apply to the region you choose.
Server and storage for PocketBase
PocketBase has no paid tier, so its direct costs are the server, disk and any S3-compatible storage you attach from the dashboard. Because it scales only vertically on one server, you pay for a larger machine as load grows rather than adding nodes. Its FAQ cites a $4 Hetzner CAX11 VPS as an example of the hardware it can serve, but your own load test determines the size you need.
Backups and the one-time rewrite
PocketBase's dashboard backups can be stored locally or in S3-compatible storage, and you pay for that capacity and the retention you choose. Backups can slightly degrade performance while they run, so schedule them with that in mind. Moving from Firestore document collections to SQLite tables, rebuilding security rules and retesting clients is a one-time project whose effort depends on your data model and SDK usage.
The person who patches PocketBase
PocketBase is developed on a volunteer basis with no promises of maintenance or support beyond what is available, so no vendor sells you an SLA. Someone on your team or a retained partner must track releases, apply upgrades that may need manual migration steps, monitor the process and respond to incidents. This staff time is usually the largest recurring cost. Ask any implementation partner for a written scope covering upgrades, monitoring and response hours.
Who supports PocketBase when something breaks
PocketBase is a volunteer-developed project with intentionally limited scope, and its FAQ states that it is developed entirely on a volunteer basis with no paid team or company behind it. The project makes no promises of maintenance or support beyond what is available. Firebase, by contrast, is a Google-managed service that sits under Google Cloud's support plans. Before choosing PocketBase for a production app, the decision is about who answers at 2 a.m., not about feature parity. A named internal owner for the backend is the minimum, and that owner has to be able to diagnose SQLite, the Go executable and the systemd service without waiting for an upstream response.
The risk matters most for production apps with uptime obligations, such as payment flows, patient or customer records, or any app with contractual availability terms. PocketBase's own documentation says full backward compatibility is not guaranteed before v1.0.0 and that it is not recommended for production critical applications yet, so upgrades can require manual migration steps from the changelog. Security fixes also arrive on the project's own schedule. The releases page shows a backported Go security fix shipped to the older 0.22 line on the same day as v0.40.5, which means a team on an old line must watch for fixes and apply them deliberately. Confirm who reads the PocketBase releases page, who tests each upgrade against a copy of production data, and who owns the rollback plan.
Ask two questions before go-live. First, does your internal team hold on-call ownership for the PocketBase host, including OS patching, TLS renewal, backup restores and incident communication? Second, if you bring in an implementation partner, does the retainer explicitly cover patching, version upgrades, changelog review and security advisories, or only initial setup? Those scopes are set in writing, so ask for them in the statement of work rather than assuming them. If neither answer is clear, the project is not ready for a production workload on PocketBase, and a platform with a commercial vendor or an established support community may fit your requirements better.
How a move from Firebase to PocketBase unfolds
The sequence turns a Firebase project into a single PocketBase deployment with its data, users, files, access rules and server logic re-created by hand, because no Firebase importer is documented for PocketBase. Each step ends with a check so the team knows whether the move is ready for cutover.
Inventory Firestore, Auth, Storage and functions
The team lists every Firestore collection and its document shapes, every Auth provider and user, every Storage bucket and path, and every Cloud Function and trigger. Someone who knows the app owns this list, and it should be checked against the production project rather than memory. The output is a written inventory with record counts and a note on which parts the app still uses, so nothing is migrated by accident.
Redesign documents as SQLite collections
Firestore's NoSQL documents do not map one to one onto PocketBase collections in embedded SQLite. The team groups fields into typed collections, decides where relations and nested data go, and defines indexes for the queries the client already runs. The output is a collection schema reviewed by the backend and client leads, with each Firestore query traced to a PocketBase filter or index.
Rebuild security rules as access rules
Firebase security rules are rewritten as PocketBase collection access rules for list, view, create, update and delete. Each rule is tested with a user from every role the app defines, including unauthenticated and cross-tenant requests. The output is a test matrix showing which role can perform which action, and every rule that could not be expressed directly is listed for a server-side workaround.
Export Auth users and check hash compatibility
The team exports Auth users with the Firebase CLI, including password hashes and the scrypt parameters the CLI reports. It then confirms with the PocketBase auth model whether those hashes can be imported without forcing password resets, and documents the result per hash type. Users whose hashes cannot be carried over are identified in advance, and the output is a tested import of a sample set, with social provider links recorded separately.
Write custom transfer scripts for data and files
Because no Firebase importer is documented for PocketBase, the team writes its own scripts to read Firestore exports, transform documents into collection records and upload Storage files into PocketBase file fields. The scripts run first against a staging instance and their row counts and file checksums are compared with the source. The output is a repeatable script set and a reconciliation report showing zero unexplained differences.
Replace Cloud Functions with JavaScript hooks
Each Cloud Function is rewritten as a PocketBase JavaScript hook or as an endpoint in the JavaScript VM plugin included in the prebuilt executables. Triggers on record and auth events are mapped to the matching hook, and third-party calls are checked for secrets handling. The output is a list of every function with its replacement and a test run for each trigger.
Load test realtime subscriptions and storage
The team runs a load test against the staging instance that reproduces expected concurrent realtime subscriptions and file reads. Results are compared with the production Firebase usage patterns, and the team confirms that a single server meets the target, since PocketBase scales only vertically. The output is a written load test report with a decision on whether to stay on one server or to choose another backend.
Cut over and confirm backups
The team freezes writes on Firebase, runs the final data and user transfer, points the clients at PocketBase and verifies sign-in, reads, writes and file access on production. Dashboard backups are configured to local or S3-compatible storage, and a restore is tested on a separate host. The output is a signed cutover checklist and a documented rollback path, with Firebase kept read-only until the team is satisfied.
Questions buyers ask before switching from Firebase to PocketBase
How much effort does a small app migration from Firebase to PocketBase take?
Effort depends mainly on how much data, how many auth users and how much client code change the app needs, not on the PocketBase install itself, which is a single executable run with ./pocketbase serve. The main drivers are the data model change from Firestore documents to SQLite tables, the number of collections and security rules to rebuild as PocketBase access rules, and the realtime listeners that must be rewritten against PocketBase subscriptions. Ask any vendor for a written breakdown of these four items, and run a test migration on a copy of production data before committing to a date.
Can our own team do the migration without outside help?
A team with working knowledge of its app, its client SDK and basic database design can often do a small migration in-house, because PocketBase has a dashboard, a REST-style API and official JavaScript and Dart SDKs. The risk grows when the app depends on Firebase Auth hashes, Cloud Functions triggers or a large Firestore dataset, since those need careful testing. If the team has no spare capacity or no one who has rewritten a backend before, a fixed-scope engagement with written deliverables is a reasonable option to compare against an internal plan.
What skills and operational work does a self-hosted PocketBase need from us?
You need someone comfortable with SQL and schema design, because PocketBase stores data in embedded SQLite in WAL mode, and someone who can administer a Linux server. The PocketBase production guide recommends running it as a systemd service and notes that it has no official Docker image. Backups are the operational item most often under-planned: PocketBase offers dashboard backups stored locally or in S3-compatible storage, and it warns that performance can degrade slightly while a backup runs. Confirm your own restore procedure with a timed test, not just the backup schedule.
Can PocketBase replace Firestore and Cloud Functions one for one?
Not one for one. PocketBase replaces Firestore's document storage with SQLite collections and covers much of the auth, file and realtime surface, but it does not offer Firestore's NoSQL model, subcollections or Firebase's security rules language. Server-side logic moves to PocketBase's JavaScript hooks, which are available in the prebuilt executables, and the PocketBase README also describes running it as a Go framework. Map each Cloud Function trigger to a hook and test its behavior, since trigger timing and error handling will not match Firebase exactly.
How does realtime scaling work in PocketBase?
PocketBase's realtime subscriptions run inside the single process, and the PocketBase FAQ says it scales only vertically on one server. The same FAQ reports it can serve 10,000+ persistent realtime connections on a $4 Hetzner CAX11 VPS, which is a vendor-reported figure, so load test your own workload with your own message rates and client counts. If you expect growth beyond one machine, you will need a plan for a larger server, a database split or a different platform, and that decision should be made before cutover.
Does PocketBase keep our users' Firebase Auth password hashes?
Confirm this before you plan the cutover. Firebase Auth uses a modified scrypt algorithm by default, and the Firebase CLI exports hashes with their parameters, which is what allows users to sign in without a forced password reset on platforms that accept them. PocketBase's documentation covers its own auth management, but this FAQ-level research did not establish a documented Firebase importer or a supported path for importing Firebase scrypt hashes. Ask the PocketBase project directly or test an import with a sample user before you tell customers that passwords will carry over.
When should we choose Supabase or Appwrite instead of PocketBase?
Choose Supabase or Appwrite when you need a documented Firebase migration path, a multi-server or multi-region design, or a database with more than one replica. Supabase gives each project a Postgres database and documents scripts for Firestore data, Auth users and Storage files, and Appwrite's Migrations feature imports Firebase projects. Appwrite 2.0 provisions PostgreSQL by default, with MariaDB and MongoDB also supported, and its Helm chart docs say built-in datastores run a single replica without failover, so confirm the high-availability design you need. Both projects are community-supported when self-hosted, so a support contract or internal team still matters.
What MIT licensing and self-hosted-only means for a buyer
PocketBase is released under the MIT License, with copyright held by Gani Georgiev, according to the LICENSE file in the pocketbase/pocketbase repository. For a buyer, that means the software can be used, modified and redistributed without a per-seat, per-user or usage fee to the licensor. The cost of running PocketBase is the infrastructure, the time to operate it and the work to apply upgrades, not a license line item. PocketBase also has no hosted edition, and its FAQ states that it is self-hosted only, so there is no vendor-run plan to compare against. Firebase works differently: its usage-based Blaze billing, which covers Cloud Storage and Cloud Functions, is set by Google and changes with usage, and the bill arrives from the provider. Both models carry cost, but PocketBase moves more of it onto your own servers and staff.
The license does not replace support, security response or compliance work. The PocketBase FAQ describes the project as developed entirely on a volunteer basis, with no paid team or company behind it, and the documentation does not guarantee full backward compatibility before v1.0.0. Ask who on your side owns security patches, which release line you will track, and how you will test upgrades against the changelog. Your procurement and legal teams should confirm how the MIT terms apply to your own distribution and internal use, and should review any compliance evidence you will need for an assessment with qualified counsel and your assessors, because DeployOpen does not provide legal opinions or certifications.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Firebase vs PocketBase decision, we start by testing whether your app's scale, data and operating model fit a single-server backend before any migration work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory which Firebase services your app uses, including Firestore, Auth, Storage, Functions and Hosting.
- The written scope states whether PocketBase's single-server, vertical-only scaling fits your expected load and growth.
How we build
- We prototype the critical Firebase features in PocketBase, such as realtime subscriptions, auth flows and file uploads.
- We map Firestore collections to SQLite tables and rebuild access rules as PocketBase API rules.
- We test whether Firebase password hashes can be carried over, or whether users need a reset path.
How we hand over
- You receive documentation of the chosen architecture, data mapping, backup setup and PocketBase upgrade steps.
- We document pre-1.0 upgrade risks, including the manual migration steps listed in each release changelog.
- Runbooks cover systemd service setup, backups to local or S3-compatible storage, and restore testing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers.
- Support can cover tracking PocketBase releases and testing each upgrade in a staging copy before production.
- Where PocketBase's volunteer-maintained project no longer fits, we can scope a move to Supabase or Appwrite instead.
