PocketBase

What it is

PocketBase is a complete backend packed into a single program you download and run. Inside are a database, user sign-up and login (including Google and other social logins), file uploads, live updates pushed to the browser, and a clean admin dashboard for creating tables and editing data.

The database is SQLite, which stores everything in ordinary files in a pb_data folder next to the program. That's why it's so light: no separate database server, no containers, nothing else to install.

It's free and MIT-licensed, written in Go, and built essentially by one developer, Gani Georgiev. It's been at version 0.x since 2022 and is now on 0.40.

What actually happens when you use it

1. Run it. Download, unzip, run ./pocketbase serve, and open the dashboard in your browser. You create an admin account on first launch.
2. Make collections. A collection is a table. You add fields in the dashboard, or have your agent write migration files that PocketBase applies on startup.
3. Set the API rules. Each collection has rules for who can list, view, create, update and delete records, for example limiting edits to the record's owner. New collections start locked to admins only, so nothing is public until you open it up. That's a safer starting point than Supabase, where tables made by an agent may start exposed.
4. Connect your front end. The JavaScript or Dart SDK handles logins, reading and writing records, and live subscriptions.
5. Extend it when you need to. Custom logic goes in JavaScript hook files, or you can use PocketBase as a Go library and compile your own version.
6. Deploy it. Upload the program to a small Linux server, point a domain at it, and it gets an HTTPS certificate on its own. The production guide covers backups, rate limiting, email and restricting admin access by IP.

What people like

• It runs a lot on very little. One developer runs five instances on a $10-a-month server, serving thousands of users a day with daily word games. Another has 21 tables, some over 300,000 records, and says searches are fast with proper indexes.
• One file versus a pile of containers. People comparing it with self-hosted Supabase like that it's one binary instead of 10+ containers. A Supabase user priced out of the $25 tier was told by others to try PocketBase.
• It's solid for internal tools. A team using it for many internal business apps called it bulletproof. Another runs a full CRM and ERP with 30+ tables on it.
• Upgrades have mostly been painless. A long-time user said only one release needed manual migration steps, and security fixes get backported to the older 0.22 line for people who haven't moved.
• The design is careful. The author of a competing project praised how polished its dashboard is, and one developer called it wonderfully designed.

What people run into

• It's not 1.0, and says so. The docs say it's not recommended for production-critical apps yet and that breaking changes can happen before 1.0. Plenty of people run it in production anyway and read the changelog before each update.
• It doesn't suit an AI-only workflow. The FAQ is blunt: if you'll rely solely on an AI tool without skimming the docs, "please do NOT use PocketBase!" Users report models don't know its current API and stay confused about how to use it. One fix that works: clone the repo and point your agent's AGENTS.md at it.
• One server, one database, forever. It scales only by getting a bigger server, and there are no plans to support Postgres or other databases. SQLite allows one write at a time, so apps with heavy, constant writing can struggle. One builder said it stopped coping past a few hundred tenants. Another hit 10 to 30 second page loads when staff kept reloading an admin page listing 5,000 orders.
• No built-in failover. If the server dies, the app is down until you bring it back. Some won't use it because a single machine isn't high availability, and others worry about losing recent data if the hardware fails. The FAQ suggests a tool called Litestream for continuous backups.
• It's a one-person project. Users worry about what happens if the developer steps away, and some describe his replies as rough. One user's feature request for a different database was deleted, and one user said their question was removed from GitHub discussions. He also declined a year of grant funding because he wasn't comfortable sending the personal paperwork the funder required. He's aiming for a stable release in 2026 with no hard promises.
• A few security fixes this year. In April a flaw let an attacker take over accounts through social login linking in some setups, and in July a bug could crash the whole server. Both were fixed, with backports for the older 0.22 line.

Before you install

• Ask whether you'll outgrow one server. Fine for most side projects, internal tools and small SaaS apps that mostly read. If you expect chat-style constant writes, many tenants, or need zero downtime, start with Postgres (Supabase or similar) instead.
• Give your agent the real docs. Point it at the docs for your version, or clone the repo next to your project. Ask it to write migrations and run ./pocketbase migrate up, as r/pocketbase users suggest, so your schema lives in git.
• Set up backups on day one. Use the built-in backups to S3-compatible storage, or Litestream. A backup stored only on the same server isn't really a backup.
• Open rules carefully. Check every collection's rules before launch. An empty rule means anyone, including logged-out visitors, can do that action.
• Pin and read before updating. Keep the version you tested, read the release notes, then update. Do update for security fixes.
• Follow the production checklist. Turn on rate limiting, set up real email (SMTP), and restrict admin logins to your IP, all from the going-to-production page.

The short version

PocketBase is the simplest way to own a real backend: one file, one cheap server, a lovely dashboard, and safe defaults. Compared with Supabase, you trade a managed service, Postgres and room to grow for simplicity and a tiny bill. That's a great deal for small apps if you'll read the docs and look after the server. If you want to never think about the backend, or you're relying entirely on an agent, a hosted service is the safer bet.