Originally published on 2026-02-03
Original article (Japanese): Supabaseのコストが気になったらPocketBase: $4 VPSで動くBaaSの選択基準
Supabase is an excellent BaaS centered around PostgreSQL, offering "most of the features you might want." However, during the early stages of product development or when creating an MVP, you might be concerned about costs due to reasons like "wanting to minimize fixed expenses" or "uncertainty in resource usage." Related articles can be found under baas and supabase.
I adopted PocketBase for job queue management in my explanation video generator. The reason was simple: the requirements weren't too complex, and I wanted to minimize operational costs.
In this article, I will not just casually recommend PocketBase as an "alternative to Supabase," but rather outline the conditions under which you should choose PocketBase (and those under which you should not). Both are excellent services, and the best choice depends on your requirements.
Understanding Supabase's Cost Structure
Cloud Pricing (Free / Pro / Team)
The pricing for Supabase Cloud is summarized on Supabase Pricing.
- Free: Sufficient for initial testing. However, you will eventually hit walls regarding "production stability," "limits," and "support."
- Pro: Typically starts at $25/month (this becomes a fixed cost per project).
- Team: Focused on organizational requirements such as team operations, permissions, and auditing.
The key point here is not that "Supabase is expensive," but that fixed costs arise because it takes care of the troublesome aspects of cloud operations (like DB management, backups, monitoring, updates, etc.).
The Reality of Self-Hosting (Complexity and Required Resources)
While Supabase can be self-hosted, the realistic costs become apparent when you actually run it.
- The setup is not simple: The supabase/supabase Docker Compose has many components, and you need to understand and maintain the entire system.
- Required resources are significant: "4GB+ RAM recommended" and "10+ container setup" are the minimum requirements (this varies with project size and workload).
- Costs do not end with just the VPS: The "labor costs" for backups, monitoring, upgrades, and incident response gradually add up.
In other words, you might find yourself in a situation where "monthly costs have decreased, but operational responsibilities have increased." Whether you can accept this is a critical decision point.
The PocketBase Option
PocketBase is a lightweight BaaS that runs as a single binary. The data store is SQLite, and it integrates authentication, storage, and real-time subscriptions.
Key features (only the highlights):
- A single binary (approximately 12MB according to the official site) makes deployment easy.
- Lightweight operations with SQLite (WAL mode).
- Fast to get "up and running" with integrated authentication and file storage.
- Can be extended with Go/JavaScript, but lacks a managed execution environment like Cloud Functions.
Note that PocketBase is currently below version 1.0. Additionally, horizontal scaling (increasing the number of instances of the same app) is not a premise. This limitation directly relates to the "unsuitable cases" discussed later.
Feature Comparison
Let's outline the features of both services. The goal is to understand "what each can and cannot do," rather than determining which is superior.
Database
| Feature | Supabase | PocketBase |
|---|---|---|
| DB Engine | PostgreSQL | SQLite (WAL mode) |
| SQL Queries | Full SQL support | Limited (filter syntax) |
| JOIN / Views / Functions | ○ | × |
| Transactions | Fully ACID compliant | Single writer constraint |
| Extensions (pgvector, etc.) | ○ | × |
| Schema Management | Migrations + GUI | Collection definitions + GUI |
Supabase is "PostgreSQL itself," allowing for complex queries and extensions. PocketBase is SQLite-based, specializing in simple CRUD operations.
Authentication
| Feature | Supabase | PocketBase |
|---|---|---|
| Email/Password | ○ | ○ |
| OAuth (Google, GitHub, etc.) | ○ (many supported) | ○ (15+ providers) |
| Magic Links | ○ | ○ |
| Phone Authentication (SMS) | ○ | × |
| MFA (Multi-Factor Authentication) | ○ | × |
| SAML / SSO | ○ (Team tier and above) | × |
| Row Level Security | ○ (PostgreSQL RLS) | ○ (collection rules) |
Both services offer basic authentication features. If you need enterprise-level features (MFA, SAML), Supabase is the only option.
Storage
| Feature | Supabase | PocketBase |
|---|---|---|
| File Upload | ○ | ○ |
| Access Control | RLS-based | Collection rules |
| Image Transformation (resizing, etc.) | ○ | × |
| CDN | ○ (Smart CDN) | × |
| Maximum File Size | 500GB (Pro) | Depends on settings |
Supabase has robust storage capabilities. PocketBase can "store files," but you need to provide your own image transformation and CDN solutions.
Real-Time
| Feature | Supabase | PocketBase |
|---|---|---|
| DB Change Subscriptions | ○ (Postgres Changes) | ○ (collection subscriptions) |
| Broadcast (arbitrary data distribution) | ○ | × |
| Presence (online status) | ○ | × |
| Concurrent Connections (estimate) | Depends on plan | 10,000+ ($4 VPS) |
Both services support DB change subscriptions for real-time functionality. Supabase also includes Broadcast/Presence features for chat and collaboration.
Server-Side Logic
| Feature | Supabase | PocketBase |
|---|---|---|
| Edge Functions | ○ (Deno) | × |
| DB Triggers / Functions | ○ (PostgreSQL) | × |
| Custom Hooks | × | ○ (Go / JS) |
| Extension Method | Managed Functions | Embedded in binary |
This highlights the difference in design philosophy. Supabase provides a "managed function execution environment," while PocketBase takes an approach of "extending as a framework." When writing custom logic in PocketBase, you need to implement hooks in Go/JS and rebuild the binary.
Operations and Management
| Feature | Supabase | PocketBase |
|---|---|---|
| Management Dashboard | ○ (feature-rich) | ○ (simple) |
| CLI | ○ | ○ |
| Backups | Automatic (Pro and above) | Manual or Litestream |
| Logs / Monitoring | ○ (Log Drain support) | Basic logs only |
| Migrations | ○ (supabase db push) | ○ (pb_migrations) |
Supabase provides comprehensive operational tools. PocketBase prioritizes "simple operation," requiring you to build your own monitoring and backup solutions.
Cost Comparison (Rough Estimate)
Assumption: Here, we envision the minimum fixed costs for running in production. Actual costs will vary significantly based on traffic, data volume, and operational setup.
| Option | Estimated Monthly Cost | Operational Cost (Effort) | When It Works Best |
|---|---|---|---|
| Supabase Cloud Pro | $25+ | Low (managed) | Want to avoid DB management, designed with PostgreSQL in mind |
| Supabase Self-hosted | VPS $20+ (example) + ancillary costs | High (self-managed) | Want to reduce cloud fixed costs but can handle operations |
| PocketBase | VPS $4+ | Low to Medium (single-node operation) | Want to minimize fixed costs with simple requirements |
The statement "PocketBase runs on a $4 VPS" is close to the context in the PocketBase FAQ (single-node operation, expected connection numbers). Specifically, it is said that the Hetzner CAX11 (2vCPU, 4GB RAM) can handle 10,000+ real-time connections. Connection numbers and performance depend on the environment, so treat these figures as estimates.
Conditions for Choosing PocketBase
✅ Suitable Cases
- Individual Development / MVP: Can accept minimizing fixed costs with the understanding that you may migrate later if successful.
- Internal Tools: Not overly strict on concurrent connections or SLAs, focused on CRUD.
- Simple CRUD: No need for complex SQL, advanced RLS (Row Level Security), or multi-step transactions.
- Can operate on a single node: Acceptable if "one node goes down, we can recover."
The point is not just "because it's cheap," but rather "if the requirements are simple, you can keep costs low without introducing unnecessary complexity."
❌ Unsuitable Cases
- Horizontal scaling is essential: Need to handle multiple instances from the start, requiring HA (high availability).
- Dependence on PostgreSQL features: Requires complex JOINs, views, functions, extensions, or strict transaction designs.
- Enterprise requirements: Strong needs for auditing, permissions, SLO/SLA, organizational operations, and compliance.
- High update workloads demanding strong data integrity: SQLite's characteristics (single writer, etc.) can complicate design.
Example: Reasons for Adoption in the Explanation Video Generator
In the explanation video generator, PocketBase is used solely for "job queue management."
Here's what I aimed to achieve:
- Create jobs (queued)
- Workers take jobs and process them (processing)
- Update progress/results (completed / failed)
- The UI needs to track state changes in real-time
This can certainly be achieved with Supabase as well. However, in my case, the priority was "managing the queue simply" rather than "using the DB intelligently," as long as the UI could follow along.
Reasons for adoption:
- For job queue management alone, SQLite + a single node was sufficient.
- Wanted real-time updates for the UI (PocketBase's subscriptions sufficed).
- Wanted to keep fixed costs low (VPS $4+ was realistic).
- Fewer dependent components resulted in a lower psychological maintenance burden.
Architecture (roughly):
flowchart LR
U[User] --> W[Web UI]
W -->|Create job| API[App API]
API --> PB[(PocketBase
SQLite)]
Worker[Worker] -->|Fetch queued jobs| PB
Worker -->|Update status/progress| PB
PB -->|Realtime subscription| W
Worker --> Gen[Video generation
LLM/TTS/Render]
Gen --> Store[(Object Storage
or local files)]
Worker -->|Store result URL| PB
In this configuration, PocketBase can focus on being the "single source of job state" and "UI update notifier." Conversely, the moment this hits scaling requirements is when you should consider migration.
The Realities of Migration
Supabase → PocketBase
In reality, migrating is closer to "rebuilding" than just "moving."
- A schema based on PostgreSQL (complex normalization, views, functions, etc.) will need redesigning.
- If you heavily utilize RLS, you'll need to restructure according to PocketBase's permission model.
- If your token design is based on Supabase Auth, client-side modifications will also be necessary.
PocketBase → Supabase
Migration is possible when you grow. Since the tasks are clear, it’s reassuring to keep the "exit" in mind from the start.
- Structure PocketBase collections in a way that they can later be easily migrated to PostgreSQL (avoid excessive nesting, stabilize ID design).
- Direct files to external storage from the beginning (to reduce migration pain).
- Consider SQLite replication for backups using Litestream.
- Keep authentication logic "replaceable" and centralized in the application layer.
While PocketBase is strong for "starting small," it is not designed to handle long-term scaling strategies entirely, so it's safe to plan with that in mind.
Conclusion
- PocketBase is not a "replacement for Supabase," but rather "another option."
- If cost is a priority and requirements are simple (suitable for a single node), PocketBase fits well.
- For scaling, PostgreSQL features, and organizational requirements, Supabase is stronger.
- Both are good, so it's most effective to articulate your requirements (availability, operational setup, SQL dependency) before making a choice.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.