Firexport / Blog

L’édition choisie à la création d’une base Firestore, Standard ou Enterprise, ne peut plus changer ensuite. Maintenant que le mode natif de l’édition Enterprise est en disponibilité générale (GA) depuis avril 2026, mieux vaut démarrer les nouvelles applications sur Enterprise. À une condition : gérer vous-même les index et l’accès des clients.

Pourquoi Enterprise est le meilleur choix par défaut

1. Impossible de changer, alors partez du côté qui bloque le moins

L’édition est fixée à la création de la base et ne change plus. En changer, c’est déplacer les données vers une nouvelle base, recréer les index et les réglages de TTL et de sauvegarde, puis publier une version de l’application qui pointe vers la nouvelle base (guide de migration).

Mieux vaut donc partir du côté où vous risquez le moins d’être bloqué. Ce qui bloque sur Standard, ce sont des fonctionnalités comme la recherche, l’agrégation ou les jointures, qu’on contourne en migrant ou en restructurant. Ce qui bloque sur Enterprise, c’est le plus souvent un index manquant : vous le déployez sans toucher au code ni aux données.

2. Le même code, plus de requêtes

Le mode natif d’Enterprise utilise les mêmes SDK Firebase et les mêmes requêtes (opérations Core) que Standard. where(), orderBy(), les écouteurs onSnapshot(), le cache hors connexion et les règles de sécurité fonctionnent tels quels, et il prend en charge l’émulateur local, les déclencheurs Cloud Functions (2e génération), les mêmes régions que Standard et l’usage gratuit du forfait Spark. Une différence : le tri. Les documents qui ont la même valeur de tri ne sont pas départagés par leur ID ; si vous paginez avec des curseurs, ajoutez l’ID du document à votre orderBy.

S’y ajoutent les requêtes Pipeline. Ce qu’il fallait contourner sur Standard tient en une seule requête.

La recherche textuelle, la recherche géospatiale et les modifications et suppressions en masse (DML) sont en disponibilité générale depuis octobre 2026. Mais Pipeline fait des lectures ponctuelles : pas d’écouteurs en temps réel ni de mode hors connexion, et dans Pipeline les règles de sécurité ne comprennent que des filtres simples comparant un champ à une constante. Gardez les listes affichées et les mises à jour en direct sur des requêtes Core, utilisez Pipeline pour la recherche, l’agrégation et les rapports, et exécutez les Pipeline complexes côté serveur (Admin SDK, Cloud Functions).

3. Les lectures indexées coûtent moins cher

Standard facture au nombre de documents, Enterprise aux octets lus et écrits. Voici les prix de us-central1 en novembre 2026.

• Lectures : lire par ID un document de 4 Kio ou moins coûte six fois moins sur Enterprise, et autant ou moins jusqu’à 24 Kio. Les requêtes paient en plus la lecture de l’index : avec un seul résultat, elles coûtent trois fois moins, et plus il y a de résultats, plus on se rapproche de six fois moins.
• Écritures : créer un document de 1 Kio revient moins cher sur Enterprise avec 2 entrées d’index au plus (0,78 $ par million) et plus cher dès 3 (1,04 $). Les mises à jour qui modifient un champ indexé coûtent 2 unités par entrée modifiée ; elles deviennent donc chères plus vite.
• Suppressions : même le plus petit document coûte 1 unité (0,26 $), donc toujours plus que sur Standard (0,10 $).

Si votre application lit bien plus qu’elle n’écrit, Enterprise revient moins cher. Si elle écrit et supprime beaucoup, faites d’abord ce calcul avec la taille de vos documents et votre nombre d’index.

La contrepartie : index et accès sont à votre charge

Standard n’exécute que les requêtes qu’un index peut servir. Chaque champ reçoit un index automatique, et une requête qui a besoin d’un index composite échoue avec une erreur qui donne le lien pour le créer. Le coût d’une requête ne dépend donc que du nombre de résultats.

Enterprise ne crée aucun index et exécute les requêtes même sans index. En contrepartie, il lit toute la collection et facture les octets lus, et il trie en mémoire, ce qui peut atteindre la limite de mémoire par requête (128 Mio). Faute d’erreur, rien ne se voit pendant le développement avec quelques dizaines de documents ; le problème apparaît quand les données grossissent.

Voici ce que coûte un million d’exécutions d’une requête qui cherche un utilisateur par son nom d’utilisateur. Les documents font 2 Kio ; la première ligne est l’exemple de tarification de Google, la seconde le même calcul avec 100 000 documents.

Un seul index fait varier de 25 000 fois le coût de la même requête (100 000 × 2 Kio ÷ 4 Kio = 50 000 unités par requête).

D’autres peuvent aussi exploiter cet écart. Si des clients peuvent lister une collection, n’importe qui peut ajouter un filtre sur un champ non indexé et faire parcourir à Firestore tout ce qu’il a le droit de lire. Rien ne correspond, donc limit n’y change rien, et les règles de sécurité ne peuvent pas bloquer un filtre ajouté à une requête. Sur Standard, une telle requête échoue tout simplement.

Quatre réflexes

1. Écrivez l’index en même temps que la requête. Pour chaque combinaison de where et d’orderBy sur une collection qui continue de grossir, ajoutez un index à firestore.indexes.json et déployez-le avec firebase deploy --only firestore:indexes. Cela inclut les index à champ unique que Standard créait pour vous. Les lectures par ID de document n’ont pas besoin d’index. Voici l’index pour where('authorId', '==', uid).orderBy('createdAt', 'desc') :

   {
     "indexes": [
       {
         "collectionGroup": "posts",
         "queryScope": "COLLECTION",
         "fields": [
           { "fieldPath": "authorId", "order": "ASCENDING" },
           { "fieldPath": "createdAt", "order": "DESCENDING" }
         ]
       }
     ]
   }

2. Vérifiez avec Query Explain avant de publier. Dans la console Firebase, exécutez la même requête dans l’éditeur de requêtes (Query Editor) de l’onglet Données (Data) de Firestore, puis ouvrez l’onglet Query Explain. Si le bas de l’arbre d’exécution est un TableScan, la collection entière a été lue sans index.
3. Encadrez l’accès des clients. Appliquez App Check pour rejeter les requêtes qui ne viennent pas de votre application, et utilisez les règles de sécurité pour lier les lectures de liste à une égalité sur un champ indexé, comme resource.data.ownerId == request.auth.uid. Ainsi, si quelqu’un déclenche un parcours, il reste limité aux documents de cet utilisateur.
4. Activez Query Insights et les alertes budgétaires. Query Insights montre vos requêtes fréquentes et leurs performances, ce qui indique où il manque un index. Avec le forfait Blaze, configurez aussi une alerte budgétaire Cloud Billing.

Démarrer sur Enterprise

Dans la console Firebase, ouvrez Firestore, cliquez sur Créer une base de données (Create database), choisissez Enterprise et le mode natif (Native mode), puis définissez un ID et un emplacement. Laissez les mises à jour en temps réel (Realtime Updates) activées, ce qui est le réglage par défaut. Elles ne peuvent plus changer ensuite, et une base créée sans elles ne peut pas servir d’écouteurs. Ensuite, trois choses diffèrent de Standard.

1. Passez l’ID de la base dans votre code. Une base Enterprise est une base que vous nommez vous-même ; (default) n’existe que sur Standard. Les SDK se connectent à (default) si vous ne leur indiquez rien d’autre.

   // Web
   const db = getFirestore(app, 'app-db');
   
   // Android (Kotlin)
   val db = FirebaseFirestore.getInstance("app-db")
   
   // iOS (Swift)
   let db = Firestore.firestore(database: "app-db")
   
   // Flutter
   final db = FirebaseFirestore.instanceFor(
       app: Firebase.app(), databaseId: 'app-db');

2. Indiquez la base et l’édition dans firebase.json. Les règles et les index sont alors déployés sur cette base, et l’émulateur démarre en Enterprise. Créez d’abord la base dans la console. Si la base indiquée n’existe pas, firebase deploy la crée à votre place, et Firebase CLI 15.12 la crée alors en mode de compatibilité MongoDB, inutilisable par les SDK Firebase.

   {
     "firestore": {
       "database": "app-db",
       "edition": "enterprise",
       "rules": "firestore.rules",
       "indexes": "firestore.indexes.json"
     }
   }

3. L’usage gratuit va à la première base créée, et à elle seule. Si le projet contient une base Standard que vous n’utilisez pas, supprimez-la avant de créer la base Enterprise, pour que l’usage gratuit revienne à Enterprise.

Quand Standard reste le meilleur choix

• Les applications qui tournent déjà sur Standard. Ne migrez pas tant que vous n’avez pas vraiment besoin de Pipeline.
• Les projets où personne ne surveille requêtes et index. Le refus de Standard d’exécuter une requête sans index vous sert de filet de sécurité.
• Les applications dont les clients lisent directement de grandes collections publiques. Sur les listes publiques que les règles ne peuvent pas restreindre, n’importe qui peut déclencher un parcours complet.
• Les applications qui écrivent et suppriment beaucoup, ou lisent surtout de gros documents. Au-delà des seuils ci-dessus, Standard revient moins cher.
• Quand vous avez besoin d’outils qui supposent la base (default) ou Cloud Functions de 1re génération. Les bases Enterprise sont nommées, et les déclencheurs de 1re génération ne les prennent pas en charge.

Sources

• Éditions de Firestore, comparaison des éditions en mode natif, présentation du mode natif d’Enterprise : différences de fonctionnalités, d’index, de tri et de parcours
• Tarifs d’Enterprise, exemples de tarifs des requêtes, exemples de tarifs des écritures et suppressions, tarifs de Firebase : prix et usage gratuit
• Migrer de Standard vers Enterprise, notes de version de Firestore
• Premiers pas avec Enterprise, gérer les bases de données, paramètres de base de données (REST), emplacements, quotas et usage gratuit
• Index d’Enterprise, format JSON des index, Query Explain, Query Insights
• Règles de sécurité pour Pipeline, App Check, déclencheurs Cloud Functions, émulateur