Platform hub

Firebase limits

Functions, Hosting, and Firestore duration, request, document, and index limits. Values below are scoped rather than flattened into one misleading platform-wide number.

Verified Aug 22, 2026Official docs
Quick answer:  Firebase has multiple independent constraints. Match the exact plan, model, runtime, invocation mode, or server configuration shown in each row.

Current documented limits

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

How to apply Firebase limits safely

The monitored baseline covers generation-specific function duration, Hosting request timeout, document size, maximum API request, transaction duration, index configuration and entries. Treat these as separate constraints rather than one platform-wide capacity number: a workload can fit one row and still fail another because the plan, model, endpoint, runtime, region, invocation mode, or account scope differs.

  1. Match the production workload to the exact scope printed beside each value and confirm it in the active Firebase console, configuration, or response headers.
  2. Measure the serialized request, token volume, duration, concurrency, storage, or connection demand at realistic percentiles, then preserve headroom for bursts and retries.
  3. Check every adjacent layer—client, SDK, gateway, proxy, queue, database, and downstream service—for a smaller effective limit before changing architecture.

Specific limit pages

These pages exist because the constraint has a distinct implementation or troubleshooting intent. Closely related keyword variations stay consolidated.

Official sources

View Firebase change history