Firebase made backends easy: auth, a realtime database, storage and hosting behind a friendly SDK. But two things push Australian teams to look elsewhere — the classic complaints (NoSQL lock-in, unpredictable scaling costs, thin querying) and the one that's specific to us: Firebase is a Google product, and Google is a US company.
That matters because of a distinction most comparison articles miss entirely. So before the list, the one rule that reorders it.
The rule that reorders every list
- Data residency = where servers physically sit (geography).
- Data sovereignty = whose government can compel access (jurisdiction).
- A US provider's Australian region gives residency, not sovereignty.
- Under the US CLOUD Act, a US-incorporated provider can be compelled in any region.
- So "hosted on the Sydney region" is not the same as "beyond US reach."
Why Firebase struggles on Australian sovereignty
Firebase runs exclusively on Google Cloud and cannot be self-hosted. Its core databases — Realtime Database and Cloud Firestore — offer limited region control, and even where an Australian location exists, Google Inc. remains US-incorporated. Under the US CLOUD Act, US authorities can compel a US company to produce data it holds anywhere in the world. Choosing a nearby region changes latency, not jurisdiction. For a team handling health, legal, financial, education or government data, that's usually a disqualifier before the feature comparison even begins.
The contenders, ranked by what Australian teams actually need
Supabase — the open-source favourite
Supabase is the most popular Firebase alternative and, for most teams, the better product: it's built on PostgreSQL (portable, powerful, no NoSQL lock-in), it's open-source, and it can be fully self-hosted with Docker. The catch for us is that Supabase Inc. is US-incorporated (Delaware), so its hosted cloud carries CLOUD Act exposure even in the Sydney region. Self-hosting Supabase on Australian infrastructure restores sovereignty — at the cost of running it yourself. We go deep on this in WattleDB vs Supabase.
Appwrite — self-host everything
Appwrite is an open-source backend server packaged as Docker microservices exposing REST, WebSocket and GraphQL. Its pitch is control: deploy it anywhere, own everything, no platform fee — you pay only for your own infrastructure. Self-hosted on Australian-owned servers, it gives you residency and sovereignty. The trade-off, as with any self-host, is that the DevOps is yours: scaling, patching, backups, on-call.
PocketBase — the single-binary minimalist
PocketBase bundles a SQLite database, auth, file storage and an admin UI into one Go binary. It's a delight for small projects and prototypes, and being self-hosted it's as sovereign as the box you run it on. The limits are inherent: SQLite and a single binary suit small-to-mid workloads, not high-concurrency multi-tenant SaaS.
Nhost & Hasura — GraphQL-first
Nhost bundles Postgres, Hasura GraphQL, auth and storage; Hasura on its own gives you instant GraphQL over Postgres. Both are open-source and self-hostable on Australian infrastructure. If your team is GraphQL-native they're excellent — you're still, however, assembling and operating the stack yourself to keep it sovereign.
WattleDB — sovereign by construction
The options above make you choose: convenience (a US-owned managed cloud) or sovereignty (self-host it yourself). WattleDB removes that trade-off. It's a 100% Australian-owned Backend-as-a-Service — managed PostgreSQL, auto-generated REST and GraphQL APIs, authentication, S3-compatible storage and transactional email — hosted on Australian-owned infrastructure in Sydney and Melbourne. Because RR Sols Pty Ltd has no foreign parent, there is no US entity anywhere for the CLOUD Act to compel. You get the managed convenience and the sovereignty, without running servers.
Side by side: the sovereignty axis
| Platform | Core DB | Self-host? | Company jurisdiction | Managed & sovereign in AU? |
|---|---|---|---|---|
| Firebase | Firestore (NoSQL) | No | US (Google) | No |
| Supabase | PostgreSQL | Yes | US (Delaware) | Hosted cloud: no |
| Appwrite | MariaDB | Yes | US-incorporated | Self-host only |
| PocketBase | SQLite | Yes | Open-source (self-run) | Self-host only |
| Nhost / Hasura | PostgreSQL | Yes | US-incorporated | Self-host only |
| WattleDB | PostgreSQL | Managed | Australian Pty Ltd | Yes — by construction |
Corporate details reflect publicly available information at time of writing and can change — always verify a provider's current ownership before relying on it for a sovereignty claim.
How to choose
- No sovereignty requirement? Any of these can work; pick on features and pricing. Supabase is the safe, portable default.
- Sovereignty required, happy to run infrastructure? Self-host Supabase or Appwrite on Australian-owned servers.
- Sovereignty required, want it managed? Use a natively sovereign BaaS — WattleDB — so you get onshore control without the DevOps.
- Leaving Firebase specifically? Moving to Postgres (Supabase or WattleDB) also frees you from NoSQL lock-in and metered-scaling surprises.
If sovereignty is a real requirement, the honest shortlist is: self-host an open-source option, or use a provider that is Australian-owned end to end. Everything else is residency wearing a sovereignty badge.
New to building the backend at all? Start with How to build a SaaS in Australia, then the deep dive on data sovereignty.