Software engineering · · 6 min read · By the Cirlume studio
Covers Firebase, Supabase, PostgreSQL, Go, Node.js, Python, AWS
Firebase, Supabase or a custom back end: how to choose
How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
Every new web or mobile product needs somewhere to store data, sign people in and run logic that should not live on the device. The quick options are hosted platforms such as Firebase and Supabase, which give you a database, authentication, file storage and client libraries in an afternoon. The slower option is a custom back end: your own API in front of a database you choose.
The choice is hard to reverse once real data and users depend on it. It is worth an hour of deliberate thought before the first screen is built. This article sets out the questions we ask.
What each option is
Firebase is Google’s app platform. Its best-known database, Cloud Firestore, is a document database: data lives in collections of JSON-like documents, and mobile and web apps read and write it directly, protected by security rules. In April 2026 Google renamed Firebase Data Connect to Firebase SQL Connect. It gives Firebase apps a managed PostgreSQL database on Cloud SQL, accessed through GraphQL-style operations, with native SQL and realtime query updates added this year.
Supabase is a hosted platform built on PostgreSQL. You get a full Postgres database, an auto-generated API, authentication, storage and realtime features. Apps can call the database directly, protected by Postgres row level security. Supabase is open source and can be self-hosted with Docker.
A custom back end is an API you write, in Go, Node.js, Python or similar, deployed to your cloud of choice, in front of a database you manage or rent. Clients never touch the database. Every request goes through code you control.
Start with the shape of your data
The most useful question is what your data looks like and how it will be queried.
- Mostly independent documents, read by the people who own them. Profiles, settings, chat messages, simple content. A document store like Firestore handles this well and syncs it to devices with little code.
- Records with many relationships. Bookings linked to customers, staff, locations and invoices. Reports that join across them. This is relational data, and PostgreSQL suits it. Supabase, Firebase SQL Connect and a custom back end on Postgres all qualify.
- Heavy reporting or analysis. If finance or operations will ask questions you cannot predict, a relational database with SQL access saves a great deal of pain later.
Modelling relational data in a document store is possible, but it usually means duplicating data across documents and keeping the copies in step. That cost appears months later, when a report needs data from five collections.
Decide where access rules live
When clients talk to the database directly, the access rules are your security boundary. Get them wrong and data is exposed.
- Firestore security rules are evaluated on every request from the mobile and web client libraries. They are expressive, but they are a separate language that needs its own tests. Server client libraries bypass them entirely and rely on IAM instead.
- Supabase row level security is standard Postgres. Policies are written in SQL and tested like other database code. Supabase’s documentation is clear that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, so every table needs RLS turned on and policies written. A common mistake is a policy that compares
auth.uid()with a column, forgetting that it returns null for anonymous requests. - A custom back end puts rules in application code. That makes complex rules easier to express, such as “a coordinator can edit visits for their branch unless the visit is invoiced”, and harder to bypass, because there is no direct database access to protect.
If your rules depend on several pieces of state or change often, a custom API or server-side functions alongside the platform are usually easier to reason about than direct client access.
Model the costs as usage grows
All three can be cheap at the start. They diverge as usage grows, and in different ways.
- Firestore charges per document read, write and delete, plus storage and network. Each document returned by a query counts as a read, and a realtime listener is charged a read each time a document in its results is added or updated. A busy screen that lists hundreds of documents for many users can cost more than expected. Model your heaviest screens before launch.
- Firebase SQL Connect charges per operation on top of the Cloud SQL instance it runs on.
- Supabase charges a plan fee per organisation, compute for each project’s dedicated Postgres server, and usage beyond quotas such as egress, storage and monthly active users. Costs track the size of the database server more than the number of reads.
- A custom back end costs whatever your cloud resources cost, plus the engineering time to build and run it. That time is the largest cost and the easiest to underestimate.
Run the numbers with your own expected usage on each provider’s current pricing page. Pricing changes, and estimates from a year ago are often wrong.
Plan the exit before you need it
Lock-in is not only about data export. It is about how much of your application assumes one platform.
- Firestore data can be exported to Cloud Storage with the managed export service, which needs the Blaze plan. Moving it to a relational database means redesigning the data model, and rewriting the client code and security rules that depended on it.
- Supabase is Postgres, so the data moves with standard tools such as
pg_dump. Self-hosting is an option, though the self-hosted version runs as a single project and lacks some managed features, including branching and managed backups. Code that calls Supabase-specific APIs, auth and storage still needs replacing if you leave. - A custom back end has the least platform lock-in, but you are still tied to your cloud provider’s managed services if you use them.
A practical middle ground is to put business logic behind your own thin API layer even on a hosted platform. Clients call your endpoints for anything important, and only simple reads go direct. Moving later then means changing the layer, not every screen.
Match the choice to your team
The right option is often the one your team can run safely.
- A small team with strong front-end skills and no one to look after servers can ship much faster on Firebase or Supabase.
- A team comfortable with SQL will find Supabase’s policies and migrations familiar, and Firestore’s rules and data modelling less so.
- A custom back end needs people who can design APIs, handle migrations, monitor production and respond when something breaks at night.
Our view
For products with relational data, which covers most business software, we lean towards PostgreSQL, either on Supabase or behind a custom API. SoulCare, our home-care platform, uses Go services on AWS Lambda behind API Gateway, with a PostgreSQL database for each provider, because its access rules and data separation needed that control. Firebase remains a good fit for apps whose data is mostly per-user documents and where offline sync to mobile matters.
None of these is a wrong choice in general. They are wrong for particular data, rules and teams.
When to bring in help
If you are about to start a product and are not sure which foundation fits, or you are already on a platform and costs or access rules are becoming hard to manage, a short review of your data model and expected usage usually settles it. We can help model costs, design access rules, or plan a move to a different back end without stopping the product.