PocketBase Review

PocketBase is an open-source backend with an embedded SQLite database, realtime subscriptions, built-in auth (email and password and OAuth), file storage, a superusers dashboard at /_/, and a REST-ish API at /api/. It can serve static files from a pb_public directory. Collections come in three types: Base for application data, View (read-only, populated by a custom SQL SELECT, and without realtime events), and Auth (a base collection plus email, verified, password, and token fields, with its own login and record endpoints). Field types include Bool, Number, Text, Email, URL, Editor, Date, Autodate, Select, File, Relation, JSON, and GeoPoint, and API rules are expressions such as @request.auth.role = staff or author = @request.auth.id, with nested and back-relation lookups. File fields store only file names in the database, with the files on local disk or S3. You can extend it with Go (as a framework) or JavaScript hooks: register custom routes, bind to hooks such as OnRecordCreateRequest, and add console commands, and the JavaScript VM mirrors the Go APIs so code can move to Go with few changes.

Download the prebuilt executable for Linux, Windows, or macOS on x64 or ARM64 and run ./pocketbase serve. On first run you create a superuser account through a browser link or from the command line, and the executable creates pb_data for application data and uploads and pb_migrations for JavaScript migration files you can commit to version control. The docs state plainly that PocketBase is still under active development and is not recommended for production-critical applications yet, that breaking changes may occur before v1.0.0, and that you should expect to read the changelog and apply manual migration steps. For production, the guide says pocketbase serve yourdomain.com gives automatic Let's Encrypt TLS (binding to ports 80 and 443 as a non-root user needs privileges such as setcap), a systemd service with Restart=always keeps it running (the example sets LimitNOFILE to 4096, and many realtime connections can trigger Too many open files), and a Docker image needs a volume mounted at /pb/pb_data. Reverse proxy examples for NGINX (client_max_body_size 10M and proxy_read_timeout 360s) and Caddy are provided, and you should configure user IP proxy headers. Backups are under Settings, Backups, stored locally or in an S3-compatible bucket, as ZIP snapshots of pb_data that can degrade performance while running, and for data sets of 5 GB or more the docs suggest a script combining sqlite3 .backup with rsync. Use a real SMTP provider instead of sendmail, enable the built-in rate limiter (v0.23.0 and later), restrict superuser access to specific IPs (v0.38.0 and later), enable MFA or OTP on the _superusers collection, set GOMEMLIMIT in constrained environments, and set a 32-character PB_ENCRYPTION_KEY to encrypt stored SMTP and S3 credentials. The pages we read do not cover minimum VPS specifications, SQLite tuning, or scaling guidance, and the latest version shown is v0.40.5.

You create collections in the dashboard, set access rules, and call the API or JavaScript SDK from your app, with realtime subscriptions for live updates. Because it is one process with one SQLite file, deployment and backups are conceptually simple. This section reflects the documentation and OpenAlternative; we did not run PocketBase.

• Single executable with embedded SQLite
• Email and password and OAuth authentication, with Auth collections
• Base, View, and Auth collections with rich field types and expression-based API rules
• File storage on local disk or S3 and realtime subscriptions
• Admin dashboard at /_/ and a REST-ish API at /api/
• JavaScript and Go extensibility, with versionable migrations
• Built-in rate limiting, backups, and superuser IP restrictions

• The simplest backend to deploy: one binary and one data directory, with automatic HTTPS
• MIT license and about 61,000 stars, with frequent releases
• A good fit for small apps, internal tools, and prototypes
• Extensible in Go or JavaScript without leaving the process, with a production guide that covers the basics

• The project says it is not yet recommended for production-critical apps
• Breaking changes may occur before v1.0.0, so upgrades require reading the changelog and sometimes migrating manually
• Single-process SQLite limits horizontal scaling, and the docs give no scaling guidance
• Backups are ZIP snapshots of pb_data that can slow the app, and large data sets need a custom script
• No managed cloud, and a smaller ecosystem and fewer features than Supabase or Firebase

PocketBase is free under the MIT license, and the pages we reviewed list no paid plans. The OpenAlternative page carries an affiliate VPS offer, which is not PocketBase pricing.

Firebase, Supabase, Appwrite, and Nhost are backend platforms with managed hosting and larger feature sets. PocketBase trades scale and breadth for radical simplicity: one file to deploy, with SQLite you can copy. Supabase (also reviewed here) is the stronger choice for Postgres, scaling, and managed hosting, while PocketBase wins for small apps and self-hosted prototypes.

• Solo developers and small teams that want a backend running in minutes
• Prototypes and internal tools
• Projects that benefit from extending the backend in Go or JavaScript

• Production-critical systems that cannot tolerate pre-1.0 breaking changes
• Apps that need horizontal scaling or a managed Postgres
• Teams that want a hosted, supported platform