Back to Blog

Is Firebase Production Ready in 2026?

In this article

• Quick Answer
• Key Takeaways
• Who Actually Runs Firebase in Production
• What Does Production Ready Actually Require
• Where Are the Real Scaling Limits
• What Are the Surprise Bills and Footguns
• Should You Fix in Place or Migrate Off
• What Changed in 2025 and 2026
• How We Decide With Clients
• Where These Numbers Come From
• Frequently Asked Questions

Firebase is a set of managed services around two databases, Firestore and the Realtime Database, plus authentication, storage, hosting and functions. It has been in production at serious scale for over a decade, so the question is not whether it works. The question is whether its limits and its billing model fit your workload, because Firebase fails differently from a Postgres platform. This guide gives the honest version, grounded entirely in what Google itself publishes.

We wrote the same guide for Supabase, and the comparison is instructive, because the two platforms have almost inverted shapes.

Who Actually Runs Firebase in Production

Google names NPR, Halfbrick, Duolingo and Venmo on the Firebase homepage as teams that use it to build and ship. Its own case studies map named companies to specific products, LaHaus with Crashlytics and Performance Monitoring, Classkick with the Realtime Database and Cloud Storage, FAVES with the Realtime Database and Cloud Functions, and MOIA with Remote Config and Test Lab.

Worth being straight about what that evidence is and is not. Google publishes no throughput or user count figures alongside those names, so they establish that credible companies ship on Firebase and nothing more precise. The Authentication case studies are about speed of adoption rather than scale, with Fabulous reporting an implementation in one afternoon and Rave reporting one to two days on the client and an hour on the server.

What Does Production Ready Actually Require

Four things, and Firebase answers them unevenly.

A committed uptime figure. Firestore publishes a strong one, at 99.999 percent or better for multi region and 99.99 percent or better for regional configurations, with service credits at 10, 25 and 50 percent. Regional configurations in Mexico and Stockholm sit at 99.95 percent instead, while multi region stays at 99.999 percent. The older Firebase service level agreement, which covers the Realtime Database and Hosting, was last updated in April 2020 and commits to 99.95 percent using commercially reasonable efforts. That phrase is doing work and you should read it before relying on it.

Compliance coverage. This is where Firebase is thinner than teams expect. There is no mention of HIPAA or PCI anywhere on the Firebase privacy and security page. If you are building in regulated healthcare or handling card data directly, that absence is the answer.

Predictable cost. Firebase does not offer this, by design. See the billing section below.

An exit. Also weak. See the migration section.

Where Are the Real Scaling Limits

Firestore inverts the usual shape. Where a Postgres platform hits a vertical ceiling, Firestore has no published maximum writes per second per database at all, and Google states in its real time queries documentation that automatic scaling lets you increase write traffic without limits. The string per second does not appear in its quotas page.

What it does publish is a ramp rule and a warning. The best practices documentation describes starting at a maximum of 500 operations per second to a new collection and increasing traffic by 50 percent every 5 minutes, which it calls the 500/50/5 rule, and warns that ramping writes too quickly leads to contention and performance problems. It also documents that indexing a field which increases or decreases sequentially between documents, such as a timestamp, caps the collection at 500 writes per second. That single sentence explains a large share of real world Firestore performance complaints.

The hard limits that do exist are per document rather than per database. A document is capped at 1 MiB, a single field value slightly under that, index entries at 40,000 per document with an 8 MiB total size, subcollection depth at 100, and map or array nesting at 20. Transactions run 270 seconds with a 60 second idle expiry, and a single commit or transaction can apply 500 field transformations to one document. Composite indexes cap at 200 or 1,000 depending on configuration and databases at 100 per project, all raisable through support.

The Realtime Database is the opposite, with clearly published ceilings. It caps at 200,000 simultaneous connections, around 100,000 responses per second and 1,000 writes per second, though Google notes the write figure is not a hard limit and activity may be rate limited instead. Data nesting caps at 32 levels. Google recommends scaling by sharding across multiple databases, and notes that an app with 10 million monthly active users usually sits under the 200,000 connection limit.

Cloud Functions add their own constraints. First generation functions time out at 540 seconds with 8 GiB of memory. Second generation goes to 60 minutes for HTTP functions, 540 seconds for event driven ones, with 32 GiB. The instance cap is 1,000 functions per region for first generation, and for second generation it is 1,000 minus the number of Cloud Run services already deployed, which is a subtlety worth knowing before you plan a large deployment. Cold starts are documented explicitly, and Google recommends setting a minimum number of instances for latency sensitive applications, which costs money while idle.

What Are the Surprise Bills and Footguns

This is the section that matters most, because it is where Firebase differs from everything else in the category.

Firestore charges per document read. In Iowa that is 0.03 dollars per 100,000 reads, 0.09 per 100,000 writes, 0.01 per 100,000 deletes and 0.15 dollars per GiB per month of storage. Multi region nam5 is double the Iowa rate for reads, writes and deletes, and 0.18 dollars per GiB for storage. Those are small numbers, which is exactly why the failure mode is surprising.

The reads are not always the ones you would count. Google documents all of the following.

• Every query costs a minimum of one read, even when it returns nothing.
• A query with an offset of 10 that returns a single document is charged 11 reads, because you pay for the documents you skipped. Cursors are the documented alternative.
• A real time listener in a mobile or web SDK with offline persistence enabled that disconnects for more than 30 minutes is billed as an entirely new query when it reconnects, covering documents and index entries. Without offline persistence you are billed that way on every disconnect and reconnect, which is worse rather than better.
• Aggregation is metered in index entries at 1,000 per read unit, so a count that scans 1,500 index entries bills as two document reads.
• Security rule evaluation is billed, once per request, and charged again on a listener when results update, the device reconnects, the rules change, or dependent documents change.

Google itself names the two classic causes of a runaway bill, which are forgetting to add a limit to a query with millions of results, and combinations of Cloud Functions that cause excessive fan out or infinite loops.

Now the uncomfortable part. There is no hard spend cap for Firestore. Cloud Billing budgets and alerts do not cap usage, and Google states they can lag by up to a few days. A spend cap feature exists for exactly four services, Firebase AI Logic, App Hosting, Cloud Functions and Extensions, Google states plainly that these are not hard caps, and Firestore is not among them. So the only real controls are architectural, which means always setting a limit, using cursors instead of offsets, watching fan out in functions, and alerting on read volume rather than on cost.

We have deliberately not quoted a dollar figure for any runaway bill story. Google documents the causes and the unit prices but publishes no incident amounts, and the third party figures that circulate are not traceable to a primary source.

One more billing change landed today. Remote Config moved to a published pricing structure with effect from 1 September 2026. It stays free to 100,000 fetch requests per day on both plans, then on Blaze costs 0.000006 dollars per request up to 10 million per day and 0.000001 above that. Existing projects get grace periods running into 2027. Most projects will pay nothing, but it is no longer an unmetered product.

Should You Fix in Place or Migrate Off

Fix in place in most cases, because the majority of Firestore problems are query design rather than platform limits. Add limits, replace offsets with cursors, denormalise to avoid fan out reads, review your listener lifecycle, and check whether a sequentially indexed field is capping your write throughput. Those five changes resolve most of what teams blame on Firebase.

Migrate when the mismatch is structural. Three cases qualify. If you need genuine relational queries with joins across normalised tables, a document store is the wrong tool and no amount of tuning changes that. If you need forecastable monthly costs for a finance function that will not accept a variable read bill with no cap, the billing model is the problem rather than the implementation. And if you are in regulated healthcare or handling card data, the absence of published HIPAA and PCI coverage settles it.

Be clear eyed about the cost of that migration. A Firestore managed export writes LevelDB files with protobuf metadata, which is designed to be imported back into Firestore rather than read as a portable dump. Google also documents that an export is not a guaranteed point in time snapshot, that you are charged one document read for every document exported, and that loading into BigQuery requires a collection ids filter. So a full export of a large database has a real bill attached before you have converted a single record. That is the honest lock in picture, and it is the strongest argument for deciding early rather than late. Our backend as a service pricing comparison covers what leaving costs across the whole category.

What Changed in 2025 and 2026

Firebase has been reshaped around Google Cloud and Gemini, and several products are on the way out. All dates are Google published.

• Firebase Data Connect became Firebase SQL Connect on 22 April 2026. Google states the features and APIs are unchanged. It is managed PostgreSQL powered by Cloud SQL, free to 250,000 operations per month on Blaze then 0.90 dollars per million, with the Cloud SQL instance billed separately.
• Firestore Enterprise edition arrived in August 2025 with MongoDB compatibility and a new query engine, reached Native mode in all supported regions in March 2026, and had pipeline operations reach general availability in April 2026. It bills on read units rather than documents, at 0.05 dollars per million 4 KiB read units, with write units at 0.26 per million and storage at 0.24 dollars per GiB per month. Indexes become optional, and single field indexes are no longer created automatically.
• Firebase Studio is being retired. It sunsets on 22 March 2027, and new workspace creation and signup have been disabled since 22 June 2026. Google is explicit that the core Firebase products are not affected and directs users to Google AI Studio or Antigravity.
• Firebase Extensions were deprecated on 20 July 2026 and sunset on 31 March 2027. Deployed extensions keep executing indefinitely, but after that date you cannot update, reconfigure or uninstall them through the console or CLI.
• Firebase ML was deprecated on 11 June 2026 and shuts down on 15 June 2027. Projects not already using it cannot start.
• Cloud Storage now requires Blaze, since 3 February 2026.
• Dynamic Links shut down on 25 August 2025, with errors phased in rather than switched on at once.
• Genkit is Google open source framework for AI and agentic applications, with TypeScript and Go stable and Python and Dart in preview. Firebase AI Logic hybrid on device and cloud inference reached general availability for web apps on 28 May 2026.

One naming point for procurement conversations. Vertex AI is now the Gemini Enterprise Agent Platform, and Google uses that label across its own pricing and billing pages. It is a Google Cloud product and does not change anything about a Firebase licence.

How We Decide With Clients

The shorthand we use is to ask what shape the workload is before looking at any feature list.

Write heavy, bursty, mobile first, with a team that can hold query discipline, points to Firestore, because it genuinely scales past where a single Postgres primary stops and the offline and realtime support is mature. Read heavy with relational structure and a finance function that needs a forecast points to Postgres, where the bill tracks resources rather than query design.

Then we ask the two questions people skip. Who owns query review, because on Firestore that role is a cost control and not a nicety. And what does the exit look like, because the export format is the one thing you cannot fix later with better engineering.

For the pricing view across the whole category, see backend as a service providers compared. For the Postgres alternative in the same format, see is Supabase production ready. If you would rather have someone run the query review and the migration decision alongside your team, that is custom software development work we do.

Where These Numbers Come From

Every limit, price and date above was read from firebase.google.com or cloud.google.com on 1 September 2026 and checked a second time before publishing. Pricing figures were taken from the us-central1 and nam5 region tables directly rather than from the default view, because the Firestore pricing page defaults to hourly units and the widely quoted per GiB per month storage figure only appears with the monthly toggle applied.

Four corrections were made during that verification and are worth passing on, because each is a common error elsewhere. Cloud Functions are not available on the Spark plan. Multi region is double the Iowa rate for operations but only 1.2 times for storage, and is not double the cheapest regions. The 1,000 functions per region cap applies to first generation only. And the ramp rule is documented as 500/50/5 on the best practices page while the real time queries page now calls the same thing the 5-5-5 rule, so we cite only the former.

The architectural judgements, the fix in place list and the decision shorthand are our own delivery practice rather than Google documentation, and are marked as such rather than dressed up with a borrowed statistic.

Frequently Asked Questions