Supabase vs Firebase for Australian apps: hosting, cost and lock in

Relational or document: what is the core difference?

Supabase gives you a PostgreSQL database with tables, joins and SQL; Firebase gives you Firestore, which stores JSON documents in collections. Almost every other difference, from pricing to reporting to how hard it is to leave, follows from that.

In Postgres, a customer row links to many order rows, and an invoice links to both. You ask questions with SQL, and the database enforces that an order can’t point at a customer who doesn’t exist. In Firestore, you usually copy the data each screen needs into the document that screen reads. That makes simple reads very fast and cheap to write code for, but it moves the job of keeping copies consistent into your app.

A rough rule we use: if the product’s core is records that relate to each other (bookings, jobs, quotes, stock, invoices) and someone will want reports across them, relational wins. If the core is a stream of user content, chat or device state read mostly one document at a time, Firestore is a comfortable fit.

	Supabase	Firebase
Main database	PostgreSQL (relational, SQL)	Firestore (document, NoSQL); SQL Connect adds Cloud SQL for PostgreSQL
Queries	Full SQL, joins, views, functions	Document and collection queries; joins done in the app
Access control	Postgres row level security policies	Firebase security rules
Realtime	Realtime subscriptions on table changes	Realtime listeners are central to the SDKs
Offline on mobile	Not built in; needs an added sync layer	Offline persistence on by default for Android and Apple
Functions	Edge Functions (Deno)	Cloud Functions for Firebase
Open source	Yes, can be self hosted	No

Where does each platform host data in Australia?

At the time of writing, Supabase offers Sydney (ap-southeast-2) as a specific region, and Firestore offers both Sydney (australia-southeast1) and Melbourne (australia-southeast2). Both let you pick the location when you create the database, and neither lets you change it afterwards without a migration.

Two details matter. First, Supabase’s general regions (Americas, Europe, APAC) place your project in whichever AWS region in that area has capacity, and the APAC grouping points to Singapore. If your data must stay in Australia, pick Sydney explicitly. Second, Firebase has no default location for Firestore or Storage, so someone has to choose, but Cloud Functions for Firebase fall back to us-central1 in Iowa if no region is set. We see that default slip into production more often than any other residency mistake.

Latency follows location. A Sydney database serves users in Sydney and Melbourne quickly; one in Singapore or Iowa adds a noticeable delay to every request, which compounds on screens that make several calls.

Does everything stay onshore?

No, and the gaps are different on each platform. Choosing an Australian database region is necessary, but it doesn’t cover every service that touches personal information.

Service	Supabase (Sydney project)	Firebase (Australian locations chosen)
Main database	Sydney	Sydney or Melbourne
Authentication	In the project’s region, per Supabase’s security page	United States only, per Firebase’s privacy page
File storage	In the project’s region	Bucket location you choose
Functions	Run in the region closest to the caller unless you set Sydney with the x-region header or client option	The region you set per function; us-central1 if unset
Backups	Daily on paid plans: 7 days on Pro, 14 on Team	Backup schedules and point in time recovery are not automatic; you create them per database
AI features	Depends on the model provider you call	Firebase AI Logic with the Gemini Developer API is always global

Google’s Firebase privacy page states that Firebase Authentication runs only from US data centres and processes data exclusively in the United States. That covers email addresses, phone numbers, password data, user agents and IP addresses. For many apps that’s acceptable once disclosed in the privacy policy. For health, financial or government work where personal information has to stay onshore, it can rule out Firebase Auth, which pushes you to an alternative identity provider.

On Supabase, Edge Functions run near the user by default. That suits Australian users anyway, but a function invoked by an overseas user or webhook could run offshore unless you pin it to ap-southeast-2. Logs and metrics on either platform are operated by the vendor; check where they sit before promising a customer that nothing leaves Australia. Our guide to data residency vs data sovereignty explains why onshore storage alone doesn’t settle the legal question.

What does each cost at 1,000, 50,000 and 500,000 users?

At small scale both cost little; at large scale authentication and database load dominate, and the platforms bill them differently. Prices below come from each vendor’s pricing page at the time of writing and are in USD, ex GST.

The assumptions: each user is active monthly, reads about 1,000 documents or rows a month and makes 50 writes. Firestore is priced at the Sydney rates of US$0.038 per 100,000 reads and US$0.115 per 100,000 writes, after the daily free quota. Supabase is on the Pro plan (US$25 a month, including US$10 of compute credit), with compute sized up as load grows.

Monthly active users	Supabase Pro (Sydney)	Firebase Blaze (Sydney)
1,000	About US$25: plan with Micro compute covered by the credit	About US$0: inside free quotas for auth and Firestore
50,000	About US$75: plan plus Medium compute (US$60 less the US$10 credit)	About US$21: auth free up to 50,000 MAU; roughly 48.5 million billable reads and 1.9 million writes
500,000	About US$1,425: plan, Large compute (US$110 less credit) and 400,000 MAU above the included 100,000 at US$0.00325	About US$2,330: US$2,115 for Identity Platform MAU tiers plus about US$217 for Firestore operations

Treat these as illustrations, not quotes. Storage, file egress, phone SMS verification, functions and support plans are left out, and real read patterns vary by a factor of ten between apps. The useful lessons are structural. Firebase’s bill moves with how often your screens read data, so a badly designed feed can multiply it. Supabase’s bill moves with database size and active users, and a slow query shows up as needing a bigger server rather than a bigger invoice line. Supabase’s Free plan pauses projects after a week of inactivity, so it isn’t for production.

How do the security models compare?

Supabase uses Postgres row level security; Firebase uses its own security rules language. Both work, and both fail the same way: rules left open.

With Supabase, the browser or app talks to the database through an API, so every exposed table needs a row level security policy saying who can read and change which rows. The upside is that the rules live in the database and apply to every client, including reports and admin tools. With Firebase, rules sit in front of Firestore and Storage, written in Google’s rules syntax, and are tested with the Firebase emulator.

On vendor assurance, Supabase states it holds ISO 27001 certification and lists SOC 2 on its Team plan, with a HIPAA business associate agreement as a paid add on. Firebase services inherit Google Cloud’s security programme. Neither attestation makes your app secure; the rules you write do. This is the single most common problem we see when reviewing apps generated with AI coding tools, covered in making an AI built app production ready.

Which handles mobile and offline better?

Firebase, clearly. Firestore’s Android and Apple SDKs cache the data the app is using and sync changes when the device reconnects, with offline persistence on by default. Conflicts resolve as last write wins.

Supabase has mobile client libraries, including Flutter and Swift, but no built in offline sync. Field apps on Supabase usually add a local database and a sync engine. That is a sound pattern and gives you more control over conflicts, but it is extra work. If your users work in sheds, basements or regional areas without signal, read our guide to offline first field apps before choosing.

How hard is it to leave each one?

Leaving Supabase is a database migration; leaving Firebase is usually a partial rebuild.

A Supabase project is a Postgres database underneath, so you can dump it and restore it on Amazon RDS, Azure Database for PostgreSQL or Google Cloud SQL with standard tools. Supabase is also open source and can be self hosted, though Supabase notes that self hosting drops managed backups, point in time recovery, branching and some platform features. Auth, storage paths and Edge Functions need rework wherever you move.

Firestore has no standard equivalent elsewhere. Moving off it means designing tables from documents, rewriting every query, translating rules and migrating users. That isn’t a reason to avoid Firebase, only a cost to weigh if the product could grow into something with heavy reporting.

Which should you pick for your product?

Match the platform to the shape of your data and your residency needs.

1. Business system, portal or SaaS with relational data and reporting: Supabase in Sydney.
2. Consumer mobile app, chat or social feed with offline use and push messaging: Firebase, with Firestore in Sydney or Melbourne and every function region set.
3. Personal information that must stay onshore, including sign in data: Supabase in Sydney, or Firebase data with a different identity provider.
4. Government, defence or highly regulated work: consider neither as the core; a managed Postgres in your own AWS, Azure or Google Cloud account gives you the controls and assessments those buyers ask about.
5. A quick prototype to test demand: either; pick the one your developer knows and set the region on day one.

How AWLabs approaches this

We build on both, and on plain Postgres in the client’s own cloud account, so the recommendation comes from the product, not a preference. We use Australian regions where data needs to stay onshore, as agreed in the Schedule of Work, and we write down which services sit outside that boundary, such as authentication or logs. Senior engineers lead every build, including the security rules and policy tests. See backend development, our startup MVP approach, or how to choose a tech stack for the wider decision.