Mode natif : quotas et limites

Cette page décrit les quotas de requêtes et les limites de l'édition Enterprise pour Cloud Firestore en mode natif.

Utilisation du niveau sans frais

Cloud Firestore en mode natif propose un niveau sans frais qui vous permet de démarrer sans frais. Les montants du niveau sans frais sont indiqués dans le tableau suivant.

Les montants du niveau sans frais sont appliqués quotidiennement et réinitialisés à minuit, heure du Pacifique.

La version sans frais ne s'applique qu'à une seule base de données Cloud Firestore par projet. La première base de données créée dans un projet sans base de données de niveau sans frais bénéficiera du niveau sans frais. Si la base de données avec le niveau sans frais appliqué est supprimée, la base de données suivante créée bénéficiera du niveau sans frais.

Niveau sans frais Quotas
Données stockées 1 Gio
Unités de lecture 50 000 par jour
Unités de mises à jour en temps réel 50 000 par jour
Unités d'écriture 40 000 par jour
Transfert de données sortant 10 Gio par mois

Limites standards

Les limites applicables à Cloud Firestore en mode natif sont présentées dans les tableaux suivants. Sauf indication contraire, ces limites sont strictes.

Bases de données

Limite Détails
Nombre maximal de bases de données par projet

100

Vous pouvez contacter l'assistance pour demander à augmenter cette limite.

Nombre maximal de bases de données CMEK (Customer-Managed Encryption Key) par projet

0

Par défaut, le quota est défini sur 0, car cette fonctionnalité est disponible uniquement sur une liste d'autorisation. Vous pouvez demander à augmenter le quota en remplissant le formulaire de demande d'accès CMEK.

Collections, documents et champs

Limite Détails
Contraintes sur les ID de collection
  • Doivent être des caractères UTF-8 valides
  • Ne doivent pas dépasser 1 500 octets
  • Ne doivent pas contenir de barre oblique (/)
  • Ne doivent pas être composés d'un seul point (.) ni de doubles points (..)
  • Ne doivent pas correspondre à une expression régulière __.*__
Profondeur maximale des sous-collections 100
Contraintes sur les ID de document
  • Doivent être des caractères UTF-8 valides
  • Ne doivent pas dépasser 1 500 octets
  • Ne doivent pas contenir de barre oblique (/)
  • Ne doivent pas être composés d'un seul point (.) ni de doubles points (..)
  • Ne doivent pas correspondre à une expression régulière __.*__
  • Si vous importez des entités Datastore vers une base de données Firestore, les ID d'entité numérique sont exposés sous la forme __id[0-9]+__.
Taille maximale d'un nom de document 6 Kio
Taille maximale d'un document 1 Mio (1 048 576 octets)
Contraintes sur les noms de champ
  • Doivent être des caractères UTF-8 valides
  • Ne doivent pas correspondre à une expression régulière __.*__
Taille maximale d'un nom de champ 1 500 octets
Contraintes sur les chemins d'accès des champs
  • Doivent séparer les noms de champ avec un seul point (.)
  • Peut être transmis sous la forme d'une chaîne de segments délimitée par un point (.), où chaque segment est un nom de champ simple ou un nom de champ entre guillemets (défini ci-dessous).
Un nom de champ est simple lorsque toutes les conditions suivantes sont remplies :
  • Le nom de champ ne contient que les caractères a-z, A-Z, 0-9 et le trait de soulignement (_).
  • Il ne commence pas par 0-9.
Un nom de champ entre guillemets commence et se termine par le caractère backtick (`). Par exemple, foo.`x&y` fait référence au champ x&y imbriqué sous le champ foo. Pour construire un nom de champ avec le caractère d'accent grave, échappez-le avec le caractère de barre oblique inverse (\). Pour plus de commodité, vous pouvez éviter les noms de champs entre guillemets en transmettant le chemin d'accès du champ sous la forme d'un objet FieldPath (par exemple, consultez FieldPath JavaScript).
Taille maximale d'un chemin d'accès de champ 1 500 octets
Taille maximale d'une valeur de champ 1 Mio – 89 octets (1 048 487 octets)
Profondeur maximale des champs dans une carte ou un tableau

20

Les champs de carte et de tableau ajoutent un niveau à la profondeur globale d'un objet. Par exemple, l'objet suivant a une profondeur totale de trois niveaux : 


{
  nested_map: {         #depth 1
    nested_array: [     #depth 2
      {
        foo: "bar"      #depth 3
      }
    ]
  }
}

Écritures et transactions

Limite Détails
Taille maximale des requêtes API 10 Mio
Durée maximale d'une transaction 270 secondes, avec un délai d'inactivité avant expiration de 60 secondes
Nombre maximal de transformations de champ pouvant être effectuées dans un seul document via une opération Commit ou une transaction 500

Index

Limite Détails
Nombre maximal d'index pour une base de données

Nombre maximal d'entrées d'index pour chaque document

40 000
Nombre maximal de champs dans un index 100
Taille maximale d'une entrée d'index

7,5 Kio
Somme maximale des tailles d'entrée d'index d'un document

8 Mio

Valeur TTL (Time to Live)

Limite Détails
Nombre maximal de configurations à champ unique pour une base de données

Une configuration au niveau du champ peut contenir plusieurs configurations pour le même champ. Par exemple, une exemption d'indexation à champ unique et une règle TTL sur le même champ comptent comme une seule configuration de champ pour la limite.

Exportation/Importation

Les limites ci-dessous sont appliquées aux opérations d'importation et d'exportation gérées :

Limite Détails
Nombre maximal total de requêtes d'exportation et d'importation autorisé par minute pour un projet 20
Nombre maximal d'exportations et d'importations simultanées 50
Nombre maximal de filtres d'ID de collection autorisé pour les requêtes d'exportation et d'importation 100

Règles de sécurité

Limite Détails
Nombre maximal d'appels de méthode exists(), get() et getAfter() par requête
  • 10 pour les requêtes de documents uniques et les requêtes de type "query".

  • 20 pour les lectures de plusieurs documents, les transactions et les écritures par lot. La limite de 10 précédente s'applique également à chaque opération.

    Par exemple, imaginons que vous créez une requête d'écriture par lot comprenant trois opérations, et que vos règles de sécurité utilisent deux appels d'accès au document pour valider chaque écriture. Dans ce cas, chaque écriture utilise deux de ses 10 appels d'accès et la requête d'écriture par lot utilise six de ses 20 appels d'accès.

Le dépassement de l'une ou l'autre limite entraîne une erreur de type "permission refusée".

Certains appels d'accès aux documents peuvent être mis en cache, et les appels en cache ne sont pas pris en compte dans les limites.
Profondeur maximale d'instructions match imbriquées 10
Longueur maximale du chemin, en segments de chemin, autorisée dans un ensemble d'instructions match imbriquées 100
Nombre maximal de variables de capture de chemin autorisées dans un ensemble d'instructions match imbriquées 20
Profondeur maximale des appels de fonction 20
Nombre maximal d'arguments de fonction 7
Nombre maximal de liaisons de variables let par fonction 10
Nombre maximal d'appels de fonction récursifs ou cycliques 0 (non autorisé)
Nombre maximal d'expressions évaluées par requête 1 000
Taille maximale d'un ensemble de règles Les ensembles de règles doivent respecter deux limites de taille :
  • une limite de 256 Ko applicable à la taille du texte source de l'ensemble de règles publié à partir de la console Firebase ou de la CLI à l'aide de firebase deploy.
  • une limite de 250 Ko applicable à la taille de l'ensemble de règles compilé qui apparaît lorsque Firebase traite la source et l'active sur le backend.