Firebase Alternatives You Can Self-Host and Actually Control

Why founders look for Firebase alternatives

Firebase does a lot of things right. The onboarding is fast, the SDKs are polished, and you can go from zero to a working app with auth, database, and hosting in an afternoon. For hackathons and MVPs, it is hard to beat.

The problems start when your project grows beyond the prototype stage.

Pricing surprises. Firebase charges per document read, write, and delete in Firestore. This sounds reasonable until you realize that loading a list of 50 items costs 50 reads. A dashboard that refreshes every 30 seconds can burn through your free tier in hours. The pricing model punishes the exact usage patterns that real apps have — frequent reads of multiple documents. Founders regularly share stories of unexpected bills in the hundreds or thousands of dollars.

Vendor lock-in. Firestore's data model and query language are proprietary. Cloud Functions run on Google Cloud. Firebase Auth tokens are tied to the Firebase ecosystem. Migrating away means rewriting your data layer, auth system, and serverless functions. That is a major engineering effort for a solo founder.

NoSQL limitations. Firestore is a document database. It works beautifully for simple data — user profiles, chat messages, settings. But the moment you need joins, aggregations, or complex queries across collections, you are fighting the data model. You end up denormalizing data (duplicating it across collections) or making multiple queries that drive up your read costs.

No SQL means no ecosystem. The entire world of SQL tooling — BI tools, data analysis, migration frameworks, ORMs — does not work with Firestore. You are limited to Firebase's own console and SDK for everything.

These are the reasons alternatives exist. Not because Firebase is bad, but because it optimizes for fast starts at the cost of long-term flexibility.

How we evaluated these alternatives

For each tool, we looked at what matters to a solo bootstrapped founder shipping a real product:

• Time to first deploy: How quickly can you go from zero to a working API with auth?
• Pricing predictability: Can you estimate your monthly bill before it arrives?
• Data portability: If you need to leave, how painful is the migration?
• Self-hosting option: Can you run it on your own infrastructure?
• Production readiness: Is this battle-tested or still in early beta?

We also considered ecosystem size — documentation quality, community support, and availability of tutorials and examples. A technically superior tool with no docs is worse than a decent tool with great docs when you are building alone.

Deep dive: what each alternative does best

Supabase — the default Firebase replacement

Supabase has positioned itself as "the open-source Firebase alternative," and honestly, that positioning is accurate. It gives you a Postgres database, auth, real-time subscriptions, edge functions, and file storage — the same feature categories as Firebase, but built on open standards.

The Postgres foundation is the biggest difference. Instead of Firestore's document queries, you write SQL. Instead of denormalizing data across collections, you use proper relational joins. Instead of Firestore security rules (a DSL that only Firebase understands), you use Row Level Security policies in SQL. If you have ever used Postgres, the learning curve is minimal.

The dashboard is surprisingly good for an open-source project. You get a table editor, SQL editor, auth user management, storage browser, and real-time inspector. It feels like a product, not a developer tool cobbled together from open-source components.

Real-time subscriptions work through Postgres logical replication. You can subscribe to changes on any table, filtered by conditions. It works, but it is not as seamless as Firestore's real-time listeners, which handle offline caching and conflict resolution automatically. If your app is heavily real-time (like a collaborative editor), this matters.

Edge Functions run on Deno, not Node.js. Most npm packages work, but some do not. Check compatibility before assuming your existing serverless code will port over. Supabase also offers database functions (PL/pgSQL) for server-side logic that runs inside the database — often faster than calling an edge function.

The free tier is generous but has a catch: projects pause after one week of inactivity. For a production app, you need the Pro plan at $25/month minimum. That gets you 8GB database, 100GB bandwidth, and no pausing.

When to pick Supabase: You are building a web app with relational data, you know SQL, and you want a managed service that you could self-host later if needed.

Appwrite — the self-hosting champion

Appwrite is what you want if your first requirement is "I need to own the entire stack." It is a Docker-based BaaS that you deploy on your own server. One docker compose up command gives you auth, databases, storage, functions, and a dashboard.

The auth system is comprehensive — over 30 OAuth providers, email/password, magic links, phone auth, and anonymous sessions. For most apps, auth is the most painful part to build from scratch, and Appwrite eliminates that entirely.

Functions support multiple runtimes: Node.js, Python, PHP, Ruby, Dart, Swift, and more. This flexibility is unusual — most BaaS platforms lock you into one language. If your team has a Python dev who wants to write backend logic while you handle the TypeScript frontend, Appwrite accommodates that.

The database uses MariaDB under the hood but exposes a document-based API. This is a middle ground — you get structured collections with defined attributes (more structured than Firestore), but you do not get raw SQL access. For founders who want the full power of SQL, Supabase is a better fit. For those who prefer a document model with stronger typing, Appwrite works well.

The managed cloud offering starts at $15/month for the Pro plan, which is cheaper than most competitors. But the real value proposition is self-hosting. Run Appwrite on a $10/month Hetzner VPS and you have a full BaaS for your app with no recurring platform fees.

When to pick Appwrite: You want complete control of your backend infrastructure and are comfortable managing Docker containers in production.

PocketBase — the radical simplifier

PocketBase takes a different approach from everything else on this list. Instead of a platform with microservices, containers, and cloud dashboards, it is a single Go binary. You download one file, run it, and you have a backend with a database, auth, real-time subscriptions, file storage, and an admin UI.

The database is SQLite, which means your entire database is a single file on disk. Backups are literally copying that file. There is no database server to manage, no connection pools to tune, no replication to configure. For the vast majority of indie projects, SQLite handles the workload without breaking a sweat.

The admin dashboard is built into the binary. Open your browser to the admin URL and you get a clean interface for managing collections (tables), viewing data, managing auth users, and exploring the REST API. It even generates client SDK code for your collections.

PocketBase also supports extending the backend with Go code if you need custom logic. You can add custom API routes, hooks that run before or after database operations, and middleware. This turns PocketBase from a simple BaaS into a lightweight application framework.

The fundamental limitation is scalability. SQLite runs on a single server. There is no built-in clustering, replication, or sharding. If your app needs to handle thousands of concurrent write operations or you need multi-region deployment, PocketBase is not the right tool. But for a SaaS serving hundreds of users, an internal tool, or a side project? It is more than enough.

The other concern is the bus factor. PocketBase is maintained primarily by one developer. The project is popular (30k+ GitHub stars), but the development pace depends on one person. For a critical production system, this is worth considering. For a side project or early-stage startup, the simplicity benefit outweighs the risk.

When to pick PocketBase: You want the simplest possible backend that you can deploy to a single server and forget about. Perfect for MVPs, side projects, and apps with modest scale requirements.

Convex — the real-time native

Convex takes a fundamentally different approach to backend development. Instead of a database that you query, Convex gives you a reactive database where every query is automatically a real-time subscription. When data changes, every client displaying that data updates instantly.

This is not a bolt-on feature. The entire platform is designed around reactivity. You write query functions in TypeScript, and the results are automatically cached and invalidated when the underlying data changes. There is no manual subscription management, no polling, no WebSocket plumbing.

The type safety story is compelling. You define your schema in TypeScript, and the types flow from the database through your queries and mutations all the way to your React (or other framework) components. A change to your schema shows type errors in your UI code immediately. For solo developers, this catches bugs before they reach production.

Convex also provides proper ACID transactions, which Firestore does not. If you need to update multiple documents atomically (deduct credits AND record a transaction AND update a user's balance), Convex handles this correctly without workarounds.

The downside is lock-in. Convex is a managed platform with no self-hosting option. Your data lives on their infrastructure, and your backend logic uses their proprietary patterns. If Convex changes pricing, pivots, or shuts down, you are migrating everything. For a side project, this risk is acceptable. For your primary revenue-generating product, weigh it carefully against the productivity benefits.

When to pick Convex: You are building a real-time collaborative app and want type-safe, reactive data without managing WebSocket infrastructure.

Nhost — the GraphQL backend

Nhost bundles Hasura (GraphQL engine), Postgres, auth, storage, and serverless functions into a single platform. If you are already sold on GraphQL for your API layer, Nhost removes the infrastructure burden of running Hasura yourself.

Hasura auto-generates a GraphQL API from your Postgres schema. Create a table, and you immediately get queries, mutations, subscriptions, and filtering — all with proper types. No resolver code to write. This is a massive productivity boost for founders who are comfortable with GraphQL.

The auth system supports email/password, magic links, and common OAuth providers. It integrates with Hasura's permission system, so you can define row-level access control through the Hasura console rather than writing custom middleware.

Self-hosting is supported through Docker Compose, making Nhost a viable option for founders who want data control. The managed platform starts at $25/month for the Pro plan with reasonable included resources.

The trade-off is complexity. GraphQL adds a layer of abstraction that not everyone needs. If your API is mostly CRUD operations, REST endpoints (like Supabase provides) are simpler. If you are not already familiar with GraphQL concepts — schemas, resolvers, subscriptions, fragments — there is a meaningful learning curve on top of learning the Nhost platform itself.

When to pick Nhost: You want a GraphQL API auto-generated from your Postgres schema without managing Hasura, Postgres, and auth separately.

AWS Amplify — the enterprise on-ramp

AWS Amplify is Amazon's answer to Firebase. It wraps core AWS services — DynamoDB, Cognito, S3, Lambda, AppSync — behind a CLI and client libraries that abstract away the AWS complexity.

The value proposition is clear: you get the reliability and scalability of AWS without needing to configure IAM policies, VPCs, and CloudFormation templates. The Amplify CLI generates the infrastructure, and the client libraries handle auth flows, API calls, and file uploads.

Amplify Hosting is a nice addition — CI/CD pipeline for your frontend with preview deployments on pull requests. If you are already deploying a Next.js or React app, Amplify Hosting is competitive with Vercel.

The problems are AWS-shaped. Pricing is pay-per-use across multiple services, which makes your monthly bill unpredictable. DynamoDB's single-table design pattern has a steep learning curve. Cognito's auth flows are functional but the developer experience is rough compared to Firebase Auth or Supabase Auth. And when Amplify's abstractions do not cover your use case, you fall through to raw AWS — which is powerful but complicated.

For founders already running infrastructure on AWS, Amplify makes sense as a way to keep everything in one ecosystem. For everyone else, the other options on this list provide a better developer experience.

When to pick AWS Amplify: You are already committed to AWS, need enterprise-grade scalability guarantees, and are willing to trade developer experience for ecosystem consistency.

When to stick with Firebase

Firebase is still the right call in specific situations:

• Offline-first mobile apps. Firestore's client SDKs handle offline caching, conflict resolution, and sync better than any alternative listed here.
• You are deep in the Google ecosystem. If you use Google Analytics, Google Ads, BigQuery, and Google Cloud, Firebase integrates seamlessly.
• Rapid prototyping. Nothing matches Firebase's speed for going from zero to a working app with auth and data persistence.
• Your app is read-heavy with simple data. Firestore shines when data fits naturally into documents and you mostly read individual documents or small collections.

The time to value with Firebase is genuinely excellent. If your goal is to validate an idea as fast as possible and you can afford to migrate later, Firebase is a reasonable choice for the prototype.

Migration strategies for founders

Moving off Firebase is not trivial, but it is doable:

1. Start with auth. Set up auth on the new platform first. Run both auth systems in parallel during migration.
2. Export Firestore data. Use the Firebase Admin SDK to export collections as JSON or use gcloud firestore export for larger datasets.
3. Transform your data model. If moving to Postgres (Supabase/Nhost), you will need to convert your document structure to relational tables. Map subcollections to foreign key relationships.
4. Migrate storage. Firebase Storage files can be downloaded and re-uploaded to the new platform's storage. Script this — do not do it manually.
5. Update client code gradually. Replace Firebase SDK calls with the new platform's SDK, one feature at a time. Auth first, then data, then storage, then functions.
6. Keep Firebase running during transition. Do not cut over all at once. Run both systems for at least two weeks to catch edge cases.

Budget 2-4 weeks for a medium-sized project. The hardest part is usually the data model transformation from NoSQL to relational. Everything else is straightforward SDK swapping.