BetterConfig vs Firebase Remote Config

Here is the short answer before the table. Stay on Firebase Remote Config if you need free reads at any scale and mobile A/B testing inside the Google ecosystem. Its free tier is genuinely free for an unlimited number of daily active users, its SDKs are mature across platforms, and its experimentation hooks into Google Analytics with no extra service. None of that has changed.

Pick BetterConfig if config is something your team edits every week rather than once a quarter. You get JSON values that stay JSON, real environments inside one project, full version history with one-click rollback, scoped read-only tokens, and changes that are typically live at the edge in under a minute over plain HTTPS. That is the trade: you give up free uncapped reads and built-in experimentation, and you get a tool shaped around the day-to-day editing of operational configuration.

This is an honest comparison. Every number below comes from the official docs of both products, and BetterConfig concedes the rows Firebase wins in plain language. If a comparison article hides the rows you would lose, do not trust the rows it claims to win.

The short version

BetterConfig is in the first column, Firebase Remote Config in the second. Read the whole thing before deciding; the rows do not all point the same direction.

The honest read of that table: Firebase wins on price, free uncapped reads, A/B testing, native SDK breadth, and real-time push. BetterConfig wins on environments, value typing that survives to the client, versioning and rollback depth, and propagation speed under default settings. Which set matters more depends entirely on what you do with config.

Where Firebase Remote Config is genuinely strong

It is worth being specific about what Firebase does well, because these are real reasons to stay.

• Free at unlimited scale. Remote Config is available at no cost on both the Spark and Blaze plans, for an unlimited number of daily active users. BetterConfig meters reads and has a hard cap; Firebase does not.
• A/B testing integrated with Google Analytics. Experiments run against Analytics audiences with no separate experimentation product to buy or wire up. A/B Testing is free, though it requires Google Analytics to be enabled.
• Real-time updates. The real-time listener keeps an HTTP connection open and bypasses the fetch interval, on mobile and, since the Firebase JS SDK 12.3.0 release on September 18, 2025, on the web as well.
• Mature SDKs across platforms. Apple, Android, web, Unity, and C++ all ship first-party clients with years of production mileage. BetterConfig has a React SDK in development and otherwise asks you to read over HTTPS.
• Server-side templates. The Admin SDK server templates let backend code fetch and evaluate config, currently labeled a Preview release across Node.js, Python, Go, and Java.

Where it gets in your way

Firebase Remote Config was designed for mobile feature delivery. The friction below comes from using it as a config store your team edits often, which is a different job than the one it was built for.

The 12-hour default fetch interval and throttling

The default and recommended production minimum fetch interval is 12 hours on both mobile and web: with minimumFetchIntervalMillis at the default of 43,200,000, configs are not fetched from the backend more than once in a 12-hour window, regardless of how many fetch calls you make. Lower it and you risk FETCH_THROTTLE on web and a fetch-throttled exception on Android. You can avoid the interval entirely with the real-time listener, but that is a separate code path with its own SDK version requirements, not the default behavior.

Typed values that still arrive as strings

The console lets you tag a parameter as STRING, BOOLEAN, NUMBER, or JSON. That typing is validation-side only. The docs are explicit: selecting a data type does not affect how values are returned to the client SDKs. Your client code still casts by hand with getString, getBoolean, getLong, or getValue.

// Firebase Remote Config on the web.
import { getRemoteConfig, fetchAndActivate, getValue } from "firebase/remote-config";

const remoteConfig = getRemoteConfig(app);

// The recommended production minimum. Anything lower risks throttling.
remoteConfig.settings.minimumFetchIntervalMillis = 43_200_000; // 12 hours

await fetchAndActivate(remoteConfig);

// Typed in the console, but the client still casts by hand.
const enabled = getValue(remoteConfig, "promo_banner_enabled").asBoolean();
const message = getValue(remoteConfig, "promo_banner_text").asString();
const limit = getValue(remoteConfig, "max_upload_mb").asNumber();

No environment concept

There is no dev, staging, or prod inside a Firebase project. Firebase recommends a separate project for each environment. In practice that means separate templates, separate credentials, and separate consoles to keep in sync. A value you change in staging does not promote to production; you re-create it.

Version history capped at 300 versions with a 90-day lifetime

Remote Config stores at most 300 lifetime versions per template type, with client and server templates counted separately, and the oldest is auto-deleted past that. Each version also has a 90-day lifetime. Rollback exists, both in the console change-history page and via the REST :rollback endpoint, but the window you can roll back to is bounded.

A/B testing requires Google Analytics

Experimentation is not standalone. A/B testing requires Google Analytics, and the documented limits are up to 24 running experiments and rollouts combined, with 300 total experiments per project. If you do not run Analytics, you do not get experiments.

The console as a JSON editor

Remote Config caps the total length of all parameter value strings per project at 1,000,000 characters, across up to 3,000 parameters and 2,000 conditions. Conditions are per-device targeting rules, not environments, so they do not give you the dev/staging/prod separation you might reach for them to provide.

How BetterConfig approaches the same problems

BetterConfig takes the same set of problems and answers them differently, because it assumes config is edited often by a team.

• JSON-native typed values. Keys are booleans, numbers, strings, objects, or arrays, edited in a real in-app JSON editor, and the values come back as JSON. No casting layer on the client.
• Environments first-class in one project. Each environment holds its own values, versions, and history inside a single project, with per-environment versioning and rollback and no retention cap on any plan. (Note: the Free tier includes one environment; unlimited environments start at Pro.)
• A plain-HTTPS read API. Published config is served from an edge-cached read API on Cloudflare Workers. It sends an ETag of "v<version>" and Cache-Control: public, max-age=30, stale-while-revalidate=300, and honors If-None-Match with a 304. Changes are typically live at the edge in under a minute, against Firebase's 12-hour default interval.
• Scoped read-only tokens. Tokens are read-only and scoped to a project (reads any environment) or to a single environment. They cannot write or publish.
• Team roles. Owner, editor, and viewer, with email invites.
• One-upload Firebase import. Upload a Firebase Remote Config template or a flat JSON object and the format is auto-detected. The migration guide walks through exporting from Firebase and bringing every parameter across, and the import documentation covers the file formats.

The read shape is one authenticated GET:

curl "https://api-public.betterconfig.dev/v1/config?project=acme-web&env=prod" \
  -H "Authorization: Bearer $BC_READ_TOKEN"

The response is a small JSON document:

{
  "projectSlug": "acme-web",
  "environmentKey": "prod",
  "version": 14,
  "fetchedAt": 1749480000000,
  "values": {
    "promo_banner_enabled": true,
    "promo_banner_text": "Summer sale: 20% off",
    "max_upload_mb": 50,
    "checkout_v2": false
  }
}

For the React-specific wiring of that endpoint, including a Next.js App Router pattern, see the React remote config guide.

What BetterConfig does not do yet

The fair comparison goes both ways. Here is what Firebase has that BetterConfig does not, stated plainly.

• No targeting, rollouts, or A/B testing. There are no per-device targeting rules, no percentage rollouts, and no experiments today. These are on the roadmap. If you need any of them now, Firebase is the better fit.
• No native SDKs today. A React SDK is in development. Right now you read config over plain HTTPS from any language, which works everywhere but is not the typed, cached, offline-aware client Firebase ships.
• Reads are metered with a hard cap. Over the cap the read API returns 429 with {"error":"reads_limit_exceeded"}, checked roughly every 15 minutes. There are never overage charges, upgrading unblocks reads immediately, and the cap resets at the start of each month. Firebase, by contrast, has free and uncapped reads.
• No published SLA. The product is pre-launch, so there is no uptime commitment yet.

Coming soon Targeting rules, percentage rollouts, and a native React SDK.

The numbers side by side

Pulled straight from both sets of docs, with no rounding inBetterConfig's favor.

A Firebase template is also worth a glance, because importing one is how most teams move over. The shape is a JSON object of parameters, each with a defaultValue and a valueType:

{
  "conditions": [],
  "parameters": {
    "promo_banner_enabled": {
      "defaultValue": { "value": "false" },
      "valueType": "BOOLEAN"
    },
    "max_upload_mb": {
      "defaultValue": { "value": "50" },
      "valueType": "NUMBER"
    }
  },
  "parameterGroups": {},
  "version": {}
}

Which one should you pick

Choose Firebase Remote Config if:

• You need free reads at any scale and do not want a read quota to think about.
• You run mobile A/B tests and already have Google Analytics in place.
• You want mature native SDKs with offline caching and real-time push on Apple and Android.
• Your config changes a few times a quarter and the 12-hour interval is fine.

Choose BetterConfig if:

• Config is something your team edits every week and you want a real JSON editor with typed values.
• You want dev, staging, and prod as environments inside one project, not three separate Firebase projects.
• You want full version history with one-click rollback and no retention cap.
• You want published changes live in about a minute over plain HTTPS, readable from any language.

If you are leaning toward BetterConfig, the migration guide covers exporting your template and importing it, and the Firebase Remote Config limitations reference collects every documented limit in one place if you want to read the fine print first. If feature flags with targeting are the real requirement, the ConfigCat vs Flagsmith comparison covers two platforms built for that job.