The risks of adopting PocketBase single-file backends

PocketBase uses a single Go binary and an embedded SQLite database to provide authentication, file storage, and a realtime API. This setup allows a $4 Hetzner CAX11 VPS with 2vCPU and 4GB RAM to handle 10,000 plus persistent realtime connections. I see developers gravitate toward this for MVPs and internal tools because they avoid the complexity of managing a fleet of machines or a multi-service Docker stack like Supabase or Appwrite.

The primary technical ceiling remains the SQLite single-writer design. While PocketBase uses WAL mode to allow readers to access the database while data is being written, it still cannot scale horizontally. If your application requires heavy write concurrency or needs to scale beyond a single server, you will hit a wall. Supabase provides horizontal scaling through read replicas and handles complex relational queries using PostgreSQL, whereas PocketBase keeps everything in one 20 MB file.

Security and maintenance realities

Relying on a personal open source project introduces specific stability risks. PocketBase is a personal project developed on a volunteer basis with no paid team or company behind it. The developer provides no promises for maintenance or support beyond what exists in the public discussions and roadmap. This differs from Supabase, which closed a Series F at a $10.5B valuation in June 2026 and supports 10 million developers.

Security vulnerabilities also present a direct risk to production apps. In May 2026, a vulnerability labeled CVE-2026-44166 showed that attackers could use an OAuth2 provider to link an unverified user to a victim’s email address, effectively hijacking accounts. While versions 0.22.42 and 0.37.4 fixed this issue, the incident demonstrates that users must track specific version updates to maintain security. If you plan to rely solely on an AI tool to manage your codebase without reading the documentation, you should not use PocketBase.

You should also consider the maintenance burden of self-hosting. PocketBase requires you to manage your own server, updates, and backups, which adds operational overhead compared to Firebase or the managed services of Elestio. If you need high-performance writes or complex joins, will the simplicity of a single binary outweigh the cost of a future migration?

Scaling and the write bottleneck

The performance of PocketBase depends heavily on vertical scaling. You can move from a $5/mo MVP setup to an enterprise configuration with 16 vCPU and 32GB RAM for $100 or more per month. This approach eliminates network latency between the API and the data, but it forces you to solve all concurrency problems on one machine. SQLite users often face issues with contention or deadlocks if they do not manage transactions effectively.

For many small to medium applications, the single-file model works. However, certain workloads demand more power.

If you need to handle a write-heavy collaborative tool with thousands of concurrent editors, PocketBase will fail where a PostgreSQL-based system succeeds. The project remains at version 0.36, meaning full backward compatibility is not guaranteed. For developers who want to avoid the unpredictable usage-based billing of Firebase, the fixed cost of a VPS is an attractive alternative. Stick with PocketBase if you prioritize zero infrastructure complexity and low costs for low-to-moderate traffic.