Firebase Put a Meter On Your Live Game

Google published cost optimisation guidance alongside the new Remote Config pricing. The headline recommendation is to fetch less often. Leave the minimum fetch interval at the recommended 12 hours, push stable values out to 24 or 48, audit the background jobs for redundant calls.

That is reasonable advice for a weather app. For a live game, as you know, the fetch interval is the clock speed of your entire LiveOps operation. Google has just put a price on running it fast.

What changed

Remote Config went usage-based on September 1, 2026. Every project gets 100,000 fetch requests a day for free. After that it’s $0.06 per 10,000 requests, dropping to $0.01 per 10,000 once you pass 10 million a day.

The product didn’t change. What changed is that the layer sitting underneath your experiments, feature rollouts, dynamic shops and kill switches now has a meter on it, and the meter is wired directly to how responsive your game is.

Why fetch interval matters

A fetch interval is like two delays wearing one number.

The first is outbound: the gap between you deciding something and your players experiencing it. At 12 hours, a misconfigured offer stays live for most of a day after you’ve fixed it. At 48, a rollback becomes a two-day operation you announce to the team in advance.

The second is inbound, and it’s the one only a few budget for. Your players can only react to values they’ve received. Until a device fetches, that player is still running last week’s game and generating data about last week’s game. Widen the interval and you are slowing down your changes as well as slowing down the arrival of the evidence you need to make the next ones.

When you stretch the interval, your treatment group fills in over days instead of hours. Cohorts start at different points, sit under different client versions, and catch different parts of the week. Statistical power tends to arrive late and it arrives dirty. In other words, you risk learning less from your tests.

The incentives point the wrong way

More audience segments. More concurrent tests. Faster rollouts and faster rollbacks. Shorter fetch intervals so changes actually land. Every marker of a studio operating a live game well now shows up as a larger invoice.

For scale, one top-grossing puzzle game we work with sends around 120 million Remote Config requests a day, close to 4 billion a month. Under the new rates that’s roughly $5,400. A studio at that revenue absorbs it easily.

The bill isn’t the real damage. The reaction time is. Once the meter exists, the next time someone proposes a fourth concurrent test or a tighter interval, there’s a number attached to saying yes. Studios are incentivized to run a slower operation. And with this incentive, the speed will slow down one reasonable cost optimization at a time.

You also can’t see what you’re operating

When you publish a change in the Firebase console, all you learn is that it published. There’s no view telling you how many players hold the new value or when the rollout completes.

Three delays sit between your change and the player:

• A client-side cache
• A separate activation step
• Whenever your code next reads the value

So when an event misfires and your fix doesn’t seem to be working, you can’t tell whether the change is wrong or simply hasn’t arrived. Every incident, in our experience, starts with debugging Firebase instead of your game.

Underneath it all is Google Cloud. Firebase’s storage is Google Cloud Storage with a Firebase label. A/B Testing depends on a linked Google Analytics property, and relinking to a different one costs you access to every experiment created before the switch. Even finding out what Remote Config costs means leaving Firebase: open the Google Cloud console, run a billing report filtered by SKU 37B1-4623-6F54, then check a separate quotas page for usage. You don’t adopt Firebase so much as take up residency in Google Cloud.

What we built instead

Firebase serves every kind of app, which is why game studios get a general purpose toolkit and assemble the rest themselves. Satori has game studios as customers and nothing else. Everything in it exists because a live game needed it.

• Segments that keep up with your game. Audiences recompute every ten minutes by default, and a player’s membership updates the moment they send an event. Eligibility is evaluated when the player asks, so live events, experiments and feature flags reflect current state rather than cached state.
• A view of what each player is actually getting. Every player identity has a behaviour stream: captured events, current properties, audience membership, experiment enrolment, and the flags in effect right now.
• No meter on your LiveOps. Flags, variants, segments and remote configuration are unlimited at any volume. Running more tests doesn’t change the bill. Usage-based billing runs on events instead, with a generous free tier with Volume Rates available, and you decide how many events you send. Most studios never go past the $1,800 base plan.
• Experiment controls built for live games. Sequential phases, participant caps, admission deadlines, and the ability to lock enrolment partway through. A live event calendar shows the whole team what’s scheduled and running.
• Your data stays yours. Raw events export to BigQuery, Snowflake or Databricks.

Firebase treats remote configuration as something you consume. In a live game it’s what you operate the game with, and metering it by API call changes how often your team is willing to reach for it.

If your fetch interval is going to be set by anything, it should be how fast your game needs to move. Not by what it costs to find out.

Come talk to us!