Most side projects die on the backend. Not on the feature work. On the part nobody likes: passwords, sessions, file uploads, and the invoice that shows up the month a side project suddenly gets popular.
Disclosure: This article contains affiliate links. If you buy through one of them, this site may earn a commission at no extra cost to you.
That last part is why I’d argue the backend choice is a pricing decision as much as a technical one. Supabase, Firebase, and Appwrite all promise the same thing on the homepage. A working auth system, a database, and storage in an afternoon. What separates them is what happens in month four, when you’ve got real users and a bill that’s either predictable or very much not.
The pricing models are genuinely different animals
Firebase runs on usage. The Spark plan is free with daily caps, and the Blaze plan charges per read, write, and byte. Google publishes the free allowances clearly: 50,000 Firestore reads a day, 20,000 writes, 1 GiB stored, 10 GiB egress monthly. Past that, you pay Google Cloud rates.
Supabase went the other way. The Free plan gives you 500 MB of database and 50,000 monthly active users, with two active projects, and pauses projects after a week of low activity. Pro starts at $25 a month, and that price includes 100,000 MAU, 8 GB of disk per project, 250 GB of egress, and $10 in compute credit that covers one Micro instance.
Appwrite sits between them. Its dedicated compute tiers start at $10 a month for one core and 1 GB of RAM, with $10 in monthly compute credits included, and it bills databases as either serverless usage or a fixed tier.
Those three sentences describe three different failure modes. Firebase’s failure mode is a surprise invoice. Supabase’s is a compute upgrade you didn’t plan for. Appwrite’s is less about surprise and more about platform maturity, which I’ll get to.
The invoice test: what 100k users actually costs
Let’s put a number on it. Say you’re running a small SaaS with 5,000 monthly active users, 200,000 database reads a day, a few gigabytes of files, and 150 GB of egress monthly.
- Supabase Pro. The $25 base covers the MAU count comfortably and the egress fits inside the 250 GB allowance. If your app is small enough to run on Micro compute, $25 a month is the bill. If it needs a Medium instance, add $50 and you’re at roughly $75 before any storage overage.
- Firebase Blaze. Your 200,000 daily reads are four times the free tier, so the reads start costing money every day, not just on a spike. Storage and egress add on top. The total depends heavily on how chatty your queries are, which is exactly the problem: the number lives in your code review habits.
- Appwrite. A Starter tier at $10 covers 1 core and 1 GB. You’re likely upgrading to Standard at $20 for a real app, and the $10 compute credit softens it.
None of those are outrageous. Firebase just requires you to read Cloud pricing docs to answer a question the other two answer on one page.
Where Firebase still beats everyone
I’ll be honest about the tradeoff here, because Firebase’s weaknesses get repeated a lot and its strengths get lost.
The real-time sync is very good, and Firestore’s offline persistence on mobile is better than what you get by bolting a sync layer onto Postgres. If you’re building a mobile app where users expect the UI to update the instant something changes on another device, Firebase is the path of least resistance. Cloud Messaging is free, which matters for push notifications at any real scale.
The flip side is lock-in. Firestore’s document model and query constraints don’t map cleanly onto SQL, so a migration means rewriting your data layer, not just exporting rows. Every team I’ve talked to who left Firebase describes the same thing: the export was easy, the rewrite wasn’t.
Supabase: it’s Postgres, and that’s the whole pitch
Supabase hands you a regular Postgres database with a connection string. You can point psql at it, or Prisma, or Drizzle, or the ORM you already use. Row Level Security runs inside the database itself, so your authorization rules are SQL policies rather than application code you hope stays in sync.
The tradeoff is that Postgres expertise becomes your problem. A slow query needs an index you write yourself. Firestore would quietly scale instead. On the other hand, if your app ever needs a join across three tables, you’ll be glad you’re on Postgres, and Firestore will be the thing making you think about denormalization at 2 a.m.
One concrete detail worth knowing if you’re cost-conscious: Supabase bills compute separately per project. A Pro organization with two projects on Micro instances runs $25 plus $10 plus $10 minus the $10 credit, or $35 a month. That’s easy to forget when you spin up a staging environment.
Appwrite: self-hosting without the pain
Appwrite is the one to look at if you want the option to run your backend on your own hardware. Its containers deploy to Docker on anything from a VPS to a home server, and the same platform runs as managed cloud. Supabase can be self-hosted too, but the official line is that it’s a heavier exercise, and Firebase has no self-host path at all.
The honest downside is ecosystem size. Fewer tutorials, fewer Stack Overflow answers, fewer people who’ve hit your exact bug. For a solo developer that gap costs time even when the software is free.
The parts you don’t notice until month six
Pricing tables compare cleanly. Day-to-day operations don’t, and the gaps between these platforms show up in small places.
Migrations. Supabase ships a CLI that generates SQL migration files you commit to git. Firebase still leans on its emulator suite and CLI for deploying rules, and schema changes land as application code rather than versioned SQL. Appwrite has a migrations API, but most teams I’ve read about treat schema work as a dashboard task and document it by hand.
Local development. All three give you a local emulator or container. Supabase’s is a Docker Compose stack that runs offline, which matters more than it sounds when you’re on a plane or your ISP is having a day. Firebase’s emulator suite is mature and plugs into the test frameworks Google supports.
Security rules. Row Level Security in Supabase is SQL you can test, and you can run those policies against your local stack inside your own test suite. Firestore rules are a separate language with a separate emulator. Appwrite’s permission model is the easiest to read of the three, which cuts both ways: simple is fast to start and awkward when you need something nuanced.
Backups. Supabase Pro includes daily backups kept for 7 days. Point-in-time recovery is an add-on at $100 a month per 7 days of retention, which is the line item that makes you sit up and check what your actual recovery objective is. Firebase usually leans on Google Cloud’s own backup tooling, and you want to know what that costs before the day you need it.
None of this is disqualifying. It’s the difference between a platform that hands you the controls and one that hides them. If you’re comfortable owning your migrations and your rules, the transparent option tends to be cheaper across a year. If you’d rather the platform handle the plumbing, the managed option earns its premium.
Head-to-head comparison
| Factor | Supabase | Firebase | Appwrite |
|---|---|---|---|
| Free tier database | 500 MB, 2 active projects | 1 GiB stored, 20K writes and 50K reads per day | Serverless quota, $10 compute credit monthly |
| First paid tier | Pro, $25/mo | Blaze, usage-based | From $10/mo (Starter compute) |
| Billing model | Subscription plus per-project compute | Pure usage | Subscription plus compute tier or usage |
| Database type | Postgres (SQL) | Firestore and Realtime Database (document) | TablesDB default, plus PostgreSQL and MySQL options |
| Self-hostable | Yes, heavier setup | No | Yes, Docker-native |
| Lock-in risk | Low, standard Postgres | High, document model and query limits | Low to medium |
| Free push notifications | No native FCM equivalent | Yes, FCM at no cost | No native FCM equivalent |
| Best fit | Web apps and SaaS with relational data | Mobile apps needing real-time sync | Teams wanting self-hosting |
How I Evaluated These Three
I don’t run a Firebase or Appwrite project in production, so I’m not going to claim I did. What I did do is pull the current pricing pages for all three and work through the numbers myself, read the vendor documentation on billing mechanics, and go through public write-ups from teams that migrated off each platform. The Supabase numbers in this article match what its pricing page lists today. Firebase’s free allowances come straight from Google’s pricing documentation. Where a specific anecdote shows up, it’s from a public postmortem, not from my own logs.
What I do have firsthand is the shape of the decision. Our own stack runs WordPress with a Postgres-flavored habit for anything custom, and every time I’ve reached for a backend-as-a-service it was because I wanted auth and storage off my plate, not because I wanted a new query language to learn. That bias probably explains why I lean toward SQL-backed options, so weigh it accordingly.
Three questions that actually decide it
Do you need offline sync on mobile? If yes, Firebase is hard to beat and the lock-in is the price of admission.
Will your data ever need joins? If yes, pick the SQL option. Retrofitting relational queries onto a document store is the kind of work that takes a quarter.
Could you ever need to own the backend? If self-hosting is on the roadmap, Appwrite’s Docker-native approach is easier to live with than most alternatives.
I’d add a fourth that’s less technical: can you afford a surprise invoice? Firebase’s meter is more granular, and granular meters are easier to leak through. Supabase’s per-project compute is less exciting but it’s a number you can put in a spreadsheet.
Key Takeaways
- Firebase’s free tier is generous in storage but strict on daily read and write counts, which makes it easy to cross the line quietly.
- Supabase Pro at $25 sits close to a flat monthly cost, but every extra project adds compute.
- Appwrite’s $10 Starter tier and $10 monthly compute credit make it the cheapest fixed-cost entry point.
- Firebase scores on real-time sync and free push notifications. It loses on lock-in.
- Supabase wins on portability because it’s plain Postgres. Appwrite wins when self-hosting matters.
Start on a free tier for whichever one matches your database shape and stop worrying about the migration you haven’t done yet. Pick Postgres if your data is relational. Pick Firestore if your app is mobile and live. That single choice settles most of the rest of it.