PocketBase - SQLite Backend That Actually Works

PocketBase is a Go binary that gives you SQLite + auth + file storage + admin UI in one file. I've deployed this on 3 different client projects over the past year - a booking app, a small CRM, and some prototype that's still running in prod somehow.

Why It Exists

Traditional backends are a pain in the ass. You need PostgreSQL, Redis, an auth service, file storage, and probably 12 Docker containers just to store some user data. PocketBase throws all that complexity out the window - download one file, run it, done.

The latest stable version is v0.29.3 (released late 2024). It's still pre-1.0 software, so expect things to break between versions. Schema migrations bit me twice - once in March when they changed collection validation, again in August when they updated the auth system. Read the fucking changelog before upgrading.

What You Actually Get

SQLite That Doesn't Suck: Uses WAL mode so you can have multiple readers without blocking writes. Handles about 50-100 concurrent users before you hit the SQLite write bottleneck. If you need more, use PostgreSQL.

Auth That Works: Email/password, OAuth with Google/GitHub/etc. The OAuth setup is straightforward if you've done it before. First-timers will spend 2 hours reading Google's terrible OAuth docs.

File Uploads: Local storage works fine for prototypes. For production, you'll want S3 because local storage fills up fast. I learned this the hard way when a client's server ran out of space at like 2AM and their app died - users couldn't upload profile pics for 6 hours while I scrambled to configure S3.

Admin Dashboard: Actually decent, unlike most open source admin interfaces that look like they're from 2010. Real-time updates work well for monitoring your app.

Auto-Generated API: Creates REST endpoints for your collections. The filtering syntax takes some getting used to, but it's more flexible than most ORMs.

When to Use It

Perfect for:

• Side projects and prototypes
• Client work under 10k users
• Apps where you want full control over your data
• When you're tired of configuring Docker compose files

Don't use it for:

• Anything that needs to scale beyond SQLite's limits
• Mission-critical apps (it's still beta software)
• Complex analytics workloads

Self-Hosting Reality

Self-hosting seems free until you factor in monitoring, backups, security updates, and 3am outages. I run mine on a $10 DigitalOcean droplet with automated backups. Works fine, but you're the DBA now - which means when shit breaks at 2AM, you're the one fixing it while everyone else sleeps.

Oh also, set up monitoring from day one. I've had servers go down for hours because I forgot to check on them. Uptime Robot or similar will save your ass.

Installation Gotchas

Download the binary from GitHub releases, but here's what you'll actually hit:

Port Conflicts: You'll probably get a "port already in use" error on first run. Use ./pocketbase serve --http=127.0.0.1:8091 to fix it.

Permission Issues: On Linux/Mac, you'll definitely need chmod +x pocketbase or you'll get "permission denied" when trying to run it. Windows users just double-click and pray their antivirus doesn't quarantine it as malware (happens more often than you'd think).

Directory Structure: It creates:

• pb_data: Your SQLite database and uploaded files (backup this or cry later)
• pb_migrations: Schema change scripts (commit these to git)

First run opens a browser to create your admin account. If you're on a headless server, add --dev flag and access via IP:port.

Real Development Experience

The JavaScript SDK works fine, but CORS will bite you if you're developing on localhost. You'll waste 30 minutes wondering why your requests are failing before remembering to add your domain to the allowed origins in settings. Classic CORS bullshit.

// This works after you fix CORS
import PocketBase from 'pocketbase';
const pb = new PocketBase('http://127.0.0.1:8090');

// Auth actually works well
await pb.collection('users').authWithPassword('test@example.com', 'password');

SDK Reality Check:

• JavaScript SDK: Solid, good TypeScript support
• Dart SDK: Works but docs are thin
• Community SDKs: Use at your own risk, most are abandoned

Schema and Collection Pain Points

Collections are like database tables but easier to fuck up. I've made these mistakes so you don't have to:

Relation Fields: Many-to-many relations work but the UI gets confusing with more than 3 levels. Keep it simple or use JSON fields.

File Fields: Default 5MB limit. Increase it in settings or users will complain about upload failures. Also set proper MIME type validation or people will upload random shit.

Access Rules: The JavaScript-like syntax is powerful but debugging access rule failures sucks. Test everything in incognito mode.

Performance Reality

SQLite is fast enough for most stuff until it isn't:

• Under 1000 users: No problems
• 1000-10000 users: Monitor write bottlenecks
• Over 10000 users: Consider PostgreSQL migration

Real Bottlenecks I've Hit:

• File uploads slow down with 100+ concurrent users (learned this during a product demo, embarrassing)
• Complex queries with multiple joins get sluggish around 50k records
• Backup operations lock the database for like 30 seconds, users notice this shit

Scaling Workarounds:

• Use read replicas for reporting queries (requires custom setup)
• Cache expensive queries in Redis
• Move file storage to S3 early