Firestore made it wonderfully easy to ship a first app: no schema, real-time sync, and a generous free tier. But the decision you make at prototype stage becomes the foundation your business runs on — and for many Australian teams, three things start to bite as they grow: the data model fights back, the bill gets unpredictable, and a procurement questionnaire asks a sovereignty question the answer can't survive. Here's how PostgreSQL and Firestore actually compare on the axes that decide the long game.
The short version
- Firestore is a document database; PostgreSQL is relational — the difference shows up everywhere.
- Postgres gives you joins, transactions and complex queries; Firestore trades them for horizontal scale.
- Firestore bills per operation — cost is hard to forecast; managed Postgres is fixed and predictable.
- Firestore is a Google (US) product — Australian region, but not Australian sovereignty.
- Postgres has no vendor lock-in and native JSONB when you do want document shapes.
The core difference: relational vs document
Firestore stores data as collections of JSON-like documents. There is no fixed schema, and you scale by keeping access patterns simple and denormalised — you often duplicate data so a screen can be served by a single lookup. PostgreSQL stores data as rows in typed tables with relationships between them, and lets the database enforce structure, uniqueness and referential integrity. One optimises for schemaless writes at scale; the other for correctness and expressive querying.
Head to head
| Google Firestore | PostgreSQL | |
|---|---|---|
| Data model | NoSQL documents / collections | Relational tables (+ JSONB documents) |
| Schema | Schemaless | Enforced schema, constraints, types |
| Joins & relations | Limited; denormalise instead | Full joins, foreign keys |
| Transactions | Limited multi-doc | Full ACID transactions |
| Querying | Simple, index-bound queries | Rich SQL: aggregates, windows, CTEs |
| Pricing model | Per read / write / delete + storage + egress | Fixed resource-based plan |
| Vendor lock-in | Proprietary Google API | Open source, portable |
| Sovereignty | AU region, but US-owned (CLOUD Act) | Sovereign when AU-owned host |
Data modelling: joins vs denormalisation
The relational model earns its keep the moment your data has relationships — customers with orders, patients with appointments, projects with tasks. In Postgres you model each entity once and join when you read. In Firestore you typically denormalise: copy the data you need into each document so reads stay cheap, then carefully keep those copies in sync on every write. That works, but it pushes integrity into your application code, where bugs are easier to introduce and harder to catch.
Queries and transactions
Firestore queries are deliberately constrained — every query must be backed by an index, and there are no joins or aggregations across collections. For dashboards, reporting and anything analytical, you end up exporting to another system. PostgreSQL runs the full breadth of SQL — aggregates, window functions, CTEs — directly against live data, and wraps multi-row changes in ACID transactions so money-movement and booking logic are correct under concurrency. If your app has business rules, that guarantee is hard to give up.
Cost: predictable vs per-operation
This is where teams get surprised. Firestore bills for every document read, write and delete, plus storage and egress. A list screen that reads 50 documents, refreshed by a few thousand users, is hundreds of thousands of billable reads — and a fan-out write pattern multiplies quickly. Managed PostgreSQL is typically priced on a fixed plan (CPU, memory, storage), so your cost is known in advance and scales in steps you choose, not per operation.
Firestore's bill scales with how many times you touch your data. Postgres's bill scales with how much database you rent. Only one of those is easy to forecast.
The sovereignty dimension
Firestore offers Australian locations, which gives you data residency. But Firestore is a Google product, and Google is US-incorporated — so the data remains reachable under the US CLOUD Act regardless of region. That's residency without sovereignty, and it's exactly the gap that trips Australian teams in regulated procurement. A PostgreSQL database hosted by an Australian-owned provider with no foreign parent keeps data under Australian jurisdiction. We unpack the distinction in Data sovereignty in Australia.
When Firestore still makes sense
None of this makes Firestore wrong. If you're shipping a simple real-time mobile prototype, your data is genuinely document-shaped and shallow, you don't need cross-entity reporting, and sovereignty isn't in scope — Firestore's zero-config start is a real advantage. The trouble is that these early-stage conveniences quietly become foundations, and re-platforming a live app is far more expensive than choosing well up front.
"But I like documents" — Postgres does those too
A common reason teams reach for Firestore is the flexibility of schemaless documents. PostgreSQL has native JSON and JSONB types with indexing, so you can store and query document-shaped data where it genuinely helps — user preferences, event payloads, flexible metadata — while keeping typed relational tables, joins and transactions for everything else. You don't have to choose flexibility or integrity; you get documents where they help and guarantees everywhere else.
Migrating from Firestore to Postgres
Moving over means designing a schema and transforming documents into rows: flatten nested structures into related tables, or drop genuinely document-shaped blobs into JSONB. It's more involved than a like-for-like swap, but it's a one-time cost that removes NoSQL lock-in and the per-operation bill for good — and it hands you SQL, relations and Row-Level Security in return.
WattleDB: managed Postgres, Australian-owned
WattleDB gives you managed PostgreSQL on 100% Australian-owned infrastructure in Sydney, with cross-state backups in Melbourne and flat AUD pricing. You get a real relational database — joins, transactions, JSONB, Row-Level Security — with an auto-generated REST API on top, and none of the CLOUD Act exposure that comes with a US-owned document store. It's the Firestore alternative for teams that want the developer convenience and Australian sovereignty. See how it compares to Supabase in WattleDB vs Supabase.