Why we chose Firestore for the production pipeline

When you're building a creator tool the data shape changes constantly. A scene gains a cliffhanger field. A shot gets a video clip. A project starts carrying a breakdown. Postgres + an ORM means a migration every time, and migrations are how good products get slow.

So we picked Firestore. Trade-offs are real, and worth being honest about.

What we gained

• Schema agility. Every document is JSON. Adding shot.metadata.videoVariants[] was a one-line change, not a migration.
• Real-time without infrastructure. Firestore's onSnapshot is the cheapest way we know to ship live multi-user editing later.
• Owner-based sharding for free. projects.where("ownerId", "==", ...) scales without any partitioning code on our side.

Where Firestore hurts

• No aggregations beyond count. Want average shot duration across all owners? Write a Cloud Function.
• Composite indexes are eventually consistent in dev. We've had two prod incidents where a new query worked locally and died on Cloud Run for 90 seconds while the index built.
• where field == null doesn't match missing fields. Burned us on legacy library_items. We now coerce in the converter.

What we'd do differently

Two changes if we were re-architecting:

1. Pay the upfront cost of writing converters for every type from day one (we backfilled half of these).
2. Run more queries through a thin service layer rather than directly in route handlers — makes "swap Firestore for X" possible later without rewriting every route.