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