Firebase has long been the default choice for developers who want a ready-made backend: authentication, real-time databases, file storage, and cloud functions, all behind a single SDK. But Firebase comes with vendor lock-in, unpredictable pricing at scale, and data residency constraints that many organizations cannot accept.
In 2026, the self-hosted Backend-as-a-Service (BaaS) landscape has matured enough that you can replicate — and in many cases exceed — Firebase’s feature set while keeping full control of your data, your infrastructure, and your budget.
Why Self-Host Your Backend-as-a-Service
Running your own BaaS platform solves problems that hosted services create:
Data sovereignty. Your user data, files, and credentials never leave your servers. This is mandatory for healthcare (HIPAA), finance (PCI DSS, GDPR), and government workloads where third-party data processing is legally restricted.
Cost predictability. Firebase’s pay-as-you-go pricing can spiral when your app hits scale. Reading 10 million documents per day or storing terabytes of files adds up fast. Self-hosted platforms run on fixed infrastructure costs — a $20/month VPS can handle thousands of users.
No vendor lock-in. When your backend runs on open-source software with standard protocols (PostgreSQL, REST APIs, WebSockets), you can migrate, fork, or extend it freely. You are not tied to a proprietary SDK or cloud ecosystem.
Customization. Need a custom authentication flow, a specialized database index, or a webhook that talks to your internal systems? Self-hosted platforms let you modify every layer.
Offline and air-gapped deployments. Some environments simply cannot reach the public internet. Self-hosted BaaS platforms work in isolated networks, on-premises data centers, and edge locations.
Three Contenders
The self-hosted BaaS space has three dominant players, each with a different philosophy:
| Feature | PocketBase | Appwrite | Supabase |
|---|---|---|---|
| Language | Go (embedded) | Node.js / docker | PostgreSQL ecosystem |
| Database | SQLite (embedded) | MariaDB / MariaDB Galera | PostgreSQL |
| Architecture | Single binary | Microservices (10+ containers) | Managed PostgreSQL + edge functions |
| Authentication | Built-in (email, OAuth2, SAML) | Built-in (email, phone, OAuth2, SAML, magic URL) | Built-in (email, phone, OAuth2, SAML, magic URL, MFA) |
| Real-time | Server-Sent Events | Realtime subscriptions | PostgreSQL replication + WebSockets |
| Storage | Local disk / S3 | Appwrite Storage / S3 | Supabase Storage / S3 |
| Server-side logic | JavaScript hooks (embedded) | Cloud Functions (Deno) | Edge Functions (Deno) + Postgres functions |
| Admin UI | Built-in single-page app | Built-in comprehensive console | Built-in dashboard + Table editor |
| Self-hosted difficulty | Trivial | Moderate | Moderate |
| Minimum RAM | 64 MB | 2 GB | 2 GB |
| GitHub Stars | 43k+ | 45k+ | 70k+ |
| License | MIT | BSD-3-Clause | Apache 2.0 |
PocketBase: The Minimalist
PocketBase is a single Go binary that bundles SQLite, a real-time subscription engine, an admin dashboard, and a file storage system. You download one file, run it, and you have a complete backend.
It is ideal for small to medium projects, internal tools, prototyping, and anyone who values simplicity over horizontal scale. The embedded SQLite database handles tens of thousands of concurrent users when configured correctly.
Appwrite: The Full-Featured Platform
Appwrite is a Docker-based platform with 10+ microservices: API gateway, database, storage, users, functions, messaging, and more. It provides the broadest feature set of the three, including teams, project-level isolation, GraphQL support, and a comprehensive audit log.
It is the closest direct replacement for Firebase’s feature parity and is suited for production applications that need enterprise-grade tooling.
Supabase: The PostgreSQL Powerhouse
Supabase is built on top of PostgreSQL and leverages the database itself as the backend engine. Row-Level Security (RLS) policies control access, triggers power real-time events, and PostgREST auto-generates a REST API from your schema.
If you already know PostgreSQL, Supabase has the shallowest learning curve. The database is your API, and your API is the database.
Installation and Setup
PocketBase — Single Binary
PocketBase is the easiest to deploy. Download the binary and run:
| |
Create a systemd service for production:
| |
| |
Access the admin panel at http://your-server:8080/_/ and create your first admin account.
For prcaddyion with HTTPS behind Caddy:
| |
Appwrite — Docker Compose
Appwrite ships as a multi-container Docker setup. The official installation script handles everything:
| |
Or use Docker Compose manually:
| |
After deployment, access the Appwrite console at http://your-server:80 and complete the setup wizard. The first run initializes the database schema and creates the admin account.
Supabase — Docker Compose
Supabase provides an official Docker Compose setup via the supabase CLI:
| |
For a standalone Docker Compose deployment without the CLI:
| |
The Supabase stack is more complex because each component is a separate service. The Kong API gateway routes requests, GoTrue handles authentication, PostgREST auto-generates the REST API from your Postgres schema, Realtime listens to database changes via PostgreSQL replication, and Storage manages file uploads.
Authentication Deep Dive
Authentication is the most critical feature of any BaaS platform. Here is how the three compare:
| Auth Feature | PocketBase | Appwrite | Supabase |
|---|---|---|---|
| Email/Password | Yes | Yes | Yes |
| OAuth2 (Google, GitHub, etc.) | Yes (10+ providers) | Yes (15+ providers) | Yes (20+ providers) |
| Phone/SMS | No (requires hook) | Yes (Twilio, TextLocal, MSG91) | Yes (Twilio, MessageBird) |
| Magic Links | Yes | Yes | Yes |
| SAML/SSO | Yes (paid plans in cloud) | Yes (self-hosted) | Yes (enterprise in cloud) |
| Multi-factor Auth (MFA) | Via hook | Built-in (TOTP) | Built-in (TOTP, SMS) |
| Anonymous Auth | Yes | Yes | Yes |
| JWT Custom Claims | Yes | Yes (via functions) | Yes (via Postgres triggers) |
| Session Management | Built-in | Built-in with device tracking | Built-in with refresh tokens |
| Password Reset | Built-in email | Built-in email + phone | Built-in email |
All three support email confirmation, password reset flows, and OAuth2 out of the box. Appwrite and Supabase have more identity providers and native SMS support. PocketBase can integrate any OAuth2 provider through its extensible auth hooks.
Database and API
PocketBase
PocketBase uses SQLite with a built-in ORM and a reactive REST API. You define collections (tables) through the admin UI or via JavaScript migrations:
| |
The listRule, viewRule, createRule, updateRule, and deleteRule fields provide declarative, row-level access control. Every request is evaluated against these rules before data is returned.
API usage:
| |
Appwrite
Appwrite provides a REST API, GraphQL API, and official SDKs for web, Flutter, React Native, and server-side languages. Databases are organized into databases → collections → documents:
| |
Appwrite’s permission model uses role strings (role:all, user:{userId}, team:{teamId}) that can be attached at the document level for fine-grained access control.
Supabase
Supabase exposes your PostgreSQL schema as a REST API through PostgREST. You define tables with standard SQL, and the API appears automatically:
| |
API usage:
| |
The advantage of Supabase’s approach is that you get the full power of PostgreSQL: complex joins, full-text search, geospatial queries (via PostGIS), materialized views, and stored procedures.
Real-Time Subscriptions
All three platforms support real-time data synchronization:
PocketBase uses Server-Sent Events (SSE) through a simple subscribe endpoint:
| |
Appwrite uses WebSocket-based channels:
| |
Supabase listens directly to PostgreSQL replication events:
| |
Supabase’s approach is unique because it reads from PostgreSQL’s Write-Ahead Log (WAL), meaning real-time events fire for any database change — even those made through direct SQL, psql, or other database clients.
Server-Side Functions
When client-side logic is not enough, all three platforms offer server-side execution:
PocketBase — JavaScript Hooks
PocketBase runs embedded JavaScript hooks inside the same process:
| |
Appwrite — Cloud Functions
Appwrite deploys functions as isolated Docker containers:
| |
Functions are triggered by HTTP requests, scheduled cron jobs, or database events. Appwrite supports Deno, Node.js, Python, PHP, Ruby, Go, Dart, C#, Kotlin, Swift, and Bun runtimes.
Supabase — Edge Functions
Supabase runs Deno-based edge functions:
| |
Deploy with:
| |
Performance and Scalability
The architectural differences between these platforms produce very different scaling characteristics:
| Metric | PocketBase | Appwrite | Supabase |
|---|---|---|---|
| Cold start | Instant (single binary) | ~15 seconds (Docker compose) | ~30 seconds (full stack) |
| Read throughput | ~10k req/s (single node) | ~5k req/s (single node) | ~8k req/s (single node) |
| Write throughput | Limited by SQLite WAL | Good (MariaDB cluster) | Excellent (PostgreSQL) |
| Horizontal scaling | Read replicas only | Full microservice scaling | PostgreSQL read replicas + connection pooling |
| Max concurrent connections | ~10k (SQLite) | ~5k (per node) | ~200 (without PgBouncer), unlimited (with PgBouncer) |
| Memory footprint | ~30 MB idle | ~800 MB idle | ~600 MB idle |
PocketBase is the most resource-efficient by a large margin. A Raspberry Pi can run PocketBase for a small project. Appwrite and Supabase need a minimum of 2 GB RAM and benefit from multi-core servers.
For horizontal scaling, Supabase and Appwrite both support read replicas and connection pooling. PocketBase can use Litestream for SQLite replication to a read-only replica, but write scaling requires application-level sharding.
Backup and Disaster Recovery
PocketBase
PocketBase is a single directory. Backing up means copying the data directory:
| |
Appwrite
Appwrite volumes need consistent backups:
| |
Supabase
PostgreSQL has mature backup tooling:
| |
Which One Should You Choose?
Choose PocketBase if:
- You are building a personal project, internal tool, or MVP
- You want zero operational overhead — one binary, done
- Your project fits comfortably within SQLite’s concurrency model (read-heavy workloads)
- You value simplicity and want to manage less infrastructure
Choose Appwrite if:
- You need the widest feature set — teams, GraphQL, audit logs, messaging, AV generation
- You are migrating from Firebase and want the closest API parity
- You need multi-tenant project isolation (one Appwrite instance, many projects)
- Your team is comfortable with Docker and container orchestration
Choose Supabase if:
- Your application is data-heavy and benefits from PostgreSQL’s features (joins, full-text search, PostGIS, window functions)
- You want the flexibility of standard SQL for complex queries
- You plan to scale horizontally with read replicas and connection pooling
- You already use PostgreSQL and want a seamless integration
Getting Started Today
The fastest way to evaluate any of these platforms is to spin them up locally:
| |
All three are production-ready, actively maintained, and backed by vibrant open-source communities. The best choice depends on your project’s scale, your team’s expertise, and your infrastructure preferences. What they all share is something Firebase cannot offer: your data stays on your servers, under your control, forever.
Frequently Asked Questions (FAQ)
Which one should I choose in 2026?
The best choice depends on your specific requirements:
- For beginners: Start with the simplest option that covers your core use case
- For production: Choose the solution with the most active community and documentation
- For teams: Look for collaboration features and user management
- For privacy: Prefer fully open-source, self-hosted options with no telemetry
Refer to the comparison table above for detailed feature breakdowns.
Can I migrate between these tools?
Most tools support data import/export. Always:
- Backup your current data
- Test the migration on a staging environment
- Check official migration guides in the documentation
Are there free versions available?
All tools in this guide offer free, open-source editions. Some also provide paid plans with additional features, priority support, or managed hosting.
How do I get started?
- Review the comparison table to identify your requirements
- Visit the official documentation (links provided above)
- Start with a Docker Compose setup for easy testing
- Join the community forums for troubleshooting