PocketBase

Open-source backend infrastructure, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source (MIT) backend in a single portable executable — embedded SQLite database with realtime subscriptions, user authentication, file storage, and an admin dashboard, all in one binary [1][4].
• Who it’s for: Solo founders, indie hackers, and small teams building web or mobile apps who want a Firebase-style backend without usage-based billing, vendor lock-in, or a DevOps team [1][5].
• Cost savings: Firebase’s Blaze pay-as-you-go plan charges per read/write/storage/egress — costs that compound fast at scale. PocketBase self-hosted runs on a $5–10/mo VPS with no per-operation charges [2][4].
• Key strength: It’s a single binary. Download it, run ./pocketbase serve, and you have a working backend with an API, admin UI, and realtime subscriptions. No Docker Compose required, no database server to configure separately [1][4].
• Key weakness: SQLite is the only supported database — no PostgreSQL, no MySQL. The project explicitly says it is not recommended for production-critical applications yet, as full backward compatibility isn’t guaranteed before v1.0.0 [docs][1].

---

What is PocketBase

PocketBase is an open source Go backend that ships as a single binary file. Inside that file: an embedded SQLite database running in WAL mode, a REST-ish API auto-generated from your collection definitions, built-in user authentication (email/password, OAuth2), file storage with local or S3-compatible backends, realtime WebSocket subscriptions, and an admin dashboard UI [1][4][README].

The GitHub description is accurate and unambiguous: “Open Source realtime backend in 1 file.” That’s the pitch. You download a ~12MB binary for your platform, run it, and it generates an installer link to set up your superuser account. The server starts at http://127.0.0.1:8090 — the admin dashboard at /_/, the API at /api/ [docs].

What makes it architecturally interesting is that it’s also usable as a Go framework. You import github.com/pocketbase/pocketbase, write your custom business logic, register routes or event hooks, and compile everything into a single custom binary. This means you’re not locked into the default behavior — you can extend it as deeply as you need without forking the project [README].

The project was created by Gani Georgiev and sits at 57,626 GitHub stars with 3,288 forks as of this review [3]. It has been in active development since July 2022. The current stable version is v0.36.7.

---

Why people choose it over Firebase, Supabase, and Appwrite

The reviews converge on the same set of reasons.

The single-binary argument. Every review mentions this, and it’s genuinely unusual at this abstraction level. TechBeta [4] puts it plainly: “Deploy by copying a single binary to your server.” Better Stack [1] calls it a “lightweight alternative to Firebase/Supabase.” Product Hunt reviewers specifically highlight the “frictionless” setup — makers of Sidenote note smooth scaling, makers of Taim call authentication “effortless,” makers of wanderer cite “fast start plus flexible hooks” [5]. The consistent theme is that the setup friction is an order of magnitude lower than alternatives that require Docker stacks, external databases, and migration tooling.

Versus Firebase. Firebase is the obvious comparison because PocketBase replicates its core feature set — realtime database, auth, storage, hosted dashboard — but inverts the economic model. Firebase charges per read, per write, per stored gigabyte, and per gigabyte of egress. Those costs start free and scale invisibly until your bill is $200/mo for a moderately active app. PocketBase on a $6 Hetzner VPS is flat. Better Stack [1] notes this directly: “Self-hosting on cheap VPSs lets developers avoid high managed cloud costs while keeping full control.”

Versus Supabase. Supabase gives you PostgreSQL and more enterprise-grade tooling, but the self-hosted version is a Docker Compose stack of 8+ services, it’s substantially more resource-intensive, and the free cloud tier has pausing behavior that’s bitten many projects. PocketBase trades raw SQL power and Postgres compatibility for operational simplicity. If you need PostgreSQL, PocketBase is the wrong tool. If you need a working relational database with an API and don’t have a reason to reach for Postgres specifically, PocketBase is faster to ship with [1][3].

Versus Appwrite. Appwrite is also open-source, also targets the Firebase replacement slot, and also self-hostable. The difference is the same as Supabase: Appwrite is a Docker Compose stack with multiple services. PocketBase is one binary. For developers who want an ops-free backend, that difference is the whole ballgame.

Product Hunt reviews specifically note that PocketBase “made authentication and data handling effortless” for founders building MVPs and side projects, and flag “frictionless auth, realtime features, one-file deployment, and reliable performance for small-to-mid workloads” as consistent themes [5].

---

Features

Based on the README, official docs, and third-party reviews:

Core backend:

• Embedded SQLite database in WAL mode — no external DB required [README][1]
• REST-ish API auto-generated from collection definitions — filter, sort, paginate, expand relations without custom code [4][docs]
• Realtime subscriptions via WebSocket — subscribe to any record or collection and receive live updates [README][4]
• Collection rules engine — per-collection access control with flexible rule expressions controlling read/create/update/delete [4]
• Admin dashboard UI — visual collection management, record editing, user management, settings [README][4]

Authentication:

• Email/password with verification and password reset [4]
• OAuth2 providers: Google, GitHub, Facebook, and others [4]
• Custom authentication flows [4]

File storage:

• Built-in file handling with automatic thumbnail generation for images [4]
• Local storage by default; configurable S3-compatible backends [4]

Extensibility:

• Extend with JavaScript hooks — script behavior without recompiling [README]
• Embed as a Go framework — full customization, custom routes, event hooks, compiled into a single binary [README]
• Official JavaScript/TypeScript SDK (pocketbase/js-sdk) for Browser, Node.js, React Native [README]
• Official Dart SDK (pocketbase/dart-sdk) for Web, Mobile, Desktop, CLI [README]

Operations:

• Built-in backup and restore [4]
• JS migration files for collection changes — can be committed to version control [docs]
• Single binary with no runtime dependencies [README]

What’s not in the box:

• No built-in job queues or background task schedulers beyond what you write via hooks
• No multi-tenancy support out of the box
• No horizontal scaling — SQLite means single-node by design [1]

---

Pricing: SaaS vs self-hosted math

Firebase (the direct comparison): Firebase’s Spark plan is free with hard limits: 1GB Firestore storage, 10GB/month bandwidth, 50K reads and 20K writes per day. Cross those limits and you’re on Blaze (pay-as-you-go). Blaze pricing: $0.06 per 100K reads, $0.18 per 100K writes, $0.108/GB storage, $0.12/GB egress. An app with 500K reads/day blows $90/mo just on reads before touching storage or bandwidth. Data not available for precise real-world median Firebase bills, but the pricing structure is public and the compounding is real.

Supabase for comparison: Free tier is limited to 500MB database, 1GB file storage, 2GB bandwidth. Pro is $25/mo for 8GB database, 100GB storage. Enterprise is custom.

PocketBase self-hosted:

• Software: $0 (MIT license)
• VPS minimum: Hetzner CAX11 at €3.79/mo (ARM, 2 vCPU, 4GB RAM) or equivalent
• Bandwidth: typically included in VPS pricing
• Your time to set up: 20–45 minutes

Hostinger’s PocketBase-specific hosting starts at $6.49/mo for 4GB RAM / 50GB NVMe / 4TB bandwidth [2]. That’s the practical floor for a managed VPS option if you don’t want to configure Nginx yourself.

Concrete savings for a typical indie project:

An app with 200 daily active users making ~1,000 Firestore reads and 200 writes per user per day: roughly 200K reads/day = $4.38/day = $131/mo on Firebase Blaze, before storage or file bandwidth. Self-hosted PocketBase on a $6 VPS: $6/mo. Annual difference: roughly $1,500/year.

That math assumes you’re comfortable with a Linux server. If you’re not, factor in a one-time deployment fee or a few hours of YouTube tutorials.

---

Deployment reality check

This is where PocketBase genuinely earns its reputation.

Minimum viable deployment:

1. Download the ~12MB binary for your platform
2. Run ./pocketbase serve
3. Open the generated installer URL to create your superuser account
4. You have a working backend

That’s it for local development. For a production VPS, you add: a reverse proxy (Nginx or Caddy for HTTPS), a systemd service file to keep it running, and optionally a cron job for the built-in backup command [docs].

No Docker required. This is unusual and meaningful. Appwrite, Supabase self-hosted, and most comparable tools ship Docker Compose stacks. PocketBase runs as a plain process. For developers who find Docker a learning cliff, this matters.

What can go sideways:

The biggest risk is the SQLite single-node constraint. Better Stack [1] is explicit: “Not ideal for large-scale apps — better for side projects, indie apps, or internal tools.” SQLite in WAL mode handles concurrent reads well, but concurrent writes are serialized. If you expect thousands of simultaneous writes per second, PocketBase is the wrong architecture. The project itself says so [docs].

The second risk is the pre-v1.0.0 status. The official docs state: “PocketBase is NOT recommended for production critical applications yet, unless you are fine with reading the changelog and applying some manual migration steps from time to time” [docs]. This is honest self-assessment, not a red flag per se — the project is actively maintained and v0.36.7 is stable for its stated use cases — but it means you should read the changelog before updating and not use it where downtime is catastrophic.

Resource requirements:

• RAM: 256MB–512MB for a small app; scales with SQLite WAL buffer and file caching
• Disk: however much your data grows; SQLite database is a single .db file
• CPU: minimal — Go is efficient, SQLite is embedded

Realistic setup time for a developer: 20–30 minutes for a working HTTPS-enabled instance on a fresh VPS. For a non-technical founder with no server experience: 2–4 hours including domain configuration and reverse proxy setup, or pay someone once to set it up.

---

Pros and Cons

Pros

• Single binary deployment. Nothing in this category ships as one file. No Docker, no external database server, no dependency management. Copy the binary, run it, done [README][4][5].
• MIT license. Genuinely permissive — self-host, embed in your product, resell, build a SaaS on top of it. No commercial licensing hurdles [3][README].
• Zero per-operation pricing. Unlike Firebase, you never get a surprise bill because your app went viral or because a bug caused a read loop. The cost is the VPS, period [1][4].
• Realtime out of the box. WebSocket subscriptions to collections and records without additional infrastructure — no Redis, no Pusher, no extra service [README][4].
• Extensible without forking. JavaScript hooks for non-Go developers; Go framework mode for engineers who want full control [README][4].
• Official SDKs for JavaScript/TypeScript and Dart — first-class mobile and web support [README].
• Built-in admin dashboard. Non-technical co-founders or content editors can manage data without touching code or SQL [README][4].
• Automatic API generation. Define a collection schema, get a filterable, sortable, paginated REST API instantly — no controller code to write [4][docs].

Cons

• SQLite only — no PostgreSQL. This is a deliberate architectural choice and the project confirms there are no plans to support other databases [1][docs]. If your use case requires Postgres (full-text search at scale, PostGIS, advanced JSON operations, row-level security at the DB level), PocketBase is not for you.
• Not recommended for production-critical apps yet. The project itself says this in its docs [docs]. Pre-v1.0.0 means occasional manual migration steps. Fine for side projects; risky for revenue-critical infrastructure.
• No horizontal scaling. SQLite is single-node. You can scale vertically (bigger VPS) but not horizontally (multiple nodes). If you need multi-region or failover clustering, look elsewhere [1].
• Smaller ecosystem than Firebase/Supabase. Fewer tutorials, fewer Stack Overflow answers, fewer third-party integrations compared to mature platforms. Community is active but smaller [3].
• No built-in job queues. Background tasks and scheduled jobs require custom hooks or an external cron setup. Not a dealbreaker, but Firebase and Supabase both have managed cloud functions [docs].
• Admin UI is functional, not polished. It’s built to configure things, not for content-heavy editorial workflows. If your non-technical team needs a CMS-quality editing experience, Directus or Payload are better fits.

---

Who should use this / who shouldn’t

Use PocketBase if:

• You’re a solo founder or small team building a web or mobile app with moderate traffic expectations.
• You want a Firebase-style backend without Firebase pricing or vendor lock-in.
• You’re comfortable with basic Linux server management, or willing to pay someone to deploy it once.
• Your data model fits a relational schema and you don’t need PostgreSQL specifically.
• You want realtime features (live-updating UIs, collaborative editing) without running a separate WebSocket server.
• You’re building an MVP and need to ship fast without provisioning infrastructure.

Skip it (use Supabase instead) if:

• You need PostgreSQL — its JSON operators, PostGIS, pg_vector, logical replication, row-level security at the database level.
• Your team already knows SQL and wants full database access, not just an API layer.
• You need managed cloud hosting with a generous free tier and don’t want to manage servers at all.

Skip it (use Firebase instead) if:

• Your compliance team won’t approve self-hosted infrastructure.
• You have no technical person to maintain a VPS.
• Your app needs Google-scale infrastructure guarantees.

Skip it (use Directus or Payload instead) if:

• Your primary use case is content management for a marketing team or editorial workflow.
• You need fine-grained role-based content permissions, localization, or a polished non-technical editor UI.

Skip it (look at Appwrite) if:

• You want the Firebase-replacement feature set but need PostgreSQL compatibility or a larger open-source community with corporate backing.

---

Alternatives worth considering

• Supabase — open-source Firebase alternative built on PostgreSQL. More powerful, more complex to self-host (Docker Compose with 8+ services), has a managed cloud tier. The default choice when you need Postgres [1][3].
• Appwrite — also open-source, also single-platform backend, also self-hostable via Docker Compose. More services and features than PocketBase, more moving parts. Good alternative if you need more than SQLite.
• Firebase — the incumbent. Managed, Google-backed, global CDN, generous free tier. Closed source. Costs compound fast past the free tier.
• Directus — open-source headless CMS and backend. Better editorial UI, supports any SQL database, more complex to set up. Right choice if content management is the primary use case.
• Payload CMS — TypeScript-native headless CMS with a strong developer experience. More code-first than PocketBase’s no-code admin.
• Nhost — managed PocketBase-alternative with GraphQL and Hasura, built on Postgres. Fully managed hosting option.
• TrailBase — newer project in the same slot as PocketBase, listed as a popular alternative on AlternativeTo [3]. Worth watching but less mature.

For the non-technical founder replacing Firebase: the realistic shortlist is PocketBase vs Supabase. Pick PocketBase if you want a single binary and operational simplicity. Pick Supabase if you need PostgreSQL or a managed cloud tier.

---

Bottom line

PocketBase is the fastest path from “I need a backend” to “I have a working backend” in the self-hosted space. A single 12MB binary that runs anywhere, costs nothing to license, and eliminates the per-read/per-write billing spiral that makes Firebase painful at any meaningful scale. The trade-offs are real and worth naming honestly: SQLite means no horizontal scaling and no PostgreSQL, the pre-v1.0.0 status means occasional migration friction, and the ecosystem is smaller than the established platforms. For the use cases it’s designed for — solo founders, indie apps, internal tools, MVPs — those constraints rarely bite. For anything expecting serious write concurrency or requiring Postgres-specific features, they bite immediately.

If the VPS setup is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients. One-time fee, done, you own the infrastructure.

---

Sources

1. Better Stack — “What is PocketBase? Features, Limitations, and Use Cases”. https://betterstack.com/community/guides/database-platforms/pocketbase-backend/
2. Hostinger — “PocketBase VPS hosting | Simple, self-contained app hosting”. https://www.hostinger.com/vps/pocketbase-hosting
3. AlternativeTo — “PocketBase – Open Source realtime backend in 1 file”. https://alternativeto.net/software/pocketbase/about/
4. TechBeta — “PocketBase”. https://techbeta.org/software/pocketbase/
5. Product Hunt — “PocketBase – Open Source realtime backend in 1 file”. https://www.producthunt.com/products/pocketbase

Primary sources:

• GitHub repository and README: https://github.com/pocketbase/pocketbase (57,626 stars, MIT license)
• Official website: https://pocketbase.io
• Official documentation: https://pocketbase.io/docs