PocketBase: Single-File Backend Replaces Entire Stack

A developer downloads a single 15MB file. No Docker compose files. No cloud console logins. No Kubernetes manifests. They run one command, and instantly have a complete backend: SQLite database with real-time subscriptions, OAuth2 authentication, file storage with thumbnails, and an admin dashboard. This is PocketBase, and it’s challenging the assumption that modern backends require complex multi-service architectures.

The 15MB Backend Stack

PocketBase packages what normally takes eight different services into one Go binary. Download it, execute it, done. The embedded SQLite database handles schema management and data validation. Authentication supports email/password plus OAuth2 for Google, Facebook, GitHub, and GitLab. File storage works locally or with S3-compatible backends. Real-time subscriptions push database changes to clients. An admin UI provides visual collection editing and user management.

The performance numbers surprise developers accustomed to “SQLite doesn’t scale” conventional wisdom. A $6/month Hetzner VPS with 2 vCPUs and 4GB RAM serves 10,000+ concurrent persistent real-time connections. Memory footprint starts at 10MB. One production deployment handles 15,000 users on a 2GB Digital Ocean droplet.

Compare this to the typical setup: Amazon RDS for the database, S3 for files, Lambda for serverless functions, Cognito or Auth0 for authentication, plus real-time messaging services. Each needs configuration, monitoring, and its own failure mode. PocketBase collapses this complexity into something you can run on a Raspberry Pi.

The Production Paradox

The creator explicitly warns: “Still under active development, NOT recommended for production critical applications.” It’s a hobby project with no company backing, no dedicated support team, no SLA guarantees.

Yet 76% of developers in a GitHub poll consider it production-ready. Real companies run real applications on it. Flutter chat apps serve thousands of users. A Reddit-style community platform for retail investors runs on PocketBase. Internal tools handle payment webhooks and data validations.

For most applications, “production-ready” doesn’t require five-nines uptime or instant horizontal scaling to millions of users. It requires: doesn’t lose data, performs adequately under normal load, recovers from expected failures. By these standards, PocketBase delivers. The pre-v1.0 caveat matters mainly if you can’t tolerate occasional breaking changes requiring manual migration steps.

The cost difference amplifies this decision. Firebase and Supabase start cheap but scale expensively—$50 to $500+ monthly for moderate usage. PocketBase runs on a $6 VPS forever. When you’re bootstrapping a startup, $500/month versus $6/month isn’t a rounding error.

Backend Minimalism as Counterculture

PocketBase didn’t emerge in a vacuum. It’s the extreme endpoint of a broader industry shift away from microservices sprawl. Developers are experiencing complexity fatigue. The pendulum that swung toward “everything should be a separate service” is swinging back toward “maybe monoliths weren’t so bad.”

SQLite is having a renaissance. Cloudflare runs SQLite at the edge. Fly.io promotes SQLite for distributed applications. The database everyone dismissed as “just for mobile apps” turns out to scale further than assumed. PocketBase demonstrates SQLite handling 10,000 concurrent connections with real-time subscriptions—capabilities most developers thought required PostgreSQL or MySQL.

This challenges a core assumption: that sophisticated features require complex architecture. PocketBase proves you can have real-time subscriptions, OAuth2, file storage, and a REST API from a single binary. The simplicity isn’t sacrificing capability; it’s refusing unnecessary complexity.

When Simplicity Wins (and When It Doesn’t)

PocketBase isn’t for everyone. The SQLite foundation creates clear limitations. SQLite uses Write-Ahead Logging mode allowing only one writer at a time. Write-intensive applications—heavy logging, constant updates, high-frequency data ingestion—will hit this bottleneck. Read-heavy workloads perform excellently; write-heavy workloads struggle.

Horizontal scaling is impossible. SQLite is file-based. You can’t shard it across multiple servers or run a multi-node high-availability cluster. Scaling means moving to a bigger server (vertical), not adding more servers (horizontal).

High availability features don’t exist natively. No built-in replication. No automatic failover. You’re responsible for backups and disaster recovery. For internal tools and indie projects, this might be fine. For mission-critical production applications, it’s probably not.

Choose PocketBase for:

• Indie projects, side hustles, MVPs where cost control matters
• Internal company tools where self-hosting provides privacy/security
• Read-heavy applications with moderate concurrent users (under 10,000)
• Projects where you value data ownership over managed convenience

Avoid PocketBase for:

• Write-intensive applications (analytics platforms, logging systems)
• Requirements for 99.99% uptime SLAs and instant failover
• Horizontal scaling needs (can’t handle traffic on one server)
• Enterprise applications requiring vendor support contracts

The comparison to Firebase and Supabase clarifies the tradeoffs. Firebase provides battle-tested infrastructure and automatic scaling at the cost of vendor lock-in and unpredictable pricing. Supabase offers PostgreSQL scalability with complex queries and horizontal scaling via read replicas.

PocketBase occupies a different niche: maximum simplicity for 80% of projects that don’t need enterprise features. It’s the option for developers who want full control, minimal cost, and zero vendor lock-in, accepting vertical scaling limits and pre-v1.0 instability in exchange.

Getting Started in Three Commands

The deployment simplicity isn’t marketing hype:

wget https://github.com/pocketbase/pocketbase/releases/download/v0.34.0/pocketbase_0.34.0_linux_amd64.zip
unzip pocketbase_0.34.0_linux_amd64.zip
./pocketbase serve

Your backend is running at http://127.0.0.1:8090. The admin UI lets you create collections (database tables), define fields and validation rules, configure authentication providers, and set up access control. The auto-generated REST API handles CRUD operations. Real-time subscriptions work out of the box via WebSockets.

For production deployment, run it behind a reverse proxy (Nginx or Caddy), enable HTTPS, configure backups, and point a domain at it. That’s the entire infrastructure checklist. No Kubernetes operators. No service mesh. No cloud-specific configuration.

The GitHub repository shows active development with regular updates. The community discussions reveal real production usage and honest assessments of where it excels and where it struggles.

The Bigger Question

PocketBase forces a useful question: Do you actually need the complexity you’ve assumed is necessary? The multi-service, cloud-native, microservices architecture that’s become default might be overkill for your use case. Sometimes the right answer is a 15MB binary that runs on a $6 VPS.

This doesn’t mean PocketBase is always the answer. It means interrogating assumptions before accepting them. SQLite can scale further than you think. Self-hosting costs less than managed services suggest. Vertical scaling handles most realistic loads. Simplicity isn’t weakness; it’s often wisdom.

For developers building indie projects, internal tools, or MVPs where shipping quickly and cheaply matters, PocketBase offers an alternative path. Not the only path. Not the best path for everyone. But a path worth considering before defaulting to whatever everyone else uses.

The backend doesn’t need to be complicated. It just needs to work.