PocketBase Over Supabase: The Indie Dev's Silent Win

The indie AI app economy is consolidating around a single, unglamorous truth: your backend choice will determine your runway more than your model selection ever will. PocketBase, the single-binary Go backend with built-in auth, realtime, and SQLite, isn’t winning on features. It’s winning on subtraction, one file, zero external dependencies, no hosted DB to bill. Supabase, by contrast, offers hosted Postgres with Edge Functions and a slick console. It removes ops labor. But it also adds a vendor, a billing surface, and a migration someday. The structural bear case for Supabase isn’t technical, it’s economic. Every external dependency is a future audit, a future lock-in negotiation, a future bill that triples overnight. PocketBase answers that with a binary you control. That trade-off, ops labor for vendor lock-in, is now the central axis of indie infrastructure.

The Deployment

PocketBase ships as a single executable file, a fully self-contained backend with realtime database, user authentication, file storage, and an admin dashboard. No separate database process, no cloud-hosted Postgres instance, no Docker orchestration. You download the binary, run it, and connect your frontend via a JavaScript SDK. The API surface is minimal: getList, getOne, create, delete, and subscribe for realtime updates. It uses SQLite under the hood, which means data lives in a single file on disk. For a solo developer shipping an AI tool in nights and weekends, this eliminates three vendors: a cloud DB provider, a secrets manager, and a backend hosting platform. The trade is clear: you accept SQLite’s scale limits in exchange for zero operational surface. There’s no “deployment” in the traditional sense, just binary execution. The live demo on the site runs locally, and the documentation assumes you’ll run it the same way.

Supabase, as the contrast, requires you to provision a hosted Postgres database. You get advanced SQL capabilities, row-level security, and Edge Functions written in Deno. But you also get a dashboard, a billing meter, and a dependency on Supabase’s uptime and pricing model. You’re not just choosing a database, you’re choosing a vendor relationship.

[[IMG: a solo developer in a home office reviewing PocketBase integration notes on a laptop, late-evening light through a window]]

Why It Matters

The category isn’t “backend as a service.” It’s “how much of your stack can you remove.” And on that metric, PocketBase is executing a quiet dethroning of the hosted-Postgres orthodoxy. The structural advantage of a single binary isn’t developer experience, it’s vendor concentration risk. Every time you add a third-party backend, you add:

• A new attack surface for breaches
• A new point of failure in uptime
• A new billing dispute
• A new migration project when pricing changes

Supabase doesn’t solve any of these, it optimizes for developer velocity at the cost of long-term autonomy. That’s a fine trade for internal tools or MVPs. But for a solo founder building a sustainable product, the cost compounds. Consider the audit pass: every external vendor requires compliance checks, SOC 2 prep, and contract reviews. PocketBase, as a self-hosted binary, collapses that into a single dependency you control. No API keys to rotate across vendors, no SLA negotiations, no surprise charges from data egress.

This mirrors the broader shift in indie infrastructure: from “cloud-native” to “cloud-avoidant.” Tools like TurboRepo, Bun, and Deno Deploy are all pushing toward fewer vendors, tighter control, and simpler stacks. PocketBase fits that wave perfectly. It’s not trying to beat Supabase on features, it’s making features irrelevant by redefining the unit economics of indie development. The cost isn’t compute or storage. It’s cognitive load, vendor management, and future migration debt.

The comparable isn’t even Supabase, it’s Vercel’s early pitch: “Just git push and it works.” But Vercel sold convenience at the cost of lock-in. PocketBase sells control at the cost of ops labor. For the solo dev, that’s the better bargain. Because the real cost of ops isn’t time, it’s the risk of being held hostage by a vendor when your app finally gains traction.

What Other Businesses Can Learn

If you’re a solo founder or small team building an AI app, your backend choice should be driven by one question: how much future work are you willing to inherit?

PocketBase forces you to run your own database process. You handle backups, scaling, and uptime. But you also eliminate entire categories of risk: no surprise billing spikes, no API deprecations, no vendor lock-in. You own the stack. For a 1–3 person team, that’s often worth the ops burden.

Supabase removes that burden, but in doing so, it becomes a permanent resident in your architecture. You’ll need to manage API keys, monitor usage meters, and plan for eventual data migration if you ever outgrow hosted Postgres or decide to self-host. And let’s be clear: every hosted Postgres provider eventually becomes a cost center. AWS RDS, Google Cloud SQL, and Supabase all follow the same pattern, low prices to hook you, then steady increases as your data grows.

The most critical dependency isn’t your AI model, it’s the data layer that feeds it.

For indie builders, the playbook should be:

1. Start with PocketBase if you can tolerate self-hosting. Use Fly.io, Render, or even a $5/month VPS. The binary is lightweight, and SQLite handles most use cases for early-stage apps.
2. Only adopt Supabase if you need advanced SQL or real-time joins. Otherwise, you’re paying for complexity you don’t need.
3. Version-pin your PocketBase binary. Treat it like any critical infrastructure component. Don’t auto-update, audit changes before deployment.
4. Assume every hosted service will raise prices by 100–300% within 18 months. Build your unit economics around that assumption.
5. Design your data model for eventual migration. Even with PocketBase, structure your records so they can be exported and reimported cleanly. This isn’t paranoia, it’s standard ops hygiene.

The real cost of a hosted backend isn’t the $25/month fee. It’s the 40-hour migration you’ll face when that fee jumps to $200 and your app can’t absorb it. PocketBase doesn’t eliminate that cost, it front-loads it. You pay in ops labor now to avoid vendor lock-in later. That’s the structural advantage.

[[IMG: a solo founder at a kitchen table reviewing database migration plans on a laptop, morning light through a window]]

Looking Ahead

Over the next 18 months, we’ll see a quiet exodus from hosted backends among indie builders who hit traction. The trigger won’t be technical, it’ll be a billing shock. When your Supabase invoice jumps from $50 to $500 because your AI app’s usage spiked, you’ll look for an exit. PocketBase will be the most viable off-ramp. It’s not because it’s faster or more scalable, it’s because it’s simpler, cheaper, and yours.

Watch Deno’s move into backend infrastructure as the parallel play. If Deno Deploy starts bundling a SQLite-backed backend similar to PocketBase, it could accelerate this shift. The endgame isn’t more tools, it’s fewer dependencies. And in that game, PocketBase isn’t just competitive. It’s setting the new standard.

Sources:

• PocketBase, accessed 2026-04-28