Firebase alternatives for China — measured

Firebase bundles more than twenty products under one console. That convenience hides a geography problem: most of the stack assumes Google infrastructure is reachable from the client. From Mainland China it often is not — or it is slow enough that users experience broken login, stalled databases, and push that never arrives.

To move past “it probably breaks,” we built a small demo app on a real Firebase project and probed every product from inside Mainland China — once as the user’s browser would reach Firebase, and once as a Mainland China app server would. This guide maps Firebase’s full product list to a concrete probe you can run, the verdict we measured from a Beijing node on 2026-06-25, and the China-local alternative where replacement is warranted. For the vendor shortlist behind those replacements, Chinaready Landscape keeps a live map of Firebase alternatives in China plus per-product lookups linked from each section below.

How we tested

The demo app

We provisioned a tiny “field reports” app — the kind of CRUD product most teams ship. A Mainland China user signs in (Auth), posts a short report document (Firestore), attaches a photo (Storage), a callable function stamps it (Functions), peers get a push (FCM), and an in-app banner is toggled by Remote Config.

Two vantage points, one Mainland China host

A real product touches Firebase from two places, and the assumption here is that both are in Mainland China: the user’s browser/client SDK, and the app’s own backend. So every user-facing product gets probed along two paths, both run from a single Alibaba Cloud ECS in cn-beijing:

Path	What it represents	Tooling
Frontend path	The user’s browser / client SDK in Mainland China	curl + Web API key, plus a real ID token from the demo user
Backend path	The app’s server in Mainland China	the Firebase Admin SDK (firebase-admin) with a service account

Products we do not provision get a single transport probe — does the host answer from Mainland China at all — which is enough to verdict a service whose failure mode is “the endpoint is unreachable.”

What we provisioned for this run

The 2026-06-25 run uses the project’s real Web keys and a service account, so both paths are exercised end to end. Provisioned: Authentication (email user + anonymous, both confirmed working), the Realtime Database (legacy database secret), and Cloud Firestore (three reports seeded via the Admin SDK from a reachable host). Cloud Storage’s default bucket was not initialized, and Cloud Functions / Remote Config were not deployed — none of which changes the China verdict, because the hosts those products depend on are blocked regardless. The service account is valid — it seeded Firestore from outside China minutes before the run — so the backend failures below are network-caused, not credential problems.

Verdict vocabulary

Verdict	Meaning
Blocked	Connection timeout, TLS failure, or hard reset — feature unusable (our probes time out at 10s)
Degraded	Connected but slow (>5s) or intermittent across samples
Reachable	Probe completes reliably at low latency (any HTTP status)
N/A	Developer tooling only — not on the China user critical path

Provenance

Results below were measured from Alibaba Cloud / cn-beijing-h / launchready.cn on 2026-06-25. The frontend and backend paths were run with the project’s real keys and service account; the transport set was sampled three times over ~1 hour. The probe kit is open and reproducible. Carrier, province, and time of day move these numbers — treat the table as a starting point and re-run the probes on your own traffic path.

Measured snapshot — 2026-06-25, cn-beijing

The raw probe output, both paths. The pattern is the story: *.googleapis.com Firebase endpoints are Blocked on the frontend, the server-side Admin SDK is Blocked too, and only a handful of non-googleapis hosts answer — yet the user-facing feature still breaks because its SDK also depends on a blocked endpoint.

Product	Path	Probe	HTTP	Total (s)	Verdict
Authentication	frontend	anonymous sign-up	000	10.00	Blocked
Authentication	frontend	email sign-in	000	10.00	Blocked
Cloud Firestore	frontend	authed read	000	10.00	Blocked
Cloud Storage	frontend	object download	000	10.00	Blocked
Cloud Functions	frontend	helloProbe HTTP	000	10.00	Blocked
Authentication	backend	Admin SDK user lookup	auth-token-blocked	1.38	Blocked
Cloud Firestore	backend	Admin SDK write+read	timeout	30.01	Blocked
Cloud Storage	backend	Admin SDK metadata	ETIMEDOUT	3.67	Blocked
Cloud Messaging	backend	Admin SDK FCM v1 send	auth-token-blocked	1.36	Blocked
Remote Config	backend	Admin SDK get template	auth-token-blocked	1.36	Blocked
Firebase ML / Vision	transport	vision.googleapis.com	000	10.00	Blocked
Firebase AI Logic	transport	generativelanguage	000	10.00	Blocked
Google Analytics	transport	app-measurement.com	404	0.20	Reachable
Crashlytics	transport	settings host	404	0.27	Reachable
Performance Mon.	transport	firebaselogging	000	10.00	Blocked
Remote Config	transport	firebaseremoteconfig	000	10.00	Blocked
Cloud Messaging	transport	installations host	000	10.00	Blocked
Cloud Messaging	transport	fcm.googleapis.com	000	10.00	Blocked
App Check	transport	reCAPTCHA loader	000	10.00	Blocked
App Distribution	transport	appdistribution host	000	10.00	Blocked
Cloud Messaging	transport	mtalk.google.com:5228 (TCP)	—	0.20	Reachable
Hosting	transport	*.web.app	404/000/404	0.89–3.06	Degraded (intermittent)
Realtime Database	transport	firebaseio.com (unauth)	401	1.5–6.0	Reachable (slow)
Realtime Database	backend	authed write (legacy key)	200	0.92	Reachable

The backend choke point: one blocked endpoint kills the Admin SDK

The server path fails before it touches any product. The Admin SDK’s first move is to mint an OAuth2 access token — and the token endpoints are unreachable from cn-beijing:

Token endpoint	cn-beijing result
oauth2.googleapis.com	timeout (no connect)
accounts.google.com	timeout (no connect)
www.googleapis.com	timeout (no connect)

So getUserByEmail(), messaging().send(), and getTemplate() all fail in ~1.4s with auth-token-blocked — not because Auth, FCM, or Remote Config rejected them, but because the SDK never got a token. Firestore and Storage time out further along, at their own data hosts. The service account is valid (it seeded Firestore from outside China minutes earlier), so this is purely a network block: one unreachable endpoint — oauth2.googleapis.com — disables every server-side Firebase call from Mainland China.

Two more facts. First, mtalk.google.com:5228 accepts a TCP connection from this node, but that does not mean push works — Mainland China Android ships without Google services, so no device maintains that channel. Second, the Realtime Database is the one data product that answered (firebaseio.com connected on every sample); the authenticated write completed in under a second. Most of the rest of Firebase rides on *.googleapis.com, which did not connect.

At a glance (planning view)

Use this as a planning table; the measured rows above are the evidence. Carrier, province, and time change outcomes.

Firebase product	User-facing?	Mainland China verdict	Replace for China?
Authentication (email, anonymous)	Yes	Blocked (measured)	Yes
Authentication (Google / OAuth)	Yes	Blocked	Yes
Authentication (SAML/OIDC)	Yes	Degraded	Often
Phone Auth / Phone Number Verification	Yes	Blocked (reCAPTCHA dep)	Yes (domestic SMS)
Cloud Firestore	Yes	Blocked (measured)	Yes
Realtime Database	Yes	Reachable / Degraded (measured)	Sometimes
Cloud Storage	Yes	Blocked (measured)	Yes for media
Cloud Functions (client-callable)	Yes	Blocked (measured)	Often
Cloud Messaging (FCM)	Yes	Blocked (device + send host)	Yes
Hosting / App Hosting	Yes	Degraded (intermittent)	Often
Remote Config	Yes	Blocked (measured)	Often
Crashlytics	Yes	Settings host reachable; uploads degrade	Often
Performance Monitoring	Yes	Blocked (measured)	Often
Google Analytics (Firebase)	Yes	Collection host reachable; SDK degrades	Often
A/B Testing	Yes	Degraded (depends on RC + Analytics)	Sometimes
In-App Messaging	Yes	Degraded	Sometimes
App Check	Yes	Blocked (reCAPTCHA)	Yes
Firebase ML / Cloud Vision	Yes	Blocked (measured)	Yes
SQL Connect (Cloud SQL)	Yes	Degraded (not probed)	Often
App Distribution	No (dev)	Blocked (measured)	No
Test Lab	No (dev)	N/A	No
Firebase AI Logic / Gemini	Yes / dev	Blocked (measured)	Yes
Firebase Studio / Gemini in Firebase	No (dev)	N/A	No
Extensions	Varies	Varies	Per extension

Build — data, auth, and compute

Authentication

What it does. Email/password, anonymous, phone, and OAuth (Google, Apple, etc.) via Identity Toolkit.

Mainland China behavior. Blocked. From cn-beijing both anonymous sign-up and email sign-in time out — identitytoolkit.googleapis.com never connects. (For reference, the same calls complete fine from outside China, where we created the demo user.)

Frontend path — anonymous sign-up (client REST):

curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=$FIREBASE_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{"returnSecureToken":true}'

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s (connection timed out).

Frontend path — email sign-in (mints the ID token for later probes):

curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=$FIREBASE_API_KEY" \
 -H "Content-Type: application/json" \
 -d "{\"email\":\"$DEMO_USER_EMAIL\",\"password\":\"$DEMO_USER_PASSWORD\",\"returnSecureToken\":true}"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s. Token refresh is never reached because sign-in itself does not connect.

Backend path — Admin SDK user lookup (a Mainland China server verifying accounts) is Blocked too — getUserByEmail() failed in 1.38s with auth-token-blocked: the Admin SDK could not reach oauth2.googleapis.com to mint an access token (see the backend choke point above). The service account is valid; the token endpoint is simply unreachable.

China alternatives.

Need	Domestic options
Email / phone login	Amazon Cognito (AWS China, Beijing region), Authing, Alibaba Cloud IDaaS, Tencent Cloud IDaaS
OAuth / social	Provider-specific Mainland China SDKs (WeChat, Alipay) via the IDaaS vendors above
Enterprise SAML/OIDC	Amazon Cognito (AWS China, Beijing region), Authing, Aliyun IDaaS, self-hosted Keycloak on a China-region VPC

Landscape lookups for this tier: Firebase Authentication alternatives and Amazon Cognito alternatives. For the WeChat and Alipay login side of the same decision, see login and payments in China apps.

Phone Auth & Phone Number Verification

What it does. SMS OTP for sign-in and standalone phone verification (Firebase PNV).

Mainland China behavior. Blocked. The flow requires a reCAPTCHA token, and the reCAPTCHA loader is Blocked from cn-beijing (see App Check) — phone OTP fails before the SMS can send. Google-sent SMS to +86 numbers is unreliable on top of that.

Frontend path — trigger SMS (requires enabled Phone Auth + a test number):

curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 -X POST "https://identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode?key=$FIREBASE_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{"phoneNumber":"+86YOUR_TEST_NUMBER","recaptchaToken":".."}'

cn-beijing (2026-06-25): Blocked upstream — the reCAPTCHA dependency (www.google.com) timed out at total=10.00s, so the OTP call cannot be made.

China alternatives. Alibaba Cloud SMS, Tencent Cloud SMS, NetEase Yunxin, Chuanglan — integrated through your auth layer, not through Firebase Phone Auth. The reCAPTCHA dependency that breaks this flow is the same one that breaks web forms: reCAPTCHA and forms in China covers the captcha replacement path, and SMS, push, and email in China covers the delivery side.

Cloud Firestore

What it does. Document database with realtime listeners (WebSocket/gRPC).

Mainland China behavior. Blocked. firestore.googleapis.com does not connect from cn-beijing — single reads and onSnapshot listeners alike fail.

Frontend path — authenticated read of a seeded doc:

curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 -H "Authorization: Bearer $ID_TOKEN" \
 "https://firestore.googleapis.com/v1/projects/$FIREBASE_PROJECT_ID/databases/(default)/documents/reports/report-001"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

Backend path — Admin SDK write + read-back is Blocked — the firestore.googleapis.com gRPC channel never connects and the probe times out at 30s. (Documents seed fine via the Admin SDK from outside China, confirming the credential is valid.)

China alternatives.

Pattern	Domestic options
Document DB + realtime	Amazon DynamoDB + AWS AppSync (real-time GraphQL; AWS China Beijing/Ningxia), LeanCloud, Tencent Cloud TDSQL-C / MongoDB on domestic cloud, Alibaba Tablestore
Full BaaS replacement	LeanCloud, MemFire Cloud (Supabase-compatible, China-hosted)
Self-managed	Amazon DynamoDB / DocumentDB on AWS China, or PostgreSQL / MongoDB on Alibaba/Tencent/Huawei Cloud in cn-* regions

Realtime Database

What it does. JSON tree with WebSocket sync (*.firebaseio.com).

Mainland China behavior. The exception in the data tier. firebaseio.com is reachable from this Beijing node: an authenticated write (legacy database secret) completed in 0.92s (Reachable), and an unauthenticated request connected on every sample, returning 401 in 1.5–6.0s (Reachable but variable). Long-lived WebSocket sync may still suffer, but the host answers — unlike Firestore/Storage on *.googleapis.com.

Transport probe (unauthenticated):

curl -sS -o /dev/null -w "rtdb code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 "${FIREBASE_DB_URL%/}/.json"

cn-beijing (2026-06-25): Reachable but variable — code=401, total=1.5–6.0s across samples (connects every time, auth required, latency swings).

Backend path — authenticated write (legacy DB secret):

curl -sS -o /dev/null -w "rtdb-auth code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 -X PUT "${FIREBASE_DB_URL%/}/probes/ecs.json?auth=$GOOGLE_DB_KEY" \
 -H "Content-Type: application/json" -d '{"src":"ecs"}'

cn-beijing (2026-06-25): Reachable — code=200 total=0.92s.

China alternatives. Even when reachable, weigh latency and compliance — AWS AppSync (real-time GraphQL) or AWS IoT Core (MQTT) in the AWS China Beijing/Ningxia regions, a domestic document/realtime DB, or an MQTT layer (Alibaba Cloud MQTT, EMQX on domestic cloud) for pure pub/sub patterns.

Cloud Storage

What it does. Object storage for user uploads, media, and static assets (firebasestorage.googleapis.com).

Mainland China behavior. Blocked. The download host does not connect from cn-beijing.

Frontend path — download an object:

curl -sS -o /dev/null -w "storage code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 "https://firebasestorage.googleapis.com/v0/b/$FIREBASE_STORAGE_BUCKET/o/probes%2Ffield-report-sample.jpg?alt=media"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

Backend path — Admin SDK metadata is Blocked — getMetadata() failed with ETIMEDOUT against storage.googleapis.com. (The default bucket was also uninitialized for this run, but the host is unreachable from cn-beijing regardless.)

China alternatives. Amazon S3 (AWS China, Beijing/Ningxia regions), Alibaba OSS, Tencent COS, Qiniu, Volcengine TOS — front with a domestic CDN (Amazon CloudFront in Ningxia, Alibaba CDN, Tencent CDN, Wangsu) for download-heavy apps.

Cloud Functions

What it does. HTTPS callable functions and background triggers (*.cloudfunctions.net, *.run.app for 2nd gen).

Mainland China behavior. Blocked. The function host does not connect from cn-beijing; clients and a Mainland China backend alike time out.

Frontend path — call the public helloProbe function:

curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 "https://$FIREBASE_FUNCTIONS_REGION-$FIREBASE_PROJECT_ID.cloudfunctions.net/helloProbe"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

Backend path. A Mainland China server calling the same function hits the same cloudfunctions.net host — same Blocked result.

China alternatives. AWS Lambda + Amazon API Gateway (AWS China, Beijing/Ningxia regions), Alibaba Function Compute, Tencent SCF, Huawei FunctionGraph.

Hosting & App Hosting

What it does. Static site and full-stack web app hosting on Firebase CDN (*.web.app, *.firebaseapp.com, App Hosting on Cloud Run).

Mainland China behavior. Degraded (intermittent). Across three samples the *.web.app host answered twice (404, 0.89s and 3.06s) and timed out once (000) — pages load unpredictably and slowly. App Hosting adds the same cross-border API problem for SSR data fetches.

Transport probe:

curl -sS -o /dev/null -w "hosting code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 30 \
 "https://$FIREBASE_PROJECT_ID.web.app/"

cn-beijing (2026-06-25): Degraded — sample 1 code=404 total=0.89s, sample 2 code=000 total=1.25s.

China alternatives. Static assets on Amazon S3 + Amazon CloudFront (AWS China Ningxia region, ICP required), or Alibaba OSS / Tencent COS + a domestic CDN; dynamic apps on AWS China (EC2 / ECS / Fargate in Beijing/Ningxia), Alibaba SAE, or Tencent CloudBase.

SQL Connect (Cloud SQL)

What it does. Managed PostgreSQL wired into Firebase (newer SQL Connect product).

Mainland China behavior. Degraded (not probed in this run — no Cloud SQL instance). The DB runs in a GCP region with no Mainland China POP; clients in China see high latency and drops.

Transport probe. From the China host, TCP + SSL to the Cloud SQL public IP (if enabled):

timeout 15 bash -c 'echo | openssl s_client -connect CLOUD_SQL_IP:5432 </dev/null 2>&1 | head -3'

cn-beijing (2026-06-25): not provisioned for this run.

China alternatives. Amazon RDS / Aurora PostgreSQL (AWS China, Beijing/Ningxia regions), Alibaba RDS PostgreSQL, Tencent PostgreSQL, Huawei RDS — same schema, migrated connection strings for the China app variant.

Firebase ML & Cloud Vision

What it does. On-device custom models and Cloud Vision API calls.

Mainland China behavior. Blocked — vision.googleapis.com does not connect.

Transport probe:

curl -sS -o /dev/null -w "vision code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://vision.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

China alternatives. Alibaba Cloud Vision, Baidu AI Vision, Tencent Cloud TI-OCR — swap the API client in your China build flavor.

App Check

What it does. Attestation that requests come from your real app (reCAPTCHA, Play Integrity, DeviceCheck).

Mainland China behavior. Blocked with the reCAPTCHA provider — the loader on www.google.com does not connect, so attestation never completes.

Transport probe — reCAPTCHA loader:

curl -sS -o /dev/null -w "recaptcha code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 15 \
 "https://www.google.com/recaptcha/api.js"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

China alternatives. Domestic captcha (GeeTest, NetEase Yidun) + custom server-side attestation; or App Check with a provider your China build can actually reach. Landscape maps the captcha layer itself under Google reCAPTCHA alternatives.

Extensions

What it does. Pre-packaged Cloud Functions + integrations (Stripe, Algolia, image resize, etc.).

Mainland China behavior. Varies — each extension calls its own third-party APIs and runs on cloudfunctions.net (Blocked above). Treat as separate line items in your dependency inventory.

How to probe. Identify the extension’s outbound URLs from its source and curl each from the China host — same transport method as the products above.

China alternatives. Replace per dependency — e.g. Algolia → domestic search (Elasticsearch on domestic cloud), Stripe → WeChat Pay / Alipay via domestic payment aggregators.

Firebase AI Logic

What it does. Gemini and generative AI calls from client or server through Firebase.

Mainland China behavior. Blocked — generativelanguage.googleapis.com does not connect.

Transport probe:

curl -sS -o /dev/null -w "generativelanguage code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://generativelanguage.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

China alternatives. Alibaba Tongyi (Qwen), Baidu ERNIE, Tencent Hunyuan, Zhipu GLM — route through your backend in a cn-* region; do not call Google AI from the China client.

Run — messaging, analytics, and ops

Cloud Messaging (FCM)

What it does. Push notifications to Android, iOS, and Web.

Mainland China behavior. Blocked. Both the send host (fcm.googleapis.com) and the token registration host (firebaseinstallations.googleapis.com) time out. Separately, Mainland China Android ships without Google Mobile Services, so even the device push channel is moot — we test the network path only.

Backend path — server send host:

curl -sS -o /dev/null -w "fcm code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://fcm.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s for the host curl, and the real Admin SDK messaging().send() is Blocked too (auth-token-blocked in 1.36s — it never gets an OAuth token; see the backend choke point above).

Frontend path — token registration host:

curl -sS -o /dev/null -w "installations code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://firebaseinstallations.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

Device channel — TCP to the push transport:

timeout 10 nc -zv mtalk.google.com 5228

cn-beijing (2026-06-25): Reachable (TCP) — total=0.20s. The socket opens, but Mainland China Android has no Google framework to use it, so device delivery still does not happen.

China alternatives. Integrate per OEM/channel — Huawei Push, Xiaomi, OPPO, vivo, Honor, Meizu — or use an aggregator: Alibaba Cloud EMAS, Tencent TPNS, JPush, Getui. Landscape keeps the shortlist under Firebase Cloud Messaging alternatives; SMS, push, and email in China covers the channel decision, and our Android store guide covers distribution context.

Remote Config

What it does. Server-driven feature flags and JSON config fetched at app start.

Mainland China behavior. Blocked — firebaseremoteconfig.googleapis.com does not connect; apps fall back to defaults silently, making rollouts invisible in China.

Frontend path — fetch host reachability:

curl -sS -o /dev/null -w "remoteconfig code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://firebaseremoteconfig.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

Backend path — Admin SDK template fetch is Blocked — getTemplate() failed in 1.36s with auth-token-blocked (the Admin SDK could not reach oauth2.googleapis.com for a token; see the backend choke point above).

China alternatives. Domestic config service or embed flags in your China API response; Alibaba Cloud EMAS, Tencent Cloud config, or simple JSON on OSS with short TTL + CDN. Landscape shortlist: Firebase Remote Config alternatives.

Crashlytics

What it does. Crash and non-fatal error reporting from mobile clients.

Mainland China behavior. Mixed → Degraded. The settings host (firebase-settings.crashlytics.com) is reachable (404, 0.27s), but the SDK also fetches configuration from blocked Google hosts and uploads can fail silently, so your dashboard under-reports China crashes.

Transport probe:

curl -sS -o /dev/null -w "crashlytics code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://firebase-settings.crashlytics.com/"

cn-beijing (2026-06-25): Reachable — code=404 total=0.27s (host answers; full pipeline still degrades).

China alternatives. Tencent Bugly, Alibaba ARMS, Sentry self-hosted on domestic cloud, or Umeng U-APM. Landscape shortlist: Firebase Crashlytics alternatives.

Performance Monitoring

What it does. Automatic traces and custom metrics from mobile/web clients.

Mainland China behavior. Blocked — firebaselogging.googleapis.com does not connect; traces are lost.

Transport probe:

curl -sS -o /dev/null -w "fireperf code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://firebaselogging.googleapis.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

China alternatives. Tencent Bugly performance, Alibaba ARMS RUM, self-hosted OpenTelemetry collector on domestic infrastructure.

Google Analytics (Firebase Analytics)

What it does. Event analytics bundled with Firebase; feeds GA4.

Mainland China behavior. Mixed → Degraded. The collection host app-measurement.com is reachable (404, 0.20s), so some events may upload — but the Firebase SDK initializes through blocked *.googleapis.com endpoints, so China DAU/MAU is still systematically undercounted.

Transport probe:

curl -sS -o /dev/null -w "app-measurement code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://app-measurement.com/"

cn-beijing (2026-06-25): Reachable — code=404 total=0.20s (collection host answers; SDK init still degrades).

China alternatives. Umeng+, Sensors Data, GrowingIO — SDK in the China app flavor; keep GA4 for global builds only. Landscape shortlist: Firebase Analytics alternatives. For the wider measurement picture, see analytics and measurement in China and Google Tag Manager in China.

A/B Testing

What it does. Experiment assignment powered by Analytics + Remote Config.

Mainland China behavior. Degraded — Remote Config is Blocked from cn-beijing, so experiment assignment cannot be fetched; China users land in control with no exposure logged.

How to probe. Run the Remote Config + Analytics probes above; confirm experiment assignment events in debug mode from a Mainland China test device.

China alternatives. Run experiments through whichever domestic analytics + config stack you adopt for China; or segment by app flavor at the API layer.

In-App Messaging

What it does. Targeted in-app banners triggered by Analytics events.

Mainland China behavior. Degraded — campaign fetch depends on the same Google endpoints as Remote Config (Blocked) and Analytics.

How to probe. Same hosts as the Analytics + Remote Config probes; validate with Firebase Debug mode on a Mainland China device.

China alternatives. Domestic push/in-app message platforms (Alibaba Cloud EMAS, JPush, Getui in-app message) or server-driven UI flags via your China API.

App Distribution

What it does. Pre-release APK/IPA distribution to testers.

Mainland China behavior. Blocked for download — appdistribution.firebase.google.com does not connect from cn-beijing. Developer workflow only; not an end-user concern.

Transport probe:

curl -sS -o /dev/null -w "appdistribution code=%{http_code} total=%{time_total}s\n" \
 --connect-timeout 10 --max-time 20 \
 "https://appdistribution.firebase.google.com/"

cn-beijing (2026-06-25): Blocked — code=000 total=10.00s.

China alternatives. Domestic CI artifacts (Tencent Coding, Alibaba DevOps), TestFlight for iOS, or direct APK hosting on OSS with a QR code — not a production user concern. Landscape shortlist: Firebase App Distribution alternatives.

Test Lab

What it does. Cloud device farm for automated UI tests.

Mainland China behavior. N/A — CI infrastructure, not user-facing. China users never touch it.

No replacement needed for production; use local devices or domestic CI if Test Lab itself is slow to reach from your China office network. Landscape shortlist: Firebase Test Lab alternatives.

Developer tooling (not on the user path)

These products appear on the Firebase pricing page but do not affect China end users directly:

Product	Verdict	Notes
Firebase Studio	N/A	Online IDE — blocked in Mainland China browsers is annoying for devs, not users
Gemini in Firebase	N/A	Console AI assist — use offline or via VPN for development only
BigQuery export	N/A	Backend analytics pipeline — runs in GCP, not on client devices

How to sequence replacements

Do not migrate everything at once. Use probe results on your China traffic share:

1. FCM first — clearest failure, longest OEM integration. Ship domestic push before marketing in China app stores.
2. Auth second — login is fully Blocked from cn-beijing; nothing else matters if users cannot sign in. Add WeChat/phone via domestic IDaaS while keeping Firebase for global builds.
3. Data third — Firestore and Storage are Blocked; the Realtime Database happens to be reachable from our node, but do not bet a product on that — justify migration when China MAU and realtime features demand it.
4. Observability fourth — Crashlytics and Analytics hosts partly answer but degrade silently; swap early if you rely on crash-free metrics for release gates.

For the broader backend picture, see Which parts of your stack break first in China.

Filing and network reachability are separate problems: a domestic replacement that serves a public-facing site or app in China still needs its own filing track — see ICP and PSB filing explained.

References

• AWS China (Beijing & Ningxia) regional product services — the authoritative list of services available in the AWS China regions, used to map the AWS-first alternatives above. AWS China runs on separate accounts operated by Sinnet (Beijing) and NWCD (Ningxia); public-facing web still requires ICP filing.
• Firebase product list & pricing — the full Firebase product surface mapped in this guide.

The probes above are open and reproducible: clone the kit, fill your project config, and run npm run probe:all from a Mainland China host to regenerate this evidence on your own traffic path. Chinaready ran them from a Beijing node on 2026-06-25 so global product teams can start from real numbers — then map only the failures to domestic replacements, with evidence, not guesswork.

What we can offer?

Firebase is not one decision but a per-function one: from cn-beijing on 2026-06-25 Auth, Firestore, Storage, Functions, FCM, and Remote Config were Blocked while the Realtime Database answered — so the work is replacing the measured failures in the right order, not rebuilding the product. Chinaready helps your team close that loop:

1. China Readiness Assessment — Re-run these probes on your own traffic path and turn the per-product verdicts into a sequenced replacement plan (push first, auth second, data third, observability fourth) instead of a full backend rewrite.
2. China Access Acceleration — Keep the China-facing origin and assets reachable while blocked Google endpoints such as oauth2.googleapis.com come off the critical path.
3. China Product Hosting — Place the domestic auth, data, storage, and function tiers in a cn-* region so your China build stops depending on hosts that do not answer, with the filing track handled alongside.
4. Mobile App Distribution — Wire OEM push, domestic SMS, and China analytics into the China app flavor so the store build actually works after launch.

Contact us when your China build still depends on Firebase endpoints that do not answer — and you want the replacement sequence backed by measurement rather than guesswork.