Change history

Firebase limit changes

Current and previous observations remain linked to their official sources. Detection date and effective date are kept separate when known.

Verified Aug 22, 20260 verified changes

Verified history

No verified historical change is recorded yet.
This means HyperObserve has not found sufficient first-party evidence for a dated before-and-after event. It does not mean Firebase has never changed. Undated values are kept in the current baseline below instead of being presented as history.

Current monitored baseline

HyperObserve currently monitors 6 scoped observations for Firebase. The baseline covers generation-specific function duration, Hosting request timeout, document size, maximum API request, transaction duration, index configuration and entries. Each value retains its plan, product, endpoint, region, account, or runtime qualifier so a future change can be compared against the correct scope.

ConstraintCurrent valueScopeVerified source
generation-specific function durationGeneration and trigger type determine the ceiling.1st gen: 540s; 2nd gen HTTP: 60m; scheduled: 30m; event: 540sCloud Functions for FirebaseFirebaseAug 22, 2026
Hosting request timeoutThe Hosting request can time out before a longer Cloud Run backend maximum.60 secondsHosting rewrites to serverlessFirebaseAug 22, 2026
document sizeIndex entries and field-value indexing have separate size constraints.1 MiBCloud FirestoreFirebaseAug 22, 2026
maximum API requestTransactions and commits also have time and transformation constraints.10 MiBCloud FirestoreFirebaseAug 22, 2026
transaction durationIdle time can end a transaction well before the total-duration ceiling.270 seconds; 60-second idle expirationCloud FirestoreFirebaseAug 22, 2026
index configuration and entriesSingle-field configurations and entry byte sizes impose additional ceilings.200 composite indexes without billing; 1,000 with billing; 40,000 entries/documentCloud FirestoreFirebaseAug 22, 2026

Tracked constraints and impact

Functions, Hosting, and Firestore duration, request, document, and index limits. A change is recorded only when it alters a constraint developers can act on, such as capacity planning, request shaping, model selection, deployment configuration, storage design, retry behavior, or account budgeting.

How a change is verified

  1. Compare the current first-party statement with the previously stored observation, including the exact plan, model, runtime, endpoint, region, and account scope.
  2. Separate a true product change from documentation clarification, temporary capacity, configurable account state, or a limit that applies to a different execution path.
  3. Preserve the old and new values, official source, effective date when disclosed, detection date, and practical impact. If those elements cannot be supported, no historical event is published.

Official sources monitored

These first-party documents support the current Firebase baseline. HyperObserve links directly to them so you can confirm the live wording before making a production decision.

Cloud Functions for Firebase quotas

Generation-specific duration, memory, networking, and event limits

Firebase Hosting serverless overview

Hosting request timeout and concurrency

Cloud Firestore usage and limits

Document, transaction, request, index, rules, and export limits

Related

Continue researching Firebase