Set Up Your Project Database

Flash Launch now treats project data as a provider-based capability.

In the current MVP:

• Firestore is the active provider and the default recommendation
• Cloud SQL Postgres stays visible in the UI as a disabled Coming soon option
• the underlying Firestore database is shared across the platform, while each project gets its own namespace under project_data/{projectId}/...

This is an intentional product change. The MVP is optimizing for a lower-cost, easier-to-operate default data path without pretending that Firestore is the same thing as a relational database.

What happens when you click `Set Up Firestore`

The Database page does not create a separate Firestore database for each project.

Instead, it provisions a project-scoped namespace inside the shared platform Firestore database:

• root document: project_data/{projectId}
• user-facing collections live under that root, for example:
• project_data/{projectId}/users/{docId}
• project_data/{projectId}/orders/{docId}

The platform also prepares provider metadata so the dashboard can:

• show the namespace root
• browse collections and documents
• edit JSON documents safely
• manage project-scoped rules and index drafts

Why the MVP uses Firestore first

The Firestore-first path exists because it matches the current product goal more closely than always-on managed Postgres infrastructure.

For the MVP, Flash Launch wants:

• a lower fixed cost baseline
• a simpler setup model
• a data surface that still lets users store real project state
• a console that helps users understand where their project data lives

That does not mean Firestore replaces SQL forever. It means the MVP now starts with the cheaper and simpler managed document-store path, while keeping the relational path visible for future support.

Provider chooser: what the UI means

The Database Providers section now shows two cards:

The Cloud SQL card is not decorative. It communicates the product roadmap honestly:

• relational support is planned
• the previous Cloud SQL implementation still exists internally
• the MVP is not using it as the active path right now

Firestore console tabs

When Firestore is active for a project, the Database page exposes four tabs:

`Overview`

Shows:

• provider status
• namespace root
• collection count
• configuration status
• last published config timestamp

`Collections`

Shows the immediate collections under the project namespace root, for example:

• users
• drafts
• events

This is a lightweight browser, not a general-purpose Firestore query builder.

`Document Editor`

Lets you:

• load a project-relative document path such as users/user-1
• replace a full JSON document
• patch fields into an existing document
• delete a document

The editor works with project-relative paths, but the platform stores them under:

• project_data/{projectId}/...

`Rules & Indexes`

This tab is project-scoped, but the underlying Firestore database is shared. That matters.

The platform stores:

• a rules template choice
• template settings
• an optional advanced raw rules fragment
• managed composite index definitions as JSON
• validation state
• last published shared revision metadata

Rules and index publishing: what is real today

This is the honest product contract for the MVP:

• rules and indexes are saved as project-scoped drafts
• publishing first runs synchronous validation and freezes a shared release artifact
• the platform then queues an async job that deploys Firestore rules and managed composite indexes to the configured named database
• invalid drafts and unsupported index definitions are rejected before the job is queued
• the shared deploy target is the Firestore database configured by GCP_PROJECT_ID + FIRESTORE_DATABASE_ID

Because the Firestore database is shared, this is not a per-project isolated rules deployment system. It is a platform-managed draft-and-publish layer that helps users work with shared Firestore safely during the MVP.

What “publish” now means in practice:

• rules are released through the Firebase Rules API
• managed composite indexes are reconciled through the Firestore Admin API
• the dashboard shows publishing while the background job is still running
• propagation can take time, especially when new composite indexes are being built

What is intentionally still out of scope:

• single-field index overrides are not modeled in the current MVP
• SQL migrations, connection strings, and relational tooling remain Cloud SQL-only concepts
• this is still not a Postgres replacement layer

Status values

The provider-aware database lifecycle still uses a small state model:

For Firestore, active means:

• the namespace root exists
• the project can browse collections/documents
• rules and indexes can be drafted from the dashboard

Deleting Firestore

Deleting Firestore from the project page is intentionally destructive.

It removes:

• all documents under the project's namespace
• saved rules/index drafts for that project
• related cached demo metadata held by the control plane

It does not mean:

• deleting the shared platform Firestore database
• enabling Cloud SQL automatically afterward

Current limitations

• Firestore is the current default provider, not a complete backend framework
• the console supports document CRUD, not arbitrary Firestore query composition
• rules and indexes are managed as shared-platform drafts with async remote deploy
• only managed composite indexes are authoritative in the current publish workflow
• Cloud SQL is visible but intentionally disabled in the MVP UI

Related docs

• What Flash Launch Is
• Set Up Firestore for a Project
• Browse and Edit Firestore Data
• Manage Firestore Rules and Indexes