Skip to content

Data Structure

Data is backed by Google Cloud Firestore, a no-SQL, document-oriented database. Firestore operates with documents (key-value sets) organized into collections and sub-collections.

We use a Hybrid Partitioning Strategy to support multitenancy while sharing global FRC data.


  • Purpose: Public data sourced from official APIs (TBA/FIRST).
  • Access: Read-only for all authenticated users.
graph TD
    Root((/metadata))
    Seasons[seasons]
    SeasonDoc[2026]
    Events[events]
    EventDoc[2026oncmp]
    Matches[matches]
    Teams[teams]
    Schemas[schemas]

    Root --> Seasons
    Seasons --> SeasonDoc
    SeasonDoc --> Events
    SeasonDoc --> Teams
    Events --> EventDoc
    EventDoc --> Matches
    Root --> Schemas

  • Purpose: Private data owned by specific FRC teams.
  • Access: Isolated by Team Membership (RBAC).
graph TD
    Root((/tenants))
    TenantDoc[tenantId]
    Users[users]
    Matches[matches]
    Surveys[surveys]
    Pits[pits]
    Picklist[picklist]

    Root --> TenantDoc
    TenantDoc --> Users
    TenantDoc --> Matches
    TenantDoc --> Surveys
    TenantDoc --> Pits
    TenantDoc --> Picklist

  • Purpose: Platform-level configuration and global admin management.
  • Access: Restricted to Superusers only.
graph TD
    Root((/system))
    Superusers[superusers]
    UID[uid]

    Root --> Superusers
    Superusers --> UID

  • Isolation: Tenant data is physically separated. A query for “All Matches” is naturally scoped to a specific team’s partition.

  • Referential Integrity: Tenant documents often reference metadata keys (e.g., a scouting report references a matchKey from the global partition).

  • Auditability: Every document in the tenant partition typically includes createdAt, updatedAt, and createdBy (UID) fields for tracking.

  • Schema Versioning: The /metadata/schemas collection allows the UI to dynamically adapt to different game rules for each season without code changes.