Firebase EU Alternative 2026: GDPR, CLOUD Act, and the Google Analytics Precedent

Post #674 in the sota.io EU Compliance Series

Firebase is Google's flagship application development platform. It bundles a NoSQL database, authentication, file storage, push notifications, serverless functions, hosting, analytics, and crash reporting into a single SDK. For developers building mobile or web apps, Firebase eliminates most backend complexity and integrates seamlessly with the rest of Google Cloud.

Firebase has a European data residency option. It has a Google Cloud Data Processing Addendum. It has ISO 27001 and SOC 2 certifications. On paper, it looks like it can be used compliantly in the EU.

The problem is not where Firebase stores your data. The problem is who owns the entity that stores it.

Firebase is a product of Google LLC, a subsidiary of Alphabet Inc., headquartered in Mountain View, California. The CLOUD Act (18 U.S.C. § 2713) gives the US government authority to compel Google to produce data held anywhere in the world — including EU-region Firebase projects — regardless of what the GDPR says about international transfers.

Firebase also carries a compliance liability that no other US cloud platform shares: it has already been declared illegal for EU use by multiple national data protection authorities. The Austrian Datenschutzbehörde (DSB) ruled in January 2022 that Firebase Analytics (then part of Google Analytics 4) violated GDPR Article 44 because no valid transfer mechanism can override CLOUD Act and FISA Section 702. France, Italy, Denmark, and Norway followed with equivalent rulings. Firebase Analytics has been found incompatible with GDPR by EU regulators — not as a theoretical risk, but as a matter of binding enforcement.

This post analyses Firebase's full GDPR and CLOUD Act exposure, explains what the DSB ruling means for developers using any Firebase service (not just Analytics), and provides a complete comparison of EU-native Firebase alternatives for 2026.

What Firebase Actually Is

Firebase bundles ten distinct services, each with its own data processing surface:

Every one of these services is a Google product. Every one runs on infrastructure owned by Alphabet Inc., a US corporation subject to CLOUD Act compulsion. Your EU users' data — authentication state, database documents, storage files, push tokens, crash reports — flows through Google's systems.

The Jurisdiction Stack

When an EU user interacts with a Firebase-backed application, the data path looks like this:

EU User (Germany, France, Netherlands)
    ↓
Firebase SDK (in user's browser or mobile device)
    ↓
Google's EU-region servers (Frankfurt / Belgium)
    ↓
Google Ireland Limited (EU entity, GDPR DPA signatory)
    ↓
Google LLC (Mountain View, CA — CLOUD Act jurisdiction)
    ↓
Alphabet Inc. (ultimate parent, Nasdaq-listed US corporation)

The critical layer is Google LLC. Google Ireland Limited acts as the EU data controller or processor for GDPR purposes, but it is a wholly-owned subsidiary of a US entity with full operational dependency on US infrastructure, US corporate governance, and US legal obligations.

Under the CLOUD Act (18 U.S.C. § 2713), Google LLC can be compelled to produce "the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber" — regardless of whether that data is held domestically or abroad. Google Ireland cannot unilaterally refuse such an order; it operates within Google's global infrastructure and cannot meaningfully segregate EU data from US corporate control.

FISA Section 702 adds a parallel pathway. National Security Letters under 18 U.S.C. § 2709 add a third. None of these mechanisms require a court order visible to the data subject or the EU data controller.

The DSB Ruling: Firebase Analytics Is Illegal in the EU

In January 2022, the Austrian Datenschutzbehörde issued a landmark ruling (Case D155.027 / 2021-0.586.257) that directly affects Firebase users. The case was brought by noyb (Max Schrems' privacy organisation) against an Austrian website that used Google Analytics 4 — which uses Firebase infrastructure — to track EU visitors.

The DSB found:

1. IP addresses and client identifiers are personal data. Even pseudonymised identifiers qualify as personal data under GDPR Article 4(1) because Google can re-identify them.

2. Standard Contractual Clauses (SCCs) are not sufficient. The SCCs that Google provides in its Data Processing Addendum cannot override CLOUD Act and FISA 702. Google is legally required to comply with US government data requests that would violate GDPR if made to an EU entity. SCCs cannot neutralise this obligation.

3. Supplementary measures are inadequate. Google's encryption and pseudonymisation do not help because Google holds the encryption keys. Technical measures only work if the data processor cannot access the plaintext — Google plainly can.

4. The transfer to the US violates GDPR Article 44. There is no valid transfer mechanism that makes Firebase Analytics legal under GDPR as long as CLOUD Act and FISA 702 remain in force.

The ruling covers Firebase Analytics specifically, but its legal reasoning applies to every Firebase service. The structural problem — a US entity with access to EU user data — is identical whether the service is Analytics, Auth, Firestore, or FCM. The DSB ruling is the first domino, not the last.

Subsequent enforcement actions (2022–2026):

• France (CNIL): January 2022 — declared Google Analytics illegal, formal notice to website operators
• Italy (Garante): June 2022 — ordered Italian websites using GA to stop or migrate
• Denmark (Datatilsynet): September 2022 — same conclusion, same legal reasoning
• Norway (Datatilsynet): 2023 — coordinated noyb complaint, equivalent ruling
• Netherlands (AP): 2023 — Google Analytics transfers deemed non-compliant without supplementary measures

Five national DPAs have now ruled that Firebase/Google Analytics violates GDPR. The legal ground has not changed; CLOUD Act and FISA 702 remain in force.

Firebase Auth: The Session Token Problem

Firebase Authentication uses Google Identity Platform as its backend. When a user signs into a Firebase app, their session is managed by Google's servers. Specifically:

• ID tokens (JWTs) are signed by Google's private keys, held on Google servers
• Refresh tokens are stored and validated by Google's authentication infrastructure
• OAuth flows (Sign in with Google, Apple, GitHub) are proxied through Firebase Auth servers
• Phone authentication (SMS OTP) routes through Google's telephony services
• Multi-factor authentication state is held by Google Identity Platform

This means Google knows:

• Which users are authenticated at any moment
• When users last logged in
• Which devices are used (via device fingerprinting in the Firebase SDK)
• Account linkage across identity providers

Under CLOUD Act, the US government can request the full session history, login timestamps, device identifiers, and linked OAuth accounts for any Firebase user — including EU citizens. A DPA-signed Data Processing Addendum does not change what Google is legally required to hand over.

Cloud Firestore and Realtime Database: Data Residency vs Legal Residency

Firebase offers data residency for Cloud Firestore. Developers can pin a Firestore database to europe-west1 (Belgium), europe-west2 (London), or europe-west3 (Frankfurt). This means bytes are stored on servers in the EU.

However, data residency is not the same as legal jurisdiction. The entity controlling that data is Google LLC — a US corporation. The CLOUD Act compels Google LLC, not the servers. Where the bytes sit is irrelevant to the legal obligation.

Additionally, Firestore has architectural dependencies on Google's global infrastructure:

• Indexing is managed by Google's global Spanner clusters
• Security rules evaluation runs in Google's infrastructure
• Admin SDK access routes through Google's APIs regardless of region
• Firebase console access — your DBA team's dashboard — routes through Google US systems

For Firebase Realtime Database, there is no EU region. The service runs in us-central1 (Iowa). All EU user data in Realtime Database is stored in the United States with no residency option.

Firebase Cloud Messaging: Push Notification Privacy

Firebase Cloud Messaging (FCM) is the dominant push notification service for Android applications (APNs handles iOS). FCM processes:

• Registration tokens — unique identifiers that link a device to a Firebase project
• Notification payloads — the content of push notifications sent to EU users
• Delivery receipts — when a user received and opened a notification
• Topic subscriptions — segmentation data (e.g., which users subscribed to which notification categories)

FCM runs entirely on Google's US-controlled infrastructure. There is no EU region for FCM. Every push notification sent to an EU user passes through Google's servers.

The delivery receipt data is particularly sensitive. It reveals when individual EU users are active on their devices, which notifications they open, and their notification engagement patterns. This constitutes behavioural data processing under GDPR.

Firebase Crashlytics and Performance Monitoring

Crashlytics (acquired by Google in 2017) processes crash reports that typically contain:

• Stack traces with code paths and variable states
• Device identifiers (installation UUID, platform, OS version)
• User identifiers if set by the developer via setUserId()
• Custom keys — developer-defined metadata attached to crash reports
• Session data — what the user was doing before the crash

Firebase Performance Monitoring captures network request URLs, response times, custom traces, and screen rendering metrics. Combined with device identifiers, this constitutes detailed behavioural profiling of EU users.

Both services run exclusively on Google US infrastructure. Neither has an EU data residency option.

What Google's DPA Actually Covers

Google's Cloud Data Processing Addendum (DPA) version 3.0 (current as of 2026) includes:

• ✅ Standard Contractual Clauses for international transfers
• ✅ GDPR Article 28 processor obligations
• ✅ Sub-processor list disclosure
• ✅ Data deletion timelines
• ✅ Security measures documentation
• ✅ Data breach notification (72 hours)

What the DPA cannot cover:

• ❌ CLOUD Act orders — Google's legal obligation supersedes contract
• ❌ FISA 702 surveillance — no warrant required, no notification to data subject
• ❌ National Security Letters — gag orders prevent disclosure
• ❌ SCCs become void when US law mandates disclosure (Schrems II / C-311/18)
• ❌ Firebase Realtime Database (no EU region — data in US)
• ❌ FCM (no EU region — US infrastructure)
• ❌ Crashlytics (no EU region — US infrastructure)

The SCCs in Google's DPA are not invalid on their own merits. They become unenforceable when applied to a US entity subject to CLOUD Act, because the DPA's commitments are subordinate to US federal law.

Python: Firebase Compliance Analyser

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional

class RiskLevel(str, Enum):
    HIGH = "HIGH"
    MEDIUM = "MEDIUM"
    LOW = "LOW"
    COMPLIANT = "COMPLIANT"

class EURegion(str, Enum):
    AVAILABLE = "EU region available"
    PARTIAL = "EU region partial"
    NONE = "No EU region — US only"

@dataclass
class FirebaseServiceRisk:
    service: str
    eu_region: EURegion
    processes_pii: bool
    cloud_act_exposure: RiskLevel
    dsb_ruling_applies: bool
    notes: str
    gdpr_recommendation: str

@dataclass
class FirebaseComplianceReport:
    services: list[FirebaseServiceRisk] = field(default_factory=list)

    def add(self, svc: FirebaseServiceRisk):
        self.services.append(svc)

    def high_risk_count(self) -> int:
        return sum(1 for s in self.services if s.cloud_act_exposure == RiskLevel.HIGH)

    def dsb_affected_count(self) -> int:
        return sum(1 for s in self.services if s.dsb_ruling_applies)

    def summary(self) -> str:
        high = self.high_risk_count()
        dsb = self.dsb_affected_count()
        return (
            f"Firebase Compliance Summary\n"
            f"  Services analysed: {len(self.services)}\n"
            f"  HIGH risk (CLOUD Act): {high}/{len(self.services)}\n"
            f"  DSB ruling applies: {dsb}/{len(self.services)}\n"
            f"  Overall verdict: {'NON-COMPLIANT' if high > 0 else 'REVIEW REQUIRED'}"
        )

def analyse_firebase_compliance() -> FirebaseComplianceReport:
    report = FirebaseComplianceReport()

    report.add(FirebaseServiceRisk(
        service="Firebase Analytics",
        eu_region=EURegion.NONE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=True,
        notes="Austrian DSB Jan 2022: declared illegal under GDPR Art.44. "
              "Five DPAs (AT, FR, IT, DK, NO) have issued equivalent rulings.",
        gdpr_recommendation="Remove immediately. Replace with Plausible (EU-hosted) or Matomo self-hosted.",
    ))

    report.add(FirebaseServiceRisk(
        service="Firebase Authentication",
        eu_region=EURegion.NONE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=True,
        notes="Google Identity Platform. Auth tokens signed by Google keys. "
              "Login timestamps, device IDs, OAuth linkage — all US entity.",
        gdpr_recommendation="Migrate to self-hosted Auth (Lucia, Authjs) or EU-native IdP (Keycloak).",
    ))

    report.add(FirebaseServiceRisk(
        service="Cloud Firestore",
        eu_region=EURegion.PARTIAL,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=False,
        notes="EU region available (europe-west1/2/3). Data stored in EU. "
              "But Google LLC controls the data — CLOUD Act applies regardless of server location.",
        gdpr_recommendation="Migrate to EU-native Postgres (Supabase self-hosted, PlanetScale EU, Neon EU).",
    ))

    report.add(FirebaseServiceRisk(
        service="Firebase Realtime Database",
        eu_region=EURegion.NONE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=False,
        notes="No EU region. Data stored in us-central1 (Iowa). "
              "Entire database in US territory and US legal jurisdiction.",
        gdpr_recommendation="Migrate to Firestore EU region or self-hosted Redis/Postgres.",
    ))

    report.add(FirebaseServiceRisk(
        service="Firebase Cloud Messaging (FCM)",
        eu_region=EURegion.NONE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=False,
        notes="No EU region. Registration tokens, notification payloads, delivery receipts "
              "all processed by Google US infrastructure.",
        gdpr_recommendation="Accept risk or replace with ntfy.sh (self-hosted) or OneSignal EU.",
    ))

    report.add(FirebaseServiceRisk(
        service="Firebase Crashlytics",
        eu_region=EURegion.NONE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=False,
        notes="Device fingerprints, installation UUIDs, user IDs, session state. "
              "No EU region. Behavioural data on US infrastructure.",
        gdpr_recommendation="Replace with Sentry (EU region, German entity available) or self-hosted Sentry.",
    ))

    report.add(FirebaseServiceRisk(
        service="Firebase Hosting",
        eu_region=EURegion.PARTIAL,
        processes_pii=False,
        cloud_act_exposure=RiskLevel.MEDIUM,
        dsb_ruling_applies=False,
        notes="Static asset delivery via Google CDN. Low PII risk for pure static assets. "
              "Firebase Hosting Analytics still routes to Google.",
        gdpr_recommendation="Low risk for static assets. Disable hosting analytics. "
                             "Consider Cloudflare Pages (EU-entity option available).",
    ))

    report.add(FirebaseServiceRisk(
        service="Cloud Functions for Firebase",
        eu_region=EURegion.AVAILABLE,
        processes_pii=True,
        cloud_act_exposure=RiskLevel.HIGH,
        dsb_ruling_applies=False,
        notes="EU region deployable (europe-west1). But Google LLC controls runtime. "
              "Function logs, environment variables, invocation metadata all Google-accessible.",
        gdpr_recommendation="Migrate to EU-native serverless (Hetzner, sota.io, fly.io EU, Scaleway Functions).",
    ))

    return report

if __name__ == "__main__":
    report = analyse_firebase_compliance()
    print(report.summary())
    print()
    for svc in report.services:
        risk_icon = "🔴" if svc.cloud_act_exposure == RiskLevel.HIGH else "🟡"
        region_icon = "❌" if svc.eu_region == EURegion.NONE else "⚠️"
        print(f"{risk_icon} {svc.service} [{svc.eu_region.value}]")
        print(f"   CLOUD Act: {svc.cloud_act_exposure.value}")
        if svc.dsb_ruling_applies:
            print(f"   ⚠️  DSB ruling APPLIES")
        print(f"   → {svc.gdpr_recommendation}")
        print()

EU-Native Firebase Alternatives: Comparison

For teams wanting a full migration away from Firebase:

Appwrite provides Auth, Database, Storage, Functions, and Messaging in a single self-hostable package. It is the closest functional equivalent to Firebase that can run entirely on EU infrastructure under your legal control.

PocketBase is a single-binary backend that handles Auth, Database (SQLite), and Storage. It is minimal, fast, and trivially self-hosted on any EU VPS.

For the serverless functions layer, sota.io provides a GDPR-native PaaS running exclusively on Hetzner infrastructure in Frankfurt. Unlike Firebase Cloud Functions, there is no US parent entity in the chain.

Migration Path: Firebase to EU-Native Stack

A Firebase-to-EU migration typically follows this order:

Step 1: Remove Firebase Analytics (Immediate, Low Risk)

Firebase Analytics removal is non-destructive. Add Plausible's script tag or self-host Matomo. Remove the Firebase Analytics SDK import. This eliminates the DSB-ruled illegal component with zero data migration.

# Remove Firebase Analytics from package.json
npm uninstall @firebase/analytics

# Replace with Plausible (EU-hosted, no cookies, GDPR-native)
# Add to HTML: <script defer data-domain="yourdomain.com"
#   src="https://plausible.io/js/script.js"></script>

Step 2: Migrate Authentication (Medium Effort)

Keycloak is the most capable EU-native Auth replacement for enterprise use cases. For simpler apps, Lucia Auth (a TypeScript library) combined with your own Postgres gives full control.

# Deploy Keycloak on EU infrastructure
docker run -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=changeme \
  quay.io/keycloak/keycloak:24.0 start-dev

# Export Firebase users (Firebase Admin SDK)
firebase auth:export users.json --format=JSON

# Map Firebase custom claims to Keycloak roles
# Migrate refresh tokens: users re-authenticate once

Step 3: Migrate Firestore to PostgreSQL (Highest Effort)

Firestore's document model maps naturally to JSONB columns in PostgreSQL.

import firebase_admin
from firebase_admin import credentials, firestore
import psycopg2
import json

def migrate_collection(collection_name: str, pg_conn):
    """Migrate a Firestore collection to PostgreSQL JSONB table."""
    db = firestore.client()
    docs = db.collection(collection_name).stream()

    with pg_conn.cursor() as cur:
        cur.execute(f"""
            CREATE TABLE IF NOT EXISTS {collection_name} (
                id TEXT PRIMARY KEY,
                data JSONB NOT NULL,
                created_at TIMESTAMPTZ DEFAULT NOW()
            )
        """)

        for doc in docs:
            data = doc.to_dict()
            cur.execute(
                f"INSERT INTO {collection_name} (id, data) VALUES (%s, %s) "
                f"ON CONFLICT (id) DO UPDATE SET data = EXCLUDED.data",
                (doc.id, json.dumps(data, default=str))
            )

    pg_conn.commit()
    print(f"Migrated collection: {collection_name}")

Step 4: Replace Cloud Storage with MinIO or Hetzner Object Storage

import boto3
from google.cloud import storage as gcs

def migrate_firebase_storage(bucket_name: str, minio_endpoint: str):
    """Migrate Firebase Storage bucket to MinIO."""
    gcs_client = gcs.Client()
    gcs_bucket = gcs_client.bucket(bucket_name)

    s3 = boto3.client(
        "s3",
        endpoint_url=minio_endpoint,
        aws_access_key_id="your-minio-key",
        aws_secret_access_key="your-minio-secret",
    )

    for blob in gcs_bucket.list_blobs():
        data = blob.download_as_bytes()
        s3.put_object(
            Bucket=bucket_name,
            Key=blob.name,
            Body=data,
            ContentType=blob.content_type or "application/octet-stream",
        )
        print(f"Migrated: {blob.name}")

GDPR Compliance Checklist for Firebase Users

The Practical Reality

Firebase's GDPR risk varies significantly by use case:

High-risk use cases (migrate urgently):

• Healthcare apps (patient data in Firestore = sensitive category under GDPR Art.9)
• Financial services (financial data subject to DORA + GDPR Art.9)
• Apps targeting minors (GDPR Art.8, higher DPA scrutiny)
• B2B SaaS for EU companies (enterprise customers increasingly require EU-entity processors)
• Any app using Firebase Analytics (DSB ruling = currently illegal, no valid SCC remedy)

Medium-risk use cases (assess and document):

• Consumer apps with email/username authentication
• Apps using Firestore in EU region for non-sensitive data
• Hobbyist or side-project scale with no commercial user base

Lower-risk use cases (document but no urgent migration needed):

• Internal tooling with employees as data subjects (B2B context, employer relationship)
• Apps where users are all outside the EU
• Firebase Hosting for pure static sites with no tracking

The fundamental question is not "is Firebase compliant?" (it is not, by EU DPA consensus) but "what is my specific enforcement risk given the data I process?" Small apps with no sensitive data have low enforcement exposure. Apps in healthcare, finance, or education handling EU citizen data at scale face meaningful DPA investigation risk.

Why This Matters for Developers Building on Firebase Today

The Austrian DSB ruling was issued in January 2022. Four years later, Google Analytics remains the most used analytics tool in the world, and Firebase remains dominant in mobile app development. Enforcement has been uneven — most developers using Firebase Analytics have not been fined.

But the legal landscape is tightening:

1. noyb has filed complaints against hundreds of EU companies. They systematically identify GDPR violations and file complaints with DPAs that have a legal obligation to investigate.

2. GDPR fines are cumulative with DMA/DSA. The EU's Digital Markets Act (DMA) and Digital Services Act (DSA) add additional compliance layers specifically targeting Google's role as a gatekeeper.

3. Enterprise procurement is changing. EU public sector procurement and large enterprise B2B increasingly require that cloud services be provided by EU-entity processors. Firebase's use of Google LLC as the controlling entity fails this requirement.

4. Data Protection Officers are getting more aggressive. DPOs at German, French, and Dutch companies have increasingly flagged Firebase as a blocked service in internal tooling decisions.

The trajectory is clear: the EU is systematically dismantling the legal cover that US cloud providers have relied on since Schrems I (2015). Firebase Analytics was the first explicitly ruled illegal Google service. It will not be the last.

For developers building new applications in 2026, the cost of migrating away from Firebase later is substantially higher than choosing EU-native tools from the start.

See Also

• Supabase EU Alternative 2026: GDPR, CLOUD Act, and the BaaS Jurisdiction Problem
• GCP EU Alternative 2026: Google Cloud GDPR Exposure and EU-Native Replacements
• AWS European Sovereign Cloud: Why It Does Not Solve the CLOUD Act Problem
• GDPR Article 44: Third Country Transfer Rules and What They Mean for Your Cloud Stack
• Vercel EU Alternative 2026: GDPR, CLOUD Act, and the Next.js Deployment Jurisdiction Problem — Vercel Analytics carries same DSB D155.027 legal basis as Firebase Analytics