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 run in production at serious scale for over a decade, so whether it works is settled. What you need to check is whether its limits and its billing model fit your workload, because Firebase fails differently from a Postgres platform. The limits, prices and dates below all come from what Google itself publishes.

We wrote the same guide for Supabase, and the two are worth reading together because the 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 tie named companies to specific products. LaHaus uses Crashlytics and Performance Monitoring, Classkick the Realtime Database and Cloud Storage, FAVES the Realtime Database and Cloud Functions, and MOIA Remote Config and Test Lab.

Google publishes no throughput or user count figures alongside those names, so all they establish is that credible companies ship on Firebase. 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, a phrase worth reading closely before you rely on the number.

Compliance coverage. Firebase is thinner here than teams expect, and the Firebase privacy and security page makes no mention of HIPAA or PCI anywhere. If you are building in regulated healthcare or handling card data directly, treat that absence as a no.

Predictable cost. Firebase does not offer this, by design, and the billing section below explains why.

An exit. Also weak, for the reasons in the migration section.

Where Are the Real Scaling Limits

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 phrase 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 one limit sits behind 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 its ceilings spelled out. 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 and 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, so count your Cloud Run services 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

Billing 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 why the failure mode catches teams out.

The reads are not always the ones you would count, and Google documents each of these cases.

• 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.
• 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.

The uncomfortable fact is that 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 couple of days. A spend cap feature exists for 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. That leaves architecture as the only real control, 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.

Remote Config has also 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 come from 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 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 itself is the problem and better code will not fix it. And if you are in regulated healthcare or handling card data, the absence of published HIPAA and PCI coverage settles it.

The migration itself has a cost. 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. A full export of a large database therefore has a real bill attached before you have converted a single record. That is what lock in looks like on Firestore, and it is the strongest argument for making the platform decision early. For what leaving costs across the whole category, see our backend as a service pricing comparison.

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 the open source framework from Google 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.

For procurement conversations, note that 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.

A workload that is write heavy, bursty and mobile first, with a team that can hold query discipline, points to Firestore, because it scales past where a single Postgres primary stops and its offline and realtime support is mature. A read heavy workload with relational structure, plus 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. The first is who owns query review, since on Firestore that role works as a cost control. The second is what the exit looks like, because the export format is the one thing you cannot fix later with better engineering.

Our backend as a service comparison has the pricing view across the whole category, and our Supabase guide covers the Postgres alternative in the same format. If you would rather have someone run the query review and the migration decision alongside your team, we take that on as part of our custom software development work.

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.

We made four corrections during that verification, and we pass them 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 come from our own delivery practice rather than Google documentation, and we label them as such here instead of propping them up with a borrowed statistic.

Frequently Asked Questions