The studio defaults to Firestore in Native Mode as the primary database. It's a serverless document store with real-time listeners, fine-grained security rules and global replication out of the box. For a small team it removes most of the operational work that comes with running a Postgres cluster.
Where Firestore wins
- Real-time listeners — every client surface gets push updates without a separate message bus
- Security rules — declarative, testable, enforced at the storage layer
- Zero ops — no Postgres pool tuning, no replica failover, no upgrade windows
- Global replication — multi-region writes for partners who need them
- Cost — single-digit dollars a month at the studio's current traffic
Where Postgres wins (and when we pick it)
Firestore loses to Postgres when a project needs complex joins, strong relational constraints, or aggregation queries at scale. For analytics and reporting we export Firestore to BigQuery via the Firestore-to-BigQuery extension and run SQL there — that covers most "I need joins" use cases without changing the primary store.
The studio reaches for Cloud SQL Postgres only when a project genuinely needs SQL constraints from day one — invoice-driven products, marketplaces with strong consistency requirements, anything that ages into a financial system. Most products don't.
Schema rules of thumb
- Denormalise hot paths — duplicate fields the UI reads frequently
- Normalise rarely-touched fields — they can be a join away
- One document per user-facing entity, not per database row
- Use subcollections for unbounded one-to-many; arrays for bounded
The honest case against Firestore
It would be dishonest to pretend Firestore wins everything. Complex reporting queries are painful — there are no joins, no GROUP BY, no ad-hoc analytics. Aggregations need either denormalised counters you maintain yourself or an export to BigQuery. If your product is fundamentally a reporting tool, Firestore is the wrong primary store and we will tell you so. Picking it by default does not mean picking it blind.
A rule of thumb for the choice
Ask one question: does this product need joins and constraints to be correct, or just to be convenient? A banking ledger needs them to be correct — pick Postgres. A fitness app, a social feed, a messaging product needs them only for occasional reporting — pick Firestore and export to BigQuery for the analytics. We have made both calls; the mistake is making the choice by habit instead of by the shape of the data.