Firebase Free Tier Limits: Every Limit Documented
The Firebase Spark plan is genuinely generous for small projects, but the limits are spread across multiple services and can be confusing. Here is every free tier limit and strategies to maximize what you get without paying.
Complete Free Tier Limits
| Service | Limit | Reset |
|---|---|---|
| Firestore reads | 50,000/day | Daily |
| Firestore writes | 20,000/day | Daily |
| Firestore deletes | 20,000/day | Daily |
| Firestore storage | 1 GB | Continuous |
| Cloud Storage | 5 GB stored | Continuous |
| Cloud Storage downloads | 1 GB/day | Daily |
| Hosting storage | 10 GB | Continuous |
| Hosting bandwidth | 360 MB/day | Daily |
| Authentication | 10,000 MAU | Monthly |
| Realtime Database storage | 1 GB | Continuous |
| Realtime Database downloads | 10 GB/month | Monthly |
| Cloud Functions | Not available | N/A |
| Test Lab | 5 tests/day (virtual) | Daily |
The Limits That Matter Most
50,000 Firestore Reads Per Day
This sounds generous but fills up fast. A user viewing a feed with 20 items performs 20 reads. If they view 3 pages, that is 60 reads per session. At 60 reads per user, 50,000 daily reads supports about 833 daily active users. For apps with real-time listeners (chat, collaborative documents), each listener counts reads continuously, which can exhaust the limit much faster than expected.
1 GB Firestore Storage
One gigabyte fills quickly with image metadata, user profiles, and nested document structures. Firestore stores field names in every document, so verbose field names waste storage. A collection of 100,000 documents with 10 fields each can easily reach 500MB to 1GB depending on field sizes. Do not store binary data (images, files) in Firestore; use Cloud Storage instead.
No Cloud Functions on Spark
This is the most limiting constraint. Without Cloud Functions, you cannot run server-side logic, send push notifications triggered by database changes, run scheduled tasks, or implement webhooks. Any app that needs backend processing must upgrade to Blaze. The workaround is to use external services (Vercel serverless functions, AWS Lambda) that connect to Firebase client-side, but this adds complexity.
Optimization Strategies to Stay on Free Tier
Cache Firestore Data Client-Side
Store frequently accessed data in memory or local storage to avoid repeated Firestore reads. If a user views the same document multiple times in a session, read it once and cache it. Firestore SDK has built-in persistence for offline access, which also reduces server reads when returning to previously loaded data.
Compress Images Before Upload
Resize and compress images client-side before uploading to Cloud Storage. A 5MB photo from a phone can be compressed to 200KB without visible quality loss. This reduces storage consumption by 25x, keeping you well within the 5GB free limit for much longer.
Use Firebase Hosting for Static Content
Serve static HTML, CSS, JS, and images through Firebase Hosting (10GB storage, 360MB/day transfer) instead of Cloud Functions for server-side rendering. Static hosting is free and fast. Only use Cloud Functions (which require Blaze) for truly dynamic server-side operations that cannot be handled client-side.
Use Short Field Names in Firestore
Firestore stores field names in every document. Using "firstName" (9 bytes) versus "fn" (2 bytes) across 100,000 documents wastes 700KB just in field names. For high-volume collections, shorter field names meaningfully reduce storage consumption. Use clear but concise names.