Supabase vs. Firebase vs. Appwrite vs. PocketBase vs. a Custom Backend: Which to Choose in 2026?

When people think of an “app”, they picture screens, buttons and forms. But what actually holds an app together is the backend: the database, user sign-in, file storage, permissions and the logic that runs on the server. And this choice matters even more than the frontend one — data is much harder to migrate than components.

In our article on web stacks we looked at how to build a website. Here we follow up with a different question: where will your data live? There are essentially two paths:

• Backend as a Service (BaaS) — Supabase, Firebase, Appwrite or PocketBase. You get a database, authentication, storage and an API “out of the box” and can start building right away.
• A custom backend — your own server with MySQL or PostgreSQL and your own API. More work up front, but full control.

For a quick overview:

Supabase — PostgreSQL with batteries included#

Supabase is one of today’s most popular choices for web applications and powers the backend of a number of AI app builders (Lovable, for example). At its core is a full PostgreSQL database — a classic relational database with tables, relations and SQL. Around it, Supabase adds authentication (email, Google, Apple…), file storage, realtime updates and server-side functions.

The key concept is Row Level Security (RLS): permissions are written directly in the database (“a user can only see their own invoices”), so the frontend can safely query it directly. When RLS is set up well, it’s elegant. When it’s set up badly, the data is visible to anyone — and in quickly generated apps, it’s the most common security flaw I come across.

Pros: standard SQL (no lock-in to a proprietary format), extensions such as pgvector for AI search, open source, EU data centre available (Frankfurt). Cons: self-hosting is more demanding (several services in Docker), free projects are paused after a week of inactivity.

Pricing (as of September 2026):

• Free: $0 — 500 MB database, 1 GB file storage, 5 GB egress, 50,000 monthly active users, max. 2 active projects, paused after a week of inactivity, no backups.
• Pro: from $25/month — 8 GB database, 100 GB file storage, 250 GB egress, 100,000 MAU, daily backups (7 days), no pausing. Each additional project from $10/month. A spend cap is on by default, so your bill won’t run away.

Firebase — Google, mobile and offline#

Firebase is the oldest and most established player. Its main database, Firestore, is document-based (NoSQL): data isn’t stored in tables but in collections of JSON-like “documents”. For mobile apps, Firebase has very mature offline support — the app works without a signal and syncs once it’s back online. On top of that you get push notifications, analytics, crash reporting and tight integration with Google Cloud.

Pros: maturity, a mobile-app ecosystem, a generous free tier with no credit card required. Cons: proprietary — moving elsewhere means rewriting your data model. Pricing is based on the number of reads and writes, so a single inefficient query can multiply your bill. Relational data (orders ↔ customers ↔ products) is harder to model in a document database.

Pricing (as of September 2026):

• Spark (free): Firestore 1 GiB of data, 50,000 reads / 20,000 writes / 20,000 deletes per day, 10 GiB egress per month, authentication up to 50,000 MAU. Server-side functions (Cloud Functions) are not available on the free plan.
• Blaze (pay as you go): free limits still apply, and you pay for actual usage above them. Cloud Functions include 2M free invocations per month. New accounts may receive $300 in credit. There’s no fixed monthly fee — but no cap either, unless you set up budget alerts.

Appwrite — the open-source all-in-one#

Appwrite offers a package similar to Supabase — authentication, database, storage, functions, realtime, plus messaging (email, SMS, push) and website hosting. The difference is in philosophy: from day one it’s designed so you can run it yourself on your own server as a single bundle. Besides its own database, it now also offers dedicated PostgreSQL or MySQL.

Pros: one platform for backend and hosting, easy self-hosting, good support for Flutter and mobile, generous bandwidth on the paid plan. Cons: a smaller community and fewer tutorials than Supabase/Firebase; the cloud version’s limits and pricing have changed several times in recent years, so check the current state before deciding.

Pricing (as of September 2026):

• Free: $0 — 75,000 MAU, 2 GB storage, 5 GB bandwidth, 750,000 function executions, 1 database and 1 bucket per project, max. 2 projects, paused after a week of inactivity.
• Pro: from $25/month for the first project, $15 for each additional one — 2 TB bandwidth, 150 GB storage and 200,000 MAU per project, daily backups (7 days), email support.
• Self-hosting: free (you only pay for the server).

PocketBase — an entire backend in a single file#

PocketBase is the smallest and simplest of the five: a single executable that contains a database (SQLite), authentication, file storage, a realtime API and an admin dashboard. Download it, run it, done. On a small virtual server costing a few euros a month, it can handle a surprising amount of traffic.

Pros: extreme simplicity, no platform fees, all data stays with you, ideal for MVPs, internal tools and smaller apps. Cons: it runs on a single server — you can’t scale horizontally. The project is still pre-1.0, and its own documentation warns that updates may require manual migrations. Backups, updates and server security are your responsibility.

Pricing: the software is free (open source, MIT). You only pay for a VPS — roughly €4–12/month (approx. CZK 100–300) with smaller providers.

Custom backend — MySQL / PostgreSQL and your own API#

The last option is the most traditional: your own server (or hosting), your own database and your own API — for example in Node.js, PHP or Python. Nothing comes out of the box; you build everything yourself: authentication, permissions, file uploads, backups.

That sounds like a lot of work — and it is. But in 2026, AI tools have cut much of that work down, and a custom backend has advantages no platform can offer: no vendor lock-in, data physically where you want it (for example in the Czech Republic), logic tailored exactly to your needs and, for stable applications, often lower ongoing running costs. If a company already has a MySQL database (typically an e-shop or an older system), connecting to it is usually more sensible than moving the data into a BaaS.

Pros: full control, no platform limits, predictable costs, easy to meet specific requirements (GDPR, data stored in the Czech Republic, integration with accounting or ERP systems). Cons: the highest upfront development cost; security and maintenance are entirely your responsibility — improvised authentication and permissions are a real risk.

Pricing: shared hosting with MySQL from a few euros a month, a VPS roughly €4–20/month (approx. CZK 100–500), a managed cloud database from a few to a few dozen dollars. But the main cost isn’t the server — it’s development and maintenance time.

Side-by-side comparison#

Prices and limits are valid as of the publication date. All platforms have changed them repeatedly in recent years — check the official pricing pages before deciding. Platform prices are listed in USD as published by the providers; EUR/CZK figures for servers are approximate, converted at roughly CZK 25 per EUR.

Vendor lock-in: how hard is it to leave?#

The “vendor lock-in” row in the table may be the most important one, because it decides what awaits you three years from now.

• Supabase, Appwrite with PostgreSQL/MySQL, a custom backend: your data lives in a standard SQL database. Moving from one PostgreSQL to another (your own server, a different cloud) is a routine operation — export, import, reconnect. What needs rewriting is mainly authentication and the parts that call a platform’s specific SDK.
• PocketBase: SQLite is a single file that almost anything can open. Leaving is technically easy; you just port the schema and logic yourself.
• Firebase: here it’s not just about the database. Firestore has its own data model, permissions live in Security Rules, logic in Cloud Functions, and the app is built around the Firebase SDK. Leaving therefore usually means rebuilding a large part of the architecture, not just moving the data.

That doesn’t make Firebase a bad choice — for a mobile app that will stay in the Google ecosystem it can be ideal. It’s just worth knowing up front.

Watch out for these free-tier catches#

“Free” is great for development and prototypes, but it has a few catches in production:

• Project pausing. Both Supabase and Appwrite pause free projects after a week of inactivity. For an app used by a handful of people now and then, that’s an unpleasant surprise.
• No backups. Free plans usually don’t include automatic backups. No app with real data should run without them.
• Project limits. Typically 2 active projects per account — not enough for an agency or a freelancer with multiple clients.
• Paying per operation. With Firebase you don’t pay for size, but for the number of reads and writes. Set up budget alerts before you need them.

How I’d choose a backend for your project#

Just like with the frontend, I don’t start with the tool but with a few questions:

1. What kind of data does the app have? Lots of relations (customers, orders, invoices) → SQL (Supabase, a custom backend). Looser structure and mobile → Firebase.
2. How many users, and how fast will it grow? A few dozen internal users can be handled by PocketBase on a small server. A public product with unknown growth → a managed platform.
3. Where can the data be stored? If you need data in the Czech Republic or full control, self-hosting (Appwrite, PocketBase) or a custom backend wins.
4. Who will maintain it in two years? A managed platform saves you server headaches. A custom solution can reduce ongoing platform fees, but it shifts a larger share of the cost into development and maintenance.

At SEMAKOD, I most often reach for Supabase for web apps and SaaS, and a custom backend where a company already has its own data or needs integration with internal systems. If you’re not sure what would make sense for your project, I’m happy to talk it through — or estimate an indicative price.

This article was created with AI assistance and reviewed editorially by SEMAKOD, including verification of the technical information’s accuracy as of the publication date.