Quotas et limites

Ce document répertorie les quotas et limites qui s'appliquent à BigQuery. Pour en savoir plus sur les quotas, consultez la page Quotas du cloud privé virtuel.

Un quota limite la quantité d'une ressource Google Cloud partagée particulière que votre projet Google Cloud peut utiliser, y compris les composants matériels, logiciels et réseau. Par conséquent, les quotas font partie d'un système qui effectue les opérations suivantes :

• Surveille votre utilisation ou votre consommation des produits et services Google Cloud
• Limite la consommation de ces ressources pour des raisons telles que l'équité et la réduction des pics d'utilisation.
• Gère des configurations qui appliquent automatiquement des restrictions recommandées.
• Fournit un moyen de demander ou d'effectuer des modifications de quota.

Dans la plupart des cas, lorsqu'un quota est dépassé, le système bloque immédiatement l'accès à la ressource Google concernée et la tâche que vous essayez d'effectuer échoue. Dans la plupart des cas, les quotas s'appliquent à chaque projet Google Cloud. Ils sont partagés entre toutes les applications et adresses IP qui utilisent ce projet.

Des limites s'appliquent également aux ressources BigQuery. Ces limites ne sont pas liées au système de quotas. Sauf indication contraire, les limites ne peuvent pas être modifiées.

Par défaut, les quotas et limites de BigQuery s'appliquent par projet. Les quotas et limites qui s'appliquent de manière différente sont indiqués comme tels ; par exemple, le nombre maximal de colonnes par table ou le nombre maximal de requêtes API simultanées par utilisateur. Les règles spécifiques varient en fonction de la disponibilité des ressources, du profil de l'utilisateur, de l'historique d'utilisation du service et d'autres facteurs. Elles peuvent en outre être modifiées sans préavis.

Renouvellement de quota

Les quotas quotidiens sont réapprovisionnés à intervalles réguliers tout au long de la journée, de sorte à inciter les utilisateurs à limiter leur taux de requêtes. Nous procédons en outre à un renouvellement progressif des quotas pour éviter de longues interruptions lorsqu'ils ont été atteints. Au lieu d'être réinitialisés intégralement en une seule fois, ils sont renouvelés au bout de quelques minutes.

Demander une augmentation du quota

Pour demander une augmentation ou une diminution de la plupart des quotas, vous pouvez utiliser Google Cloud Console. Pour en savoir plus, consultez Demander une augmentation de quota.

Pour obtenir des instructions détaillées sur le processus de demande d'augmentation de quota dans la console Google Cloud, cliquez sur Visite guidée :

VISITE GUIDÉE

Limiter l'utilisation des quotas

Pour savoir comment limiter l'utilisation d'une ressource particulière en spécifiant un quota inférieur à celui défini par défaut, consultez la section Limiter l'utilisation des ressources.

Autorisations requises

Pour afficher et mettre à jour vos quotas BigQuery dans la console Google Cloud, vous avez besoin des mêmes autorisations que pour tout quota Google Cloud. Pour plus d'informations, consultez la section Autorisations de quota Google Cloud.

Résoudre les problèmes

Pour en savoir plus sur la résolution des erreurs liées aux quotas et aux limites, consultez la page Résoudre les erreurs de quota BigQuery.

Jobs

Les quotas et les limites s'appliquent aux tâches que BigQuery exécute en votre nom, qu'elles soient exécutées à l'aide de Google Cloud Console, de l'outil de ligne de commande bq ou de manière automatisée à l'aide de l'API REST ou des bibliothèques clientes.

Tâches de requête

Les quotas suivants s'appliquent aux tâches de requête créées automatiquement via l'exécution de requêtes interactives, de requêtes planifiées et de tâches soumises à l'aide de jobs.query et de la méthode d'API jobs.insert de type requête :

Quota	Par défaut	Remarques
Utilisation des requêtes par jour	Illimité	Il n'y a pas de limite au nombre d'octets pouvant être traités par les requêtes dans un projet. Afficher le quota dans la console Google Cloud
Utilisation des requêtes par jour et par utilisateur	Illimité	Il n'y a pas de limite au nombre d'octets que les requêtes d'un utilisateur peuvent traiter chaque jour. Afficher le quota dans la console Google Cloud
Octets de requêtes fédérées Cloud SQL interrégionales par jour	1 To	Si l'emplacement de traitement des requêtes BigQuery et l'emplacement de l'instance Cloud SQL sont différents, votre requête est une requête interrégionale. Votre projet peut exécuter jusqu'à 1 To de requêtes interrégionales par jour. Consultez la page Requêtes fédérées Cloud SQL. Afficher le quota dans la console Google Cloud
Octets transférés entre plusieurs clouds par jour	1 To	Vous pouvez transférer jusqu'à 1 To de données par jour à partir d'un bucket Amazon S3 ou d'Azure Blob Storage. Pour en savoir plus, consultez les sections Transfert intercloud depuis Amazon S3 et Azure. Afficher le quota dans la console Google Cloud

Les limites ci-dessous s'appliquent aux tâches de requête créées automatiquement via l'exécution de requêtes interactives, de requêtes planifiées et de tâches soumises à l'aide de jobs.query et de la méthode d'API jobs.insert de type requête :

Limite	Par défaut	Remarques
Nombre maximal de requêtes interactives en file d'attente	1 000 requêtes	Votre projet peut mettre en file d'attente jusqu'à 1 000 requêtes interactives. Les requêtes interactives supplémentaires qui dépassent cette limite renvoient une erreur de quota.
Nombre maximal de requêtes par lot en file d'attente	20 000 requêtes	Votre projet peut mettre en file d'attente jusqu'à 20 000 requêtes par lot. Les requêtes par lot supplémentaires qui dépassent cette limite renvoient une erreur de quota.
Nombre maximal de requêtes interactives simultanées sur des sources de données externes Bigtable	16 requêtes	Votre projet peut exécuter jusqu'à seize requêtes simultanées sur une source de données externe Bigtable.
Nombre maximal de requêtes simultanées contenant des fonctions distantes	10 requêtes	Vous pouvez exécuter jusqu'à dix requêtes simultanées avec des fonctions distantes par projet.
Nombre maximal de requêtes à plusieurs instructions simultanées	1 000 requêtes à plusieurs instructions	Votre projet peut exécuter jusqu'à 1 000 requêtes à plusieurs instructions simultanées. Pour connaître les autres quotas et limites liés aux requêtes à plusieurs instructions, consultez la section Requêtes à plusieurs instructions.
Nombre maximal de requêtes simultanées en ancien SQL et contenant des fonctions définies par l'utilisateur	6 requêtes	Votre projet peut exécuter jusqu'à six requêtes en ancien SQL simultanées avec des fonctions définies par l'utilisateur. Cette limite inclut les requêtes interactives et les requêtes par lot. Les requêtes interactives contenant des fonctions définies par l'utilisateur sont également comptabilisées dans la limite de requêtes interactives simultanées. Cette limite ne s'applique pas aux requêtes GoogleSQL.
Taille limite des requêtes quotidiennes	Illimité	Par défaut, aucune limite quotidienne ne s'applique à la taille des requêtes. Toutefois, vous pouvez définir des limites sur la quantité de données que les utilisateurs peuvent interroger en créant des quotas personnalisés pour contrôler l'utilisation des requêtes par jour ou l'utilisation des requêtes par jour et par utilisateur.
Limite quotidienne de mises à jour de la table de destination	Consultez la section Nombre maximal d'opérations par table et par jour.	Les mises à jour des tables de destination dans une tâche de requête sont comptabilisées dans la limite du nombre maximal d'opérations de table par jour pour les tables de destination. La mise à jour des tables de destination inclut les opérations d'ajout et d'écrasement que vous effectuez en exécutant des requêtes via Cloud Console ou l'outil de ligne de commande bq, ou bien en appelant les méthodes d'API jobs.query et de type requête jobs.insert.
Délai d'exécution de la requête à plusieurs instructions	6 heures	Une requête (qu'elle soit simple ou à instructions multiples) peut s'exécuter pendant 6 heures au maximum, après quoi elle échoue. Cependant, des requêtes font parfois l'objet de nouvelles tentatives. Une requête peut être tentée trois fois au maximum, et chaque tentative peut durer jusqu'à 6 heures. Par conséquent, il est possible pour une requête d'avoir un temps d'exécution total supérieur à 6 heures. Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des job de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 72 heures.
Nombre maximal de ressources référencées par requête	1 000 Ressources	Une requête peut référencer jusqu'à 1 000 tables, vues, fonctions définies par l'utilisateur (UDF) et fonctions de table uniques après expansion complète. Cette limite inclut les éléments suivants : Tables, vues, fonctions définies par l'utilisateur et fonctions de table directement référencées par la requête. Tables, vues, fonctions définies par l'utilisateur et fonctions de table référencées par d'autres vues/UDF/fonctions de table référencées dans la requête.
Longueur maximale d'une requête non résolue en ancien SQL	256 Ko	Une requête non résolue en ancien SQL peut atteindre 256 Ko. Si votre requête est plus longue, vous obtenez l'erreur suivante : The query is too large. Pour respecter cette limite, envisagez de remplacer les tableaux ou les listes volumineux par des paramètres de requête.
Longueur maximale d'une requête GoogleSQL non résolue	1 Mo	Une requête GoogleSQL non résolue peut atteindre 1 Mo. Si votre requête est plus longue, l'erreur suivante s'affiche : The query is too large.. Pour respecter cette limite, envisagez de remplacer les tableaux ou les listes volumineux par des paramètres de requête.
Longueur maximale d'une requête résolue en ancien SQL et en GoogleSQL	12 Mo	La limite de longueur d'une requête résolue prend en compte la longueur de toutes les vues et tables génériques référencées par la requête.
Nombre maximal de paramètres de requête GoogleSQL	10 000 Paramètres	Une requête GoogleSQL peut comporter jusqu'à 10 000 paramètres.
Taille maximale de requête	10 Mo	La taille de la requête peut atteindre 10 Mo, ce qui inclut des propriétés supplémentaires comme les paramètres de requête.
Taille maximale des réponses	10 Go compressés	La taille varie en fonction des taux de compression des données. La taille de réponse réelle peut être nettement supérieure à 10 Go. La taille de réponse maximale est illimitée dans le cas de l'écriture de résultats de requête volumineux dans une table de destination.
Taille maximale des lignes	100 Mo	La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite maximale de taille de ligne est appliquée à certaines étapes de l'exécution de la tâche de requête.
Nombre maximal de colonnes dans une table, un résultat de requête ou une définition de vue	10 000 colonnes	Une de table, un résultat de requête ou une définition de vue peut contenir jusqu'à 10 000 colonnes.
Nombre maximal d'emplacements simultanés pour la tarification à la demande	2 000 emplacements par projet 20 000 emplacements par organisation	Avec la tarification à la demande, votre projet peut comporter jusqu'à 2 000 emplacements simultanés. Il existe également une limite de 20 000 emplacements simultanés au niveau de l'organisation. Des pneus BigQuery pour allouer des emplacements de manière équitable entre les projets d'une organisation si la demande totale est supérieure à 20 000 emplacements. Les emplacements BigQuery sont partagés entre toutes les requêtes d'un même projet. BigQuery peut passer en utilisation intensive au-delà de cette limite pour accélérer vos requêtes. Pour vérifier le nombre d'emplacements que vous utilisez, consultez la page consacrée à la surveillance de BigQuery avec Cloud Monitoring.
Utilisation maximale du processeur par données analysées pour la tarification à la demande	256 secondes de processeur par Mio analysé	Avec la tarification à la demande, votre requête peut utiliser jusqu'à 256 secondes de processeur par Mio de données analysées. Si votre requête nécessite une utilisation intensive du processeur pour la quantité de données en cours de traitement, la requête échoue avec une erreur billingTierLimitExceeded. Pour en savoir plus, consultez la section billingTierLimitExceeded.
Mutations de tables de transactions multi-instructions	100 tables	Une transaction peut muter des données dans un maximum de 100 tables.
Modifications de partitions de transactions multi-instructions	100 000 modifications de partitions	Une transaction peut effectuer au maximum 100 000 modifications de partitions.
Taille maximale des résultats de requêtes BigQuery Omni	20 Gio non compressés	La taille maximale des résultats est de 20 Gio d'octets logiques lors de l'interrogation de données Azure ou AWS. Si le résultat de votre requête dépasse 20 Gio, envisagez d'exporter les résultats vers Amazon S3 ou Blob Storage. Pour en savoir plus, consultez la page Limites de BigQuery Omni.
Taille totale des résultats de requête BigQuery Omni par jour	1 To	La taille totale des résultats de requête pour un projet est de 1 To par jour. Pour en savoir plus, consultez la page Limites de BigQuery Omni.
Taille maximale des lignes BigQuery Omni	10 Mio	La taille maximale des lignes est de 10 Mio lors de l'interrogation de données Azure ou AWS. Pour en savoir plus, consultez la page Limites de BigQuery Omni.

Bien que les requêtes programmées utilisent des fonctionnalités du service de transfert de données BigQuery, elles ne sont pas des transferts et ne sont pas soumises aux limites de tâches de chargement.

Tâches d'exportation

Les limites suivantes s'appliquent aux tâches d'exportation de données depuis BigQuery à l'aide de l'outil de ligne de commande bq, de la console Google Cloud ou de la méthode d'API jobs.insert de type exportation.

Limite	Par défaut	Remarques
Nombre maximal d'octets exportés par jour	50 To	Vous pouvez exporter gratuitement jusqu'à 50 Tio (tébioctets) de données par jour à partir d'un projet à l'aide du pool d'emplacements partagé. Vous pouvez configurer une règle d'alerte Cloud Monitoring qui fournit une notification sur le nombre d'octets exportés. Pour exporter plus de 50 Tio de données par jour, effectuez l'une des opérations suivantes : Créez une réservation d'emplacement et spécifiez PIPELINE comme type d'attribution. Nous vous facturerons selon la capacité. Utilisez l'instruction SQL EXPORT DATA. Nous vous facturerons à la demande ou selon la capacité, en fonction de la configuration de votre projet. Utilisez l'API Storage Read. Vous serez facturé à l'aide du prix pour les lectures en flux continu. Le délai d'expiration minimal est garanti à au moins 6 heures, à compter de la création de la session.
Nombre maximal de tâches d'exportation par jour	100 000 Exportations	Vous pouvez exécuter jusqu'à 100 000 exportations par jour dans un projet. Pour exécuter plus de 100 000 exportations par jour, effectuez l'une des opérations suivantes : Créez une réservation d'emplacement et spécifiez PIPELINE comme type d'attribution, ou utilisez une attribution PIPELINE existante. Nous vous facturerons selon la capacité. Utilisez l'instruction SQL EXPORT DATA. Nous vous facturerons à la demande ou selon la capacité, en fonction de la configuration de votre projet. Utilisez l'API Storage Read. Vous serez facturé à l'aide du prix pour les lectures en flux continu. Le délai d'expiration minimal est garanti à au moins 6 heures, à compter de la création de la session.
Taille maximale de table exportée vers un seul fichier	1 GB	Vous pouvez exporter jusqu'à 1 Go de données de table dans un seul fichier. Pour exporter plus de 1 Go de données, utilisez un caractère générique pour exporter les données dans plusieurs fichiers. Le cas échéant, la taille des fichiers varie. Dans certains cas, la taille des fichiers de sortie est supérieure à 1 Go.
URI génériques par exportation	500 URI	Une exportation peut comporter jusqu'à 500 URI génériques.

Pour en savoir plus sur votre utilisation actuelle des tâches d'exportation, consultez la page Afficher l'utilisation actuelle des quotas.

Tâches de chargement

Les limites suivantes s'appliquent lorsque vous chargez des données dans BigQuery à l'aide de la console Google Cloud, de l'outil de ligne de commande bq ou de la méthode d'API jobs.insert de type chargement.

Limite	Par défaut	Remarques
Tâches de chargement par table et par jour	1 500 jobs	Les tâches de chargement, y compris celles ayant échoué, sont comptabilisées dans le nombre d'opérations de table par jour pour la table de destination. Pour en savoir plus sur les limites du nombre d'opérations de table par jour pour les tables standards et les tables partitionnées, consultez la page Tables.
Tâches de chargement par jour	100 000 Tâches	Votre projet est réinitialisé avec un quota maximal de 100 000 jobs de chargement toutes les 24 heures. Les tâches de chargement ayant échoué sont comptabilisées dans cette limite. Dans certains cas, il est possible d'exécuter plus de 100 000 jobs de chargement en 24 heures si le quota du jour précédent n'est pas entièrement utilisé.
Nombre maximal de colonnes par table	10 000 colonnes	Une table peut contenir jusqu'à 10 000 colonnes.
Taille maximale par tâche de chargement	15 To	La taille totale de l'ensemble de vos fichiers d'entrée CSV, JSON, Avro, Parquet et ORC peut atteindre 15 To.
Nombre maximal d'URI sources dans la configuration de la tâche	10 000 URI	Une configuration de tâche peut comporter jusqu'à 10 000 URI sources.
Nombre maximal de fichiers par tâche de chargement	10 000 000 fichiers	Une tâche de chargement peut contenir jusqu'à 10 millions de fichiers au total, y compris tous les fichiers correspondant à tous les URI génériques.
Nombre maximal de fichiers dans le bucket Cloud Storage source	Environ 60 000 000 de fichiers	Un job de chargement peut lire les données d'un bucket Cloud Storage contenant jusqu'à 60 000 000 de fichiers environ.
Limite de temps d'exécution d'une tâche de chargement	6 heures	Une tâche de chargement échoue si elle s'exécute pendant plus de six heures.
Avro : taille maximale des blocs de données de fichiers	16 Mo	La taille des blocs de données du fichier Avro est limitée à 16 Mo.
CSV : taille maximale de la cellule	100 Mo	La taille des cellules CSV ne doit pas dépasser 100 Mo.
CSV : taille maximale des lignes	100 Mo	La taille des lignes CSV ne doit pas dépasser 100 Mo.
CSV : taille maximale du fichier compressé	4 Go	La taille des fichiers CSV compressés est limitée à 4 Go.
CSV : taille maximale du fichier, non compressé	5 To	La taille d'un fichier CSV non compressé est limitée à 5 To.
JSON : taille maximale des lignes	100 Mo	La taille des lignes JSON peut atteindre 100 Mo.
JSON : taille maximale du fichier (compressé)	4 Go	La taille d'un fichier JSON compressé est limitée à 4 Go.
JSON : taille de fichier maximale non compressée	5 To	La taille maximale d'un fichier JSON non compressé est de 5 To.

Si vous dépassez régulièrement les limites de tâches de chargement en raison de mises à jour fréquentes, envisagez plutôt de diffuser des données par flux dans BigQuery.

Pour en savoir plus sur l'affichage de votre utilisation actuelle des jobs de chargement, consultez la section Afficher les jobs d'utilisation de quota actuelles.

Considérations relatives aux quotas des tâches de chargement du service de transfert de données BigQuery

Les jobs de chargement créés par les transferts du service de transfert de données BigQuery sont inclus dans les quotas de BigQuery sur les jobs de chargement. Il est important de prendre en compte le nombre de transferts que vous activez dans chaque projet pour éviter que les transferts et d'autres jobs de chargement ne génèrent des erreurs quotaExceeded.

Vous pouvez utiliser l'équation suivante pour faire une estimation du nombre de tâches de chargement dont vos transferts peuvent avoir besoin :

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

Où :

• Number of transfers correspond au nombre de configurations de transfert que vous activez dans votre projet.

• Number of tables correspond au nombre de tables créées par chaque type de transfert spécifique. Le nombre de tables varie selon le type de transfert :

  • Les transferts de Campaign Manager créent environ 25 tables.
  • Les transferts de Google Ads créent environ 60 tables.
  • Les transferts de Google Ad Manager créent environ 40 tables.
  • Les transferts de Google Play créent environ 25 tables.
  • Les transferts de Search Ads 360 créent environ 50 tables.
  • Les transferts de YouTube créent environ 50 tables.

• Schedule frequency décrit la fréquence d'exécution du transfert. Les programmations d'exécution des transferts sont indiquées pour chaque type de transfert :

  • Campaign Manager
  • Google Ads
  • Google Ad Manager
  • Google Merchant Center (bêta)
  • Google Play
  • Search Ads 360 (bêta)
  • Chaîne YouTube
  • Propriétaire de contenu YouTube

• Refresh window correspond au nombre de jours à inclure dans le transfert de données. Si vous saisissez 1, il n'y a pas de remplissage quotidien.

Jobs de copie

Les limites suivantes s'appliquent aux tâches BigQuery permettant de copier des tables, y compris les tâches qui créent une copie, un clone ou un instantané d'une table standard, d'un clone de table ou d'un instantané de table. Elles concernent les jobs créés à l'aide de la console Google Cloud, de l'outil de ligne de commande bq ou de la méthode jobs.insert qui spécifie le champ copy dans la configuration du job. Les tâches de copie sont comptabilisées dans ces limites, qu'elles aboutissent ou non.

Limite	Par défaut	Remarques
Tâches de copie par table de destination et par jour		Consultez la section Opérations de table par jour.
Tâches de copie par jour	100 000 Tâches	Votre projet peut exécuter jusqu'à 100 000 tâches de copie par jour.
Tâches de copie interrégionales par table de destination et par jour	100 Tâches	Votre projet peut exécuter jusqu'à 100 tâches de copie interrégionales par jour et par table de destination.
Tâches de copie interrégionales par jour	2 000 Tâches	Votre projet peut exécuter jusqu'à 2 000 tâches de copie interrégionales par jour.
Nombre de tables sources à copier	1 200 tables sources	Vous pouvez copier jusqu'à 1 200 tables sources par tâche de copie.

Pour en savoir plus sur l'affichage de votre utilisation actuelle des jobs de copie, consultez la section Jobs de copie : afficher les jobs d'utilisation de quota actuelles.

Les limites suivantes s'appliquent à la copie d'ensembles de données :

Limite	Par défaut	Remarques
Nombre maximal de tables dans l'ensemble de données source	20 000 TABLES	Un ensemble de données source peut comporter jusqu'à 20 000 tables.
Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination dans la même région	20 000 TABLES	Votre projet peut copier 20 000 tables par exécution dans un ensemble de données de destination situé dans la même région.
Nombre maximal de tables pouvant être copiées par exécution dans un ensemble de données de destination dans une autre région	1 000 TABLES	Votre projet peut copier 1 000 tables par exécution dans un ensemble de données de destination situé dans une région différente. Par exemple, si vous configurez une copie interrégionale d'un ensemble de données comprenant 8 000 tables, le service de transfert de données BigQuery crée automatiquement huit exécutions de manière séquentielle. La première exécution copie 1 000 tables. Vingt-quatre heures plus tard, la deuxième exécution copie 1 000 tables. Ce processus se poursuit jusqu'à ce que toutes les tables de l'ensemble de données soient copiées, dans la limite de 20 000 tables par ensemble de données.

Réservations

Les quotas suivants s'appliquent aux réservations :

Quotas	Par défaut	Remarques
Nombre total d'emplacements pour la région UE	5 000 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans l'ensemble de la région UE à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour la région États-Unis	10 000 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans l'emplacement multirégional États-Unis à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour la région us-east1	4 000 Emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans la région répertoriée à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions suivantes : asia-south1 asia-southeast1 europe-west2 us-central1 us-west1	2 000 Emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans chacune des régions répertoriées à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions suivantes : asia-east1 asia-northeast1 asia-northeast3 asia-southeast2 australia-southeast1 europe-north1 europe-west1 europe-west3 europe-west4 northamerica-northeast1 us-east4 southamerica-east1	1 000 Emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans chacune des régions répertoriées à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud
Nombre total d'emplacements pour les régions BigQuery Omni	100 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans les régions BigQuery Omni à l'aide de la console Google Cloud. Consulter les quotas dans la console Google Cloud
Nombre total d'emplacements pour toutes les autres régions	500 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans d'autres régions à l'aide de la console Google Cloud. Afficher les quotas dans la console Google Cloud

Les limites suivantes s'appliquent aux réservations :

Limite	Valeur	Remarques
Nombre de projets d'administration pour les réservations d'emplacements	5 projets par organisation	Nombre maximal de projets dans une organisation pouvant contenir une réservation ou un engagement actif pour des emplacements correspondant à une localisation ou une région donnée.
Nombre maximal de réservations d'édition standard	10 réservations par projet	Nombre maximal de réservations d'édition standard par projet d'administration au sein d'une organisation pour un emplacement/une région donnés.
Nombre maximal de réservations de l'édition Enterprise ou Enterprise Plus	200 réservations par projet	Nombre maximal de réservations de l'édition Enterprise ou Enterprise Plus par projet d'administration au sein d'une organisation pour un emplacement/une région donnés.

Ensembles de données

Les limites suivantes s'appliquent aux ensembles de données BigQuery.

Limite	Par défaut	Remarques
Nombre maximal d'ensembles de données	Illimité	Le nombre d'ensembles de données qu'un projet peut avoir est illimité.
Nombre de tables par ensemble de données	Illimité	Lorsque vous utilisez un appel d'API, les performances d'énumération sont ralenties à mesure que vous approchez 50 000 tables dans un ensemble de données. La console Google Cloud peut afficher jusqu'à 50 000 tables pour chaque ensemble de données.
Nombre de ressources autorisées dans la liste de contrôle d'accès d'un ensemble de données	2500 ressources	La liste de contrôle d'accès d'un ensemble de données peut contenir jusqu'à 2500 ressources autorisées au total, ce qui inclut les Vues autorisées, les Ensembles de données autorisés et les Fonctions autorisées. Si vous dépassez cette limite en raison d'un grand nombre de vues autorisées, envisagez de les regrouper dans des ensembles de données autorisés.
Nombre d'opérations de mise à jour d'un ensemble de données par ensemble de données toutes les 10 secondes	5 opérations	Votre projet peut effectuer jusqu'à cinq opérations de mise à jour des ensembles de données toutes les 10 secondes. La limite de mise à jour de l'ensemble de données inclut toutes les opérations de mise à jour des métadonnées effectuées par les éléments suivants : Console Google Cloud Outil de ligne de commande bq Bibliothèques clientes BigQuery Les méthodes d'API suivantes : datasets.insert datasets.patch datasets.update datasets.delete datasets.undelete Les instructions DDL suivantes : CREATE SCHEMA ALTER SCHEMA DROP SCHEMA UNDROP SCHEMA
Longueur maximale de la description des ensembles de données	16 384 caractères	Lorsque vous ajoutez une description à un ensemble de données, le texte ne doit pas comporter plus de 16 384 caractères.

Tables

Toutes les tables

Les limites suivantes s'appliquent à toutes les tables BigQuery.

Remarque : Les quotas et les limites sont associés aux noms des tables. Par conséquent, lorsque vous tronquez la table ou lorsque vous supprimez puis recréez la table, le quota/limite n'est pas réinitialisé, car le nom de la table n'a pas changé.

Limite	Par défaut	Remarques
Longueur maximale d'un nom de colonne	300 caractères.	Le nom de la colonne ne peut pas comporter plus de 300 caractères.
Longueur maximale d'une description de colonne	1 024 caractères	Lorsque vous ajoutez une description à une colonne, le texte ne doit pas comporter plus de 1 024 caractères.
Profondeur maximale des enregistrements imbriqués	15 Niveaux	Les colonnes de type RECORD peuvent contenir des types RECORD imbriqués, également appelés enregistrements enfants. La limite de profondeur des données imbriquées est de 15 niveaux. Cette limite est indépendante du fait que les enregistrements soient scalaires ou basés sur des tableaux (répétitions).

Tables standards

Les limites suivantes s'appliquent aux tables intégrées (standards) de BigQuery :

Limite	Par défaut	Remarques
Modifications de table par jour	1 500 modifications	Votre projet peut apporter jusqu'à 1 500 modifications par table et par jour, qu'il s'agisse d'ajout ou de mise à jour des données, ou de troncation de table. Cette limite ne peut pas être modifiée et inclut le total cumulé de tous les éléments suivants : jobs de chargement,jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination. Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de table par jour. Les données en flux continu ne sont pas comptabilisées dans le nombre de modifications de table par jour.
Taux maximal d'opérations de mise à jour des métadonnées de table par table	5 opérations pour 10 secondes	Votre projet peut effectuer jusqu'à cinq opérations de mise à jour des métadonnées de table pour 10 secondes par table. Cette limite s'applique à toutes les opérations de mise à jour des métadonnées de table, effectuées par les éléments suivants : Console Google Cloud Outil de ligne de commande bq Bibliothèques clientes BigQuery Les méthodes d'API suivantes : tables.insert tables.patch tables.update Instructions LDD sur les tables Cette limite inclut le total combiné de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table. Notez que même si les instructions LMD sont comptabilisées dans cette limite, elles n'y sont pas soumises si elle est atteinte. Les opérations LMD sont soumises à des limites de débit dédiées. Si vous dépassez cette limite, vous recevez un message d'erreur du type Exceeded rate limits: too many table update operations for this table. Cette erreur est temporaire. vous pouvez réessayer avec un intervalle exponentiel entre les tentatives. Pour identifier les opérations comptabilisées dans cette limite, vous pouvez inspecter vos journaux. Consultez la page Résoudre les erreurs de quota pour obtenir des conseils sur le diagnostic et la résolution de cette erreur.
Nombre maximal de colonnes par table	10 000 colonnes	Chaque table, résultat de requête ou définition de vue peut comporter jusqu'à 10 000 colonnes.

Tables externes

Les limites suivantes s'appliquent aux tables BigQuery contenant des données stockées sur Cloud Storage aux formats Avro, CSV, JSON, ORC et Parquet.

Limite	Par défaut	Remarques
Nombre maximal d'URI sources par table externe	10 000 URI	Chaque table externe peut comporter jusqu'à 10 000 URI sources.
Nombre maximal de fichiers par table externe	10 000 000 fichiers	Une table externe peut contenir jusqu'à 10 millions de fichiers, y compris tous les fichiers correspondant à tous les URI génériques.
Taille maximale des données stockées sur Cloud Storage par table externe	600 To	Une table externe peut contenir jusqu'à 600 téraoctets pour tous les fichiers d'entrée. Cette limite s'applique aux tailles de fichiers tels qu'ils sont stockés sur Cloud Storage. cette taille n'est pas la même que celle utilisée dans la formule de tarifs de la requête. Pour les tables partitionnées externes, la limite est appliquée après l'élimination des partitions.
Nombre maximal de fichiers dans le bucket Cloud Storage source	Environ 60 000 000 de fichiers	Une table externe peut référencer un bucket Cloud Storage contenant jusqu'à 60 000 000 de fichiers environ. Pour les tables partitionnées externes, cette limite est appliquée avant l'élimination des partitions.

Tables partitionnées

Les limites suivantes s'appliquent aux tables partitionnées BigQuery.

Remarque : Ces limites ne s'appliquent pas aux tables externes partitionnées par Hive.

Les limites de partition s'appliquent au total cumulé de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une partition de destination.

Une seule tâche peut affecter plusieurs partitions. Par exemple, les jobs de requête et les jobs de chargement peuvent écrire sur plusieurs partitions.

BigQuery utilise le nombre de partitions affectées par une tâche pour déterminer la limite utilisée par celle-ci. Les insertions en flux continu n'affectent pas cette limite.

Pour en savoir plus sur les stratégies permettant de respecter les limites des tables partitionnées, consultez la page Résoudre les erreurs de quota.

Limite	Par défaut	Remarques
Nombre de partitions par table partitionnée	4 000 Partitions	Chaque table partitionnée peut comporter jusqu'à 4 000 partitions. Si vous dépassez cette limite, pensez à utiliser le clustering en plus ou à la place du partitionnement.
Nombre maximal de partitions modifiées par tâche	4 000 Partitions	Chaque opération de tâche (requête ou chargement) peut affecter jusqu'à 4 000 partitions. BigQuery rejette toute tâche de requête ou de chargement qui tente de modifier plus de 4 000 partitions.
Nombre de modifications de partition par table partitionnée par date d'ingestion et par jour	5 000 Modifications.	Votre projet peut effectuer jusqu'à 5 000 modifications de partition par jour, qu'il s'agisse d'ajout ou de mise à jour des données, ou de troncation de table partitionnée par date d'ingestion. Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de partition par jour.
Nombre de modifications de partitions par table partitionnée par colonne et par jour	30 000 Modifications.	Votre projet peut générer jusqu'à 30 000 modifications de partition par jour pour une table partitionnée en colonnes. Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de partition par jour. Les données en flux continu ne sont pas comptabilisées dans le nombre de modifications de partition par jour.
Taux maximal d'opérations de mise à jour des métadonnées de table par table partitionnée	50 modifications toutes les 10 secondes	Votre projet peut exécuter jusqu'à 50 modifications par table partitionnée toutes les 10 secondes. Cette limite s'applique à toutes les opérations de mise à jour des métadonnées de table partitionnée effectuées par les éléments suivants : Console Google Cloud Outil de ligne de commande bq Bibliothèques clientes BigQuery Les méthodes d'API suivantes : tables.insert tables.patch tables.update Instructions LDD sur les tables Cette limite inclut le total combiné de tous les jobs de chargement, jobs de copie et jobs de requête qui ajoutent ou écrasent une table de destination, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table. Si vous dépassez cette limite, vous recevez un message d'erreur du type Exceeded rate limits: too many partitioned table update operations for this table. Cette erreur est temporaire. vous pouvez réessayer avec un intervalle exponentiel entre les tentatives. Pour identifier les opérations comptabilisées dans cette limite, vous pouvez inspecter vos journaux.
Nombre de plages possibles pour le partitionnement de plage	10 000 Plages	Une table partitionnée par plages peut contenir jusqu'à 10 000 plages. Cette limite s'applique à la spécification de partition lorsque vous créez la table. Une fois la table créée, la limite s'applique également au nombre réel de partitions.

Clones de tables

Les limites suivantes s'appliquent aux clones de table BigQuery :

Limite	Par défaut	Remarques
Nombre maximal de clones et d'instantanés dans une chaîne	3 clones ou instantanés de table	Les clones et les instantanés sont limités à une profondeur de 3. Cela signifie qu'après avoir cloné ou créé un instantané d'une table de base, vous ne pourrez cloner ou créer un instantané à partir du résultat que deux fois de plus. Toute troisième tentative de clonage ou de création d'instantané à partir du résultat générera une erreur. Par exemple, vous pouvez créer le clone A de la table de base, créer l'instantané B du clone A, puis créer le clone C de l'instantané B. Pour créer des doubles supplémentaires du clone ou de l'instantané de troisième niveau, utilisez plutôt une opération de copie.
Nombre maximal de clones et d'instantanés pour une table de base	1 000 clones ou instantanés de table	Vous ne pouvez pas avoir plus de 1 000 clones et instantanés (total combiné) d'une table de base donnée. Par exemple, si vous disposez de 600 instantanés et 400 clones, la limite est atteinte.

Instantanés de table

Les limites suivantes s'appliquent aux instantanés de table BigQuery :

Limite	Par défaut	Remarques
Nombre maximal de tâches simultanées pour les instantanés de table	100 Tâches	Votre projet peut exécuter jusqu'à 100 tâches d'instantané de table simultanées.
Nombre maximal de tâches d'instantané de table par jour	50 000 Tâches	Votre projet peut exécuter jusqu'à 50 000 tâches d'instantané de table par jour.
Nombre maximal de jobs d'instantané de table par table et par jour	50 jobs	Votre projet peut exécuter jusqu'à 50 jobs d'instantané de table par table et par jour.
Nombre maximal de mises à jour de métadonnées par instantané de table et par intervalle de 10 secondes	5 mises à jour	Votre projet peut mettre à jour les métadonnées d'un instantané de table jusqu'à cinq fois toutes les 10 secondes.
Nombre maximal de clones et d'instantanés dans une chaîne	3 clones ou instantanés de table	Les clones et les instantanés sont limités à une profondeur de 3. Cela signifie qu'après avoir cloné ou créé un instantané d'une table de base, vous ne pourrez cloner ou créer un instantané à partir du résultat que deux fois de plus. Toute troisième tentative de clonage ou de création d'instantané à partir du résultat générera une erreur. Par exemple, vous pouvez créer le clone A de la table de base, créer l'instantané B du clone A, puis créer le clone C de l'instantané B. Pour créer des doubles supplémentaires du clone ou de l'instantané de troisième niveau, utilisez plutôt une opération de copie.
Nombre maximal de clones et d'instantanés pour une table de base	1 000 clones ou instantanés de table	Vous ne pouvez pas avoir plus de 1 000 clones et instantanés (total combiné) d'une table de base donnée. Par exemple, si vous disposez de 600 instantanés et 400 clones, la limite est atteinte.

Vues

Les quotas et limites suivants s'appliquent aux vues et aux vues matérialisées.

Vues logiques

Les limites suivantes s'appliquent aux vues BigQuery standards :

Limite	Par défaut	Remarques
Nombre maximal de niveaux de vues imbriquées	16 Niveaux	BigQuery accepte jusqu'à 16 niveaux de vues imbriquées. Il est possible de créer des vues jusqu'à cette limite, mais les requêtes sont limitées à 15 niveaux. Si la limite est dépassée, BigQuery renvoie une erreur INVALID_INPUT.
Longueur maximale d'une requête GoogleSQL utilisée pour définir une vue	256 000 caractères	Une requête GoogleSQL unique qui définit qu'une vue peut comporter jusqu'à 256 000 caractères. Cette limite s'applique à une seule requête et n'inclut pas la longueur des vues référencées dans la requête.
Nombre maximal de vues autorisées par ensemble de données		Consultez la page Ensembles de données.

Vues matérialisées

Les limites suivantes s'appliquent aux vues matérialisées BigQuery.

Limite	Par défaut	Remarques
Références de table de base (même ensemble de données)	20 vues matérialisées	Chaque table de base peut être référencée par un maximum de 20 vues matérialisées à partir du même ensemble de données.
Références de table de base (même projet)	100 vues matérialisées	Chaque table de base peut être référencée par un maximum de 100 vues matérialisées du même projet.
Références aux tables de base (ensemble de l'organisation)	500 vues matérialisées	Chaque table de base peut être référencée par un maximum de 500 vues matérialisées de l'ensemble de l'organisation.
Nombre maximal de vues autorisées par ensemble de données		Consultez la page Ensembles de données.

Rechercher dans les index

Les limites suivantes s'appliquent aux index de recherche BigQuery :

Limite	Par défaut	Notes
Nombre d'instructions LDD CREATE INDEX par projet, par région et par jour	500 opérations	Votre projet peut émettre jusqu'à 500 opérations LDD CREATE INDEX chaque jour dans une région.
Nombre d'instructions LDD d'index de recherche par table et par jour	20 opérations	Votre projet peut émettre jusqu'à 20 opérations LDD CREATE INDEX ou DROP INDEX par table et par jour.
Taille maximale autorisée des données de table par organisation, pour la création d'index de recherche ne s'exécutant pas dans une réservation	100 To dans les emplacements multirégionaux, 20 To dans toutes les autres régions	Vous pouvez créer un index de recherche pour une table si la taille globale des tables avec des index dans votre organisation est inférieure à la limite de votre région : 100 To pour les emplacements multirégionaux US et EU, et 20 To pour toutes les autres régions. Cette limite ne s'applique pas si vos jobs de gestion d'index s'exécutent dans votre propre réservation.

Index vectoriels

Les limites suivantes s'appliquent aux index vectoriels BigQuery :

Limite	Par défaut	Notes
Nombre minimal de lignes de la table de base	5 000 lignes	Pour créer un index vectoriel, une table doit contenir au moins 5 000 lignes.
Nombre maximal de lignes pour la table de base	1 000 000 000 lignes	Une table peut contenir au maximum 1 000 000 000 lignes pour créer un index vectoriel.
Taille maximale du tableau dans la colonne indexée	1 600 éléments	La colonne à indexer peut contenir au maximum 1 600 éléments.
Taille minimale de la table pour la population des index vectoriels	10 Mo	Si vous créez un index vectoriel sur une table de moins de 10 Mo, l'index n'est pas renseigné. De même, si vous supprimez les données d'une table indexée vectorielle de telle sorte que la taille de la table est inférieure à 10 Mo, l'index vectoriel est temporairement désactivé. Cela se produit que vous utilisiez ou non votre propre réservation pour vos tâches de gestion d'index. Lorsque la taille d'une table indexée vectorielle dépasse à nouveau 10 Mo, son index est automatiquement renseigné.
Nombre d'instructions LDD CREATE VECTOR INDEX par projet, par région et par jour	500 opérations	Pour chaque projet, vous pouvez émettre jusqu'à 500 opérations CREATE VECTOR INDEX par jour pour chaque région.
Nombre d'instructions LDD d'index vectoriel par table et par jour	10 opérations	Vous pouvez émettre jusqu'à 10 opérations CREATE VECTOR INDEX ou DROP VECTOR INDEX par table et par jour.
Taille maximale autorisée des données de table par organisation, pour la création d'index vectoriel ne s'exécutant pas dans une réservation	20 To	Vous pouvez créer un index vectoriel pour une table si la taille totale des tables avec index de votre organisation est inférieure à 20 To. Cette limite ne s'applique pas si vos jobs de gestion d'index s'exécutent dans votre propre réservation.

Routines

Les quotas et limites suivants s'appliquent aux routines.

Fonctions définies par l'utilisateur

Les limites suivantes s'appliquent aux fonctions définies par l'utilisateur (UDF), qu'elles soient temporaires ou persistantes, dans les requêtes GoogleSQL.

Remarque : Les fonctions définies par l'utilisateur et les tables auxquelles elles font référence sont comptabilisées dans la limite du nombre de ressources référencées dans une requête

.

Limite	Par défaut	Remarques
Sortie maximale par ligne	5 Mo	La quantité maximale de données que votre fonction JavaScript définie par l'utilisateur peut générer lors du traitement d'une seule ligne est d'environ 5 Mo.
Nombre maximal de requêtes en ancien SQL simultanées avec fonctions définies par l'utilisateur (JavaScript)	6 requêtes	Votre projet peut comporter jusqu'à six requêtes en ancien SQL simultanées contenant des fonctions définies par l'utilisateur en JavaScript. Cette limite inclut les requêtes interactives et les requêtes par lot. Cette limite ne s'applique pas aux requêtes GoogleSQL.
Nombre maximal de ressources de fonction JavaScript définies par l'utilisateur par requête	50 Ressources	Une tâche de requête peut contenir jusqu'à 50 ressources de fonction JavaScript définie par l'utilisateur, telles que des blobs de code intégrés ou des fichiers externes.
Taille maximale du blob de code intégré	32 Ko	La taille d'un blob de code intégré dans une fonction définie par l'utilisateur peut atteindre 32 Ko.
Taille maximale de chaque ressource de code externe	1 Mo	La taille maximale de chaque ressource de code JavaScript est de 1 Mo.

Les limites suivantes s'appliquent aux fonctions définies par l'utilisateur persistantes :

Limite	Par défaut	Remarques
Longueur maximale d'un nom de fonction définie par l'utilisateur	256 caractères	Un nom de fonction définie par l'utilisateur peut comporter jusqu'à 256 caractères.
Nombre maximal d'arguments	256 Arguments	Une fonction définie par l'utilisateur peut comporter jusqu'à 256 arguments.
Longueur maximale d'un nom d'argument	128 caractères	Un nom d'argument de fonction définie par l'utilisateur peut comporter jusqu'à 128 caractères.
Profondeur maximale d'une chaîne de référence d'une fonction définie par l'utilisateur	16 Références	Une chaîne de référence d'une fonction définie par l'utilisateur peut comprendre jusqu'à 16 références.
Profondeur maximale d'une sortie ou d'un argument de type STRUCT	15 Niveaux	Une sortie ou un argument UDF de type STRUCT UDF peut comporter jusqu'à 15 niveaux de profondeur.
Nombre maximal de champs dans des arguments de type STRUCT ou en sortie par UDF	1 024 Champs	Une fonction définie par l'utilisateur peut contenir jusqu'à 1 024 champs dans les arguments de type STRUCT et les résultats.
Nombre maximal de bibliothèques JavaScript dans une instruction CREATE FUNCTION	50 Bibliothèques	Une instruction CREATE FUNCTION peut comporter jusqu'à 50 bibliothèques JavaScript.
Longueur maximale des chemins d'accès aux bibliothèques JavaScript incluses	5 000 caractères	Le chemin d'accès à une bibliothèque JavaScript incluse dans une fonction définie par l'utilisateur peut comporter jusqu'à 5 000 caractères.
Fréquence maximale de mise à jour par fonction définie par l'utilisateur par intervalle de 10 secondes	5 mises à jour	Votre projet peut mettre à jour une fonction définie par l'utilisateur jusqu'à cinq fois toutes les 10 secondes.
Nombre maximal d'UDF autorisées par ensemble de données		Consultez la page Ensembles de données.

Fonctions à distance

Les limites suivantes s'appliquent aux fonctions distantes dans BigQuery.

Limite	Par défaut	Remarques
Nombre maximal de requêtes simultanées contenant des fonctions distantes	10 requêtes	Vous pouvez exécuter jusqu'à dix requêtes simultanées avec des fonctions distantes par projet.
Taille maximale d'entrée	5 Mo	La taille totale maximale de tous les arguments d'entrée d'une seule ligne est de 5 Mo.
Taille limite des réponses HTTP (Cloud Functions 1re génération)	10 Mo	Le corps de la réponse HTTP de votre fonction Cloud 1re génération peut atteindre 10 Mo. Le dépassement de cette valeur entraîne des échecs de requêtes.
Limite de taille de réponse HTTP (Cloud Functions 2e génération ou Cloud Run)	15 Mo	Le corps de la réponse HTTP de la fonction Cloud 2e génération ou de Cloud Run ne dépasse pas 15 Mo. Le dépassement de cette valeur entraîne des échecs de requêtes.
Durée maximale de l'appel HTTP (Cloud Functions 1re génération)	9 minutes	Vous pouvez définir votre propre limite de temps pour votre fonction Cloud Functions de 1re génération pour un appel HTTP individuel, mais la limite de temps maximale est de 9 minutes. Le dépassement du délai défini pour votre fonction Cloud Functions de 1re génération peut entraîner des échecs d'appels HTTP et des requêtes après un nombre limité de tentatives.
Durée maximale de l'appel HTTP (Cloud Functions 2e génération ou Cloud Run)	20 minutes	La limite de temps pour un appel HTTP individuel à votre fonction Cloud 2e génération ou Cloud Run. Le dépassement de cette valeur peut entraîner des échecs d'appels HTTP et des échecs de requête après un nombre limité de tentatives.

Fonctions de table

Les limites suivantes s'appliquent aux fonctions de table BigQuery :

Limite	Par défaut	Remarques
Longueur maximale d'un nom de fonction de table	256 caractères	Le nom d'une fonction de table peut comporter jusqu'à 256 caractères.
Longueur maximale d'un nom d'argument	128 caractères	Le nom d'un argument de fonction de table peut comporter jusqu'à 128 caractères.
Nombre maximal d'arguments	256 Arguments	Une fonction de table peut contenir jusqu'à 256 arguments.
Profondeur maximale d'une chaîne de référence de fonction de table	16 Références	Une chaîne de référence de fonction de table peut comporter jusqu'à 16 références.
Profondeur maximale d'un argument ou d'une sortie de type STRUCT	15 Niveaux	Un argument STRUCT pour une fonction de table peut comporter jusqu'à 15 niveaux de profondeur. De même, un enregistrement STRUCT dans le résultat d'une fonction de table peut contenir jusqu'à 15 niveaux de profondeur.
Nombre maximal de champs dans un argument ou une table de retour de type STRUCT par fonction de table	1 024 Champs	Un argument STRUCT pour une fonction de table peut contenir jusqu'à 1 024 champs. De même, un enregistrement STRUCT dans le résultat d'une fonction de table peut contenir jusqu'à 1 024 champs.
Nombre maximal de colonnes dans le tableau des retours	1 024 colonnes	Une table affichée par une fonction de table peut contenir jusqu'à 1 024 colonnes.
Longueur maximale des noms des colonnes des tables de retour	128 caractères	Les noms de colonne des tables renvoyées peuvent comporter jusqu'à 128 caractères.
Nombre maximal de mises à jour par fonction de table pour 10 secondes	5 mises à jour	Votre projet peut mettre à jour une fonction de table jusqu'à cinq fois toutes les 10 secondes.

Procédures stockées pour Apache Spark

Les limites suivantes s'appliquent aux procédures stockées BigQuery pour Apache Spark :

Limite	Default	Remarques
Nombre maximal de requêtes de procédures stockées simultanées	50	Vous pouvez exécuter jusqu'à 50 requêtes de procédures stockées simultanées pour chaque projet.
Nombre maximal de processeurs en cours d'utilisation	12 000	Vous pouvez utiliser jusqu'à 12 000 processeurs simultanés pour chaque projet. Les requêtes qui ont déjà été traitées ne sont pas prises en compte. Vous pouvez utiliser jusqu'à 2 400 processeurs pour chaque emplacement et chaque projet, sauf dans les emplacements suivants : asia-south2 australia-southeast2 europe-central2 europe-west8 northamerica-northeast2 southamerica-west1 Vous pouvez utiliser jusqu'à 500 processeurs dans chaque emplacement pour chaque projet. Si vous exécutez des requêtes simultanées dans un emplacement multirégional et dans un emplacement régional unique situé dans la même zone géographique, vos requêtes peuvent consommer le même quota de processeurs simultanés.
Taille maximale totale des disques persistants standard en cours d'utilisation	204,8 To	Vous pouvez utiliser jusqu'à 204,8 To de disques persistants standards pour chaque emplacement et chaque projet. Les requêtes déjà traitées ne sont pas prises en compte. Si vous exécutez des requêtes simultanées dans un emplacement multirégional et dans un emplacement régional unique situé dans la même zone géographique, vos requêtes peuvent consommer le même quota de disques persistants standard.

Notebooks

Tous les quotas et limites de Dataform, ainsi que les quotas et limites de Colab Enterprise, s'appliquent aux notebooks dans BigQuery. Les limites suivantes s'appliquent également :

Limite	Default	Notes
Taille maximale du notebook	20 Mo	La taille d'un notebook correspond au total de son contenu, de ses métadonnées et de la surcharge d'encodage. Pour afficher la taille du contenu du notebook, développez l'en-tête du notebook, cliquez sur Afficher, puis sur Informations sur le notebook.
Nombre maximal de requêtes par seconde envoyées à Dataform	100	Les notebooks sont créés et gérés via Dataform. Toute action qui crée ou modifie un notebook est comptabilisée dans ce quota. Ce quota est partagé avec les requêtes enregistrées. Par exemple, si vous apportez 50 modifications aux notebooks et 50 modifications aux requêtes enregistrées sous une seconde, vous atteignez le quota.

Saved queries

Tous les quotas et limites de Dataform s'appliquent aux requêtes enregistrées. Les limites suivantes s'appliquent également :

Limite	Default	Notes
Taille maximale des requêtes enregistrées	10 Mo
Nombre maximal de requêtes par seconde envoyées à Dataform	100	Les requêtes enregistrées sont créées et gérées via Dataform. Toute action qui crée ou modifie une requête enregistrée est comptabilisée dans ce quota. Ce quota est partagé avec les notebooks. Par exemple, si vous apportez 50 modifications aux notebooks et 50 modifications aux requêtes enregistrées sous une seconde, vous atteignez le quota.

Langage de manipulation de données

Les limites suivantes s'appliquent aux instructions BigQuery langage de manipulation de données (LMD) :

Limite	Par défaut	Remarques
Instructions LMD par jour	Illimité	Votre projet peut exécuter un nombre illimité d'instructions LMD par jour. Les instructions LMD ne sont pas comptabilisées dans le nombre de modifications de table par jour (ou dans le nombre de modifications de table partitionnée par jour pour les tables partitionnées). Les instructions LMD sont soumises aux limites suivantes.
Instructions LMD en mutation simultanées par table	2 instructions	BigQuery exécute jusqu'à deux instructions LMD en mutation simultanées (UPDATE, DELETE et MERGE) par table. Les autres instructions LMD en mutation d'une table sont placées en file d'attente.
Instructions LMD en mutation en file d'attente par table	20 instructions	Dans la file d'attente, une table peut contenir jusqu'à 20 instructions LMD en mutation en attente d'exécution. Si vous envoyez des instructions LMD en mutation supplémentaires pour la table, ces instructions échouent.
Temps maximal dans la file d'attente pour l'instruction LMD	6 heures	Une instruction LMD interactive prioritaire peut être placée en file d'attente pendant six heures. Si l'instruction n'est pas exécutée au bout de six heures, elle échoue.
Taux maximal d'instructions LMD pour chaque table	25 instructions toutes les 10 secondes	Votre projet peut exécuter jusqu'à 25 instructions LMD toutes les 10 secondes pour chaque table. Les instructions LMD INSERT et les instructions LMD de mutation contribuent à cette limite.

Pour en savoir plus sur les instructions LMD en mutation, consultez les sections INSERT LMD simultané et UPDATE, DELETE, MERGE LMD simultané.

Requêtes à plusieurs instructions

Les limites suivantes s'appliquent aux requêtes à plusieurs instructions dans BigQuery.

Limite	Par défaut	Remarques
Nombre maximal de requêtes à plusieurs instructions simultanées	1 000 requêtes à plusieurs instructions	Votre projet peut exécuter jusqu'à 1 000 requêtes à plusieurs instructions simultanées.
Limite de temps cumulé	24 heures	La limite de temps cumulé pour une requête à plusieurs instructions est de 24 heures.
Durée maximale de l'instruction	6 heures	Le délai d'une instruction dans une requête à plusieurs instructions est de 6 heures.

CTE récursifs dans les requêtes

Les limites suivantes s'appliquent aux expressions de table courantes (CTE) récursives dans BigQuery.

Limite	Par défaut	Remarques
Limite d'itération	500 iterations	Le CTE récursif peut exécuter ce nombre d'itérations. Si cette limite est dépassée, une erreur est générée. Pour contourner les limites d'itération, consultez la page Résoudre les erreurs de limite d'itération.

Sécurité au niveau des lignes

Les limites suivantes s'appliquent aux règles d'accès au niveau de la ligne de BigQuery :

Limite	Default	Notes
Nombre maximal de règles d'accès aux lignes par table.	400 règles	Une table peut contenir jusqu'à 400 règles d'accès aux lignes.
Nombre maximal de règles d'accès aux lignes par requête.	6000 règles	Une requête peut accéder jusqu'à 6000 règles d'accès aux lignes.
Nombre maximal d'instructions LDD CREATE / DROP par règle pour 10 secondes	Cinq instructions	Votre projet peut créer jusqu'à cinq instructions CREATE ou DROP par ressource de règle d'accès aux lignes toutes les 10 secondes.
Instructions DROP ALL ROW ACCESS POLICIES par table et par période de 10 secondes	Cinq instructions	Votre projet peut générer jusqu'à cinq instructions DROP ALL ROW ACCESS POLICIES par table toutes les 10 secondes.

Règles concernant les données

Les limites suivantes s'appliquent au masquage des données dynamiques au niveau des colonnes :

Limite	Par défaut	Remarques
Nombre maximal de stratégies de données par tag avec stratégie.	8 règles par tag avec stratégie	Jusqu'à huit stratégies de données par tag avec stratégie. L'une de ces règles peut être utilisée pour les contrôles des accès au niveau des colonnes. Les expressions de masquage en double ne sont pas acceptées.

BigQuery ML

Les limites suivantes s'appliquent à BigQuery ML.

Tâches de requête

Tous les quotas et limites des jobs de requête s'appliquent aux jobs de requête GoogleSQL qui utilisent des instructions et des fonctions BigQuery ML.

Instructions CREATE MODEL

Les limites suivantes s'appliquent aux jobs CREATE MODEL :

Limite	Par défaut	Remarques
Requêtes avec instruction CREATE MODEL par période de 48 heures pour chaque projet	20 000 requête avec instruction	Certains modèles sont entraînés à l'aide de services Vertex IA, qui possèdent leur propre gestion des ressources et des quotas.
Limite de durée d'exécution	24 ou 72 heures	Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des job de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 72 heures.

Fonctions des services Vertex AI et Cloud AI

Les limites suivantes s'appliquent aux fonctions qui utilisent des modèles de langage volumineux (LLM) de Vertex AI et des services d'IA dans le cloud :

Fonction	Requêtes par minute	Lignes par job	Nombre de jobs exécutés simultanément
ML.ANNOTATE_IMAGE	900	307 800	5
ML.TRANSLATE	3 000	1 026 000	5
ML.UNDERSTAND_TEXT	300	102 600	5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur un modèle gemini-1.5-pro	60	21 600	5
ML.GENERATE_TEXT lors de l'utilisation d'un modèle distant sur le modèle gemini-1.0-pro-vision	60	20 000	1
ML.GENERATE_TEXT lorsque vous utilisez un modèle distant sur un modèle gemini-1.0-pro, text-bison, text-bison-32 ou text-unicorn	60	30 000	5
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI multimodalembedding	120	25 000	1
ML.GENERATE_EMBEDDING en cas d'utilisation avec des modèles distants via des modèles Vertex AI textembedding-gecko et textembedding-gecko-multilingual	1,500	1 000 000	1
ML.PROCESS_DOCUMENT	600	205 200	5
ML.TRANSCRIBE	60	1 000	5

Pour en savoir plus sur les quotas applicables aux LLM Vertex AI et aux API des services Cloud AI, consultez les documents suivants :

• Limites de quota de l'IA générative sur Vertex AI
• Quotas et limites de l'API Cloud Translation
• Quotas et limites de l'API Vision
• Quotas et limites de l'API Natural Language
• Quotas et limites de Document AI
• Quotas et limites de Speech-to-Text

Pour demander une augmentation de quota pour des fonctions BigQuery ML, ajustez d'abord le quota pour le LLM Vertex AI ou le service Cloud AI associé, puis envoyez un e-mail à [e-mail] en incluant les informations sur le quota ajusté pour le LLM ou le service Cloud AI. Pour plus d'informations sur la demande d'augmentation de quota pour ces services, consultez la page Demander une augmentation de quota.

Définitions des quotas

La liste suivante décrit les quotas qui s'appliquent aux fonctions des services Vertex AI et Cloud AI :

• Les fonctions qui appellent un modèle de fondation Vertex AI utilisent un quota Vertex AI, à savoir le nombre de requêtes par minute (RPM). Dans ce contexte, les requêtes sont des appels de requête lancés par la fonction, à destination de l'API du modèle Vertex AI. Le quota de RPM s'applique à un modèle de base et à l'ensemble des versions, identifiants et versions réglées de ce modèle. Pour en savoir plus sur les quotas relatifs aux modèles de fondation Vertex AI, consultez la page Quotas par région et par modèle.
• Les fonctions qui appellent un service Cloud AI utilisent les quotas de requêtes du service cible. Consultez la documentation de référence sur les quotas du service Cloud AI concerné pour plus de détails.

• BigQuery ML utilise trois quotas :

  • Requêtes par minute. Ce quota correspond au nombre maximal d'appels de requête par minute que les fonctions peuvent effectuer sur l'API du modèle Vertex AI ou du service Cloud AI. Cette limite s'applique à chaque projet.

    Pour les fonctions qui appellent un modèle de fondation Vertex AI, le nombre d'appels de requêtes par minute varie en fonction du point de terminaison, de la version et de la région du modèle Vertex AI. Ce quota est conceptuellement identique au quota de RPM utilisé par Vertex AI, mais sa valeur peut être inférieure à celle du quota de RPM pour un modèle correspondant.

  • Lignes par job. Ce quota correspond au nombre maximal de lignes autorisées pour chaque job de requête.

  • Nombre de jobs exécutés simultanément. Ce quota correspond au nombre maximal de requêtes SQL, par projet, pouvant être exécutées simultanément pour la fonction concernée.

Les exemples suivants montrent comment interpréter les limites de quota dans des situations types :

• J'ai un quota de 1 000 RPM dans Vertex AI. Une requête portant sur 100 000 lignes devrait donc prendre environ 100 minutes. Alors pourquoi le job prend-il plus de temps ?

  Les environnements d'exécution d'un job peuvent varier, même avec des données d'entrée identiques. Dans Vertex AI, les appels de procédure à distance (RPC) ont des priorités différentes afin d'éviter le drainage des quotas. Lorsque le quota est insuffisant, les RPC ayant des priorités inférieures sont mis en attente et peuvent finir par échouer, si leur traitement prend trop de temps.

• Comment dois-je interpréter le quota de lignes par job ?

  Dans BigQuery, une requête peut s'exécuter pendant un maximum de six heures. Le nombre maximal de lignes acceptées varie selon cette chronologie et votre quota de RPM Vertex AI, afin de garantir que BigQuery peut achever le traitement de la requête en six heures. Étant donné qu'une requête ne peut généralement pas utiliser l'intégralité du quota, ce nombre est inférieur à votre quota de RPM multiplié par 360.

• Que se passe-t-il si j'exécute un job d'inférence par lot sur une table qui contient plus de lignes que le quota de lignes par job (par exemple, 10 millions de lignes) ?

  BigQuery ne traite que le nombre de lignes spécifié par le quota de lignes par job. Vous êtes facturé uniquement pour les appels d'API réussis pour ce nombre de lignes, et non pour l'ensemble des 10 millions de lignes de votre table. Pour les autres lignes, BigQuery répond à la requête avec une erreur A retryable error occurred: the maximum size quota per query has reached, qui est renvoyée dans la colonne status du résultat. Vous pouvez utiliser cet ensemble de scripts SQL ou ce package Dataform pour effectuer une itération des appels d'inférence jusqu'à ce que toutes les lignes soient traitées avec succès.

• J'ai beaucoup plus de lignes à traiter que ce qu'autorise le quota de lignes par job. Puis-je m'en sortir en répartissant les lignes sur plusieurs requêtes et en les exécutant simultanément ?

  Non, car ces requêtes consomment les mêmes quotas de requêtes BigQuery ML par minute et de RPM Vertex AI. Si vous définissez plusieurs requêtes qui restent toutes dans les limites du quota de lignes par job et du quota de nombre de jobs exécutés simultanément, le traitement cumulé va épuiser le quota de requêtes par minute.

BI Engine

Les limites suivantes s'appliquent à BigQuery BI Engine.

Limite	Par défaut	Remarques
Taille maximale de réservation par projet et par emplacement (interface SQL	250 Gio	S'applique lors de l'utilisation de BI Engine avec BigQuery. S'applique dans tous les cas, à l'exception de Looker Studio sans intégration native. Vous pouvez demander une augmentation de la capacité de réservation maximale pour vos projets. Les augmentations de réservation sont disponibles dans la plupart des régions et leur traitement peut prendre de trois jours à une semaine.
Taille maximale de réservation par projet et par emplacement (Looker Studio)	100 Go	S'applique lorsque vous utilisez BI Engine avec Looker Studio sans intégration native. Cette limite n'affecte pas la taille des tables que vous interrogez, car BI Engine ne charge en mémoire que les colonnes utilisées dans vos requêtes, et non l'intégralité de la table.
Taille maximale du modèle de données par table (Looker Studio)	10 GB	S'applique lorsque vous utilisez BI Engine avec Looker Studio sans intégration native. Si vous disposez d'une réservation de 100 Go par projet et par emplacement, BI Engine limite la réservation par table à 10 Go. Le reste de la réservation disponible est utilisé pour les autres tables du projet.
Nombre maximal de partitions par table (Looker Studio)	500 partitions	S'applique lorsque vous utilisez BI Engine avec Looker Studio sans intégration native. BI Engine pour Looker Studio accepte un maximum de 500 partitions par table.
Nombre maximal de lignes par requête (Looker Studio)	150 millions	S'applique lorsque vous utilisez BI Engine avec Looker Studio sans intégration native. BI Engine pour Looker Studio accepte jusqu'à 150 millions de lignes de données interrogées, selon la complexité de la requête.

Analytics Hub

Les limites suivantes s'appliquent à Analytics Hub :

Limite	Par défaut	Remarques
Nombre maximal d'échanges de données par projet	500 échanges	Vous pouvez créer jusqu'à 500 échanges de données dans un projet.
Nombre maximal de fiches par échange de données	1 000 fiches	Vous pouvez créer jusqu'à 1 000 fiches dans un échange de données.
Nombre maximal d'ensembles de données associés par ensemble de données partagé	1 000 ensembles de données associés	Tous les abonnés Analytics Hub combinés peuvent posséder un maximum de 1 000 ensembles de données associés par ensemble de données partagé.

Quotas et limites des API

Ces quotas et limites s'appliquent aux requêtes API BigQuery.

API BigQuery

Les quotas suivants s'appliquent aux requêtes API BigQuery (cœur) :

Quotas	Par défaut	Remarques
Requêtes par jour	Illimité	Votre projet peut effectuer un nombre illimité de requêtes API BigQuery par jour. Afficher le quota dans la console Google Cloud
Nombre maximal d'octets tabledata.list par minute	7,5 Go dans les emplacements multirégionaux ; 3,7 Go dans toutes les autres régions	Votre projet peut renvoyer jusqu'à 7,5 Go de données de ligne de table par minute via tabledata.list dans les emplacements multirégionaux us et eu, et 3,7 Go de données de ligne de table par minute dans toutes les autres régions. Ce quota s'applique au projet contenant la table en cours de lecture. D'autres API, y compris jobs.getQueryResults, et extrayant les résultats de jobs.query et jobs.insert peuvent également consommer ce quota. Afficher le quota dans la console Google Cloud L'API BigQuery Storage Read peut gérer un débit beaucoup plus élevé que tabledata.list. Si vous avez besoin d'un débit supérieur à celui autorisé sous ce quota, envisagez d'utiliser l'API BigQuery Storage Read.

Les limites suivants s'appliquent aux requêtes API BigQuery (cœur) :

Limite	Par défaut	Remarques
Nombre maximal de requêtes API par seconde, par utilisateur et par méthode	100 requêtes	Un utilisateur peut envoyer jusqu'à 100 requêtes API par seconde à une méthode d'API. Si un utilisateur envoie plus de 100 requêtes par seconde à une méthode, un ralentissement du débit peut survenir. Cette limite ne s'applique pas aux insertions en flux continu.
Nombre maximal de requêtes API simultanées par utilisateur	300 requêtes	Si un utilisateur effectue plus de 300 requêtes simultanées, cela peut entraîner une limitation. Cette limite ne s'applique pas aux insertions en flux continu.
Taille maximale de l'en-tête de requête	16 Kio	Une requête API BigQuery ne peut pas dépasser 16 Kio, en incluant l'URL de la requête et tous les en-têtes. Cette limite ne s'applique pas au corps de la requête, comme dans une requête POST.
Nombre maximal de requêtes jobs.get par seconde	1 000 requêtes	Votre projet peut effectuer jusqu'à 1 000 requêtes jobs.get par seconde.
Taille maximale des réponses jobs.query	20 Mo	Par défaut, il n'existe aucun nombre maximal pour les lignes de données renvoyées par jobs.query par page de résultats. Cependant, vous êtes tenu de respecter la limite maximale de 20 Mo pour la taille des réponses. Pour modifier le nombre de lignes à renvoyer, utilisez le paramètre maxResults.
Taille maximale des lignes jobs.getQueryResults	20 Mo	La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite est appliquée lors du transcodage.
Nombre maximal de requêtes projects.list par seconde	2 requêtes	Votre projet peut envoyer jusqu'à deux requêtes projects.list par seconde.
Nombre maximal de requêtes tabledata.list par seconde	1 000 requêtes	Votre projet peut effectuer jusqu'à 1 000 requêtes tabledata.list par seconde.
Nombre maximal de lignes par réponse tabledata.list	100 000 Lignes	Un appel tabledata.list peut renvoyer jusqu'à 100 000 lignes de table. Pour en savoir plus, consultez la section Parcourir des résultats à l'aide de l'API.
Taille maximale des lignes tabledata.list	100 Mo	La taille maximale des lignes est approximative, car la limite est basée sur la représentation interne des données de ligne. La limite est appliquée lors du transcodage.
Nombre maximal de requêtes tables.insert par seconde	Dix requêtes	Votre projet peut effectuer jusqu'à 10 requêtes tables.insert par seconde. La méthode tables.insert permet de créer une table vide dans un ensemble de données. Cette limite inclut les instructions SQL qui créent des tables, telles que CREATE TABLE, et les requêtes qui écrivent les résultats dans des tables de destination.

API BigQuery Connection

Les quotas suivants s'appliquent aux requêtes de l'API BigQuery Connection :

Quotas	Par défaut	Remarques
Requêtes de lecture par minute	1 000 requêtes par minute	Votre projet peut envoyer jusqu'à 1 000 requêtes par minute aux méthodes de l'API BigQuery Connection qui lisent des données de connexion. Afficher le quota dans la console Google Cloud
Requêtes d'écriture par minute	100 requêtes par minute	Votre projet peut envoyer jusqu'à 100 requêtes par minute aux méthodes de l'API BigQuery Connection qui créent ou mettent à jour des connexions. Afficher le quota dans la console Google Cloud
Connexions AWS par région	50 connexions par région	Votre projet peut contenir jusqu'à 50 connexions AWS par région AWS.
Connexions Azure par région	50 connexions par région	Votre projet peut comporter jusqu'à 50 connexions Azure par région Azure.

API BigQuery Migration

Les limites suivantes s'appliquent à l'API BigQuery Migration :

Limite	Par défaut	Remarques
Taille individuelle des fichiers pour la traduction SQL par lot	10 Mo	La taille maximale de chaque fichier source et de métadonnée est de 10 Mo. Cette limite ne s'applique pas au fichier ZIP de métadonnées généré par l'outil d'extraction sur ligne de commande dwh-migration-dumper.
Taille totale des fichiers sources pour la traduction SQL par lot	1 GB	La taille totale maximale de tous les fichiers d'entrée importés dans Cloud Storage est de 1 Go. Cela inclut tous les fichiers sources ainsi que tous les fichiers de métadonnées si vous décidez de les inclure.
Taille de chaîne d'entrée pour la traduction SQL interactive	1 Mo	La chaîne que vous saisissez pour la traduction SQL interactive ne doit pas dépasser 1 Mo.
Taille maximale du fichier de configuration pour la traduction SQL interactive	50 Mo	Les fichiers de métadonnées individuels (compressés) et les fichiers de configuration YAML dans Cloud Storage ne doivent pas dépasser 50 Mo. Si la taille d'un fichier dépasse 50 Mo, le traducteur interactif ignore ce fichier de configuration lors de la traduction et génère un message d'erreur. Une méthode permettant de réduire la taille des fichiers de métadonnées consiste à utiliser l'option —database ou –schema pour filtrer les bases de données lorsque vous générez les métadonnées.

Les quotas suivants s'appliquent à l'API BigQuery Migration. Les valeurs par défaut suivantes s'appliquent dans la plupart des cas. Les valeurs par défaut de votre projet peuvent être différentes :

Quotas	Par défaut	Remarques
Requêtes de liste d'EDWMigration Service par minute Requêtes de listes d'EDWMigration Service par minute et par utilisateur	12 000 requêtes 2 500 requêtes	Votre projet peut envoyer jusqu'à 12 000 requêtes de liste de l'API Migration par minute. Chaque utilisateur peut générer jusqu'à 2 500 requêtes de liste de l'API Migration par minute. Consulter les quotas dans la console Google Cloud
Demandes GET d'EDWMigration Service par minute Demandes GET d'EDWMigration Service par minute et par utilisateur	25 000 requêtes 2 500 requêtes	Votre projet peut générer jusqu'à 25 000 requêtes GET de l'API Migration par minute. Chaque utilisateur peut générer jusqu'à 2 500 requêtes GET de l'API Migration par minute. Consulter les quotas dans la console Google Cloud
Autres requêtes d'EDWMigration Service par minute Autres requêtes d'EDWMigration Service par minute et par utilisateur	25 requêtes 5 requêtes	Votre projet peut envoyer jusqu'à 25 autres requêtes de l'API Migration par minute. Chaque utilisateur peut envoyer jusqu'à 5 autres requêtes de l'API Migration par minute. Consulter les quotas dans la console Google Cloud
Requêtes de traduction SQL interactives par minute Requêtes de traduction SQL interactives par minute et par utilisateur	200 requêtes 50 requêtes	Votre projet peut envoyer jusqu'à 200 requêtes de service de traduction SQL par minute. Chaque utilisateur peut envoyer jusqu'à 50 autres requêtes de service de traduction SQL par minute. Consulter les quotas dans la console Google Cloud

API BigQuery Reservation

Les quotas suivants s'appliquent aux requêtes API BigQuery Reservation :

Quotas	Par défaut	Remarques
Requêtes par minute et par région	100 requêtes	Votre projet peut effectuer jusqu'à 100 appels vers les méthodes de l'API BigQuery Reservations par minute et par région. Afficher les quotas dans la console Google Cloud
Nombre d'appels SearchAllAssignments par minute et par région	100 requêtes	Votre projet peut envoyer jusqu'à 100 appels vers la méthode SearchAllAssignments par minute et par région. Afficher les quotas dans la console Google Cloud
Requêtes pour SearchAllAssignments par minute, par région et par utilisateur	Dix requêtes	Chaque utilisateur peut envoyer jusqu'à 10 appels à la méthode SearchAllAssignments par minute et par région. Afficher les quotas dans la console Google Cloud (Dans les résultats de recherche de la console Google Cloud, recherchez par utilisateur.)

API BigQuery DataPolicy

Les limites suivantes s'appliquent à l'API Data Policy (aperçu) :

Limite	Par défaut	Remarques
Nombre maximal d'appels dataPolicy.list.	400 requêtes par minute et par projet 600  requêtes par minute et par organisation
Nombre maximal d'appels dataPolicy.testIamPermissions.	400 requêtes par minute et par projet 600  requêtes par minute et par organisation
Nombre maximal de requêtes de lecture .	1 200 requêtes par minute et par projet 1 800 requêtes par minute et par organisation	Cela inclut les appels vers dataPolicy.get et dataPolicy.getIamPolicy.
Nombre maximal de requêtes d'écriture.	600 requêtes par minute et par projet 900 requêtes par minute et par organisation	Cela inclut les appels à : dataPolicy.create dataPolicy.delete dataPolicy.setIamPolicy dataPolicy.patch

API IAM

Les quotas suivants s'appliquent lorsque vous utilisez la fonctionnalité Gestion de l'authentification et des accès dans BigQuery pour récupérer et définir des stratégies IAM, et pour tester des autorisations IAM. Les instructions LCD (langage de contrôle de données) sont comptabilisées dans le quota SetIAMPolicy.

Remarque : Si vous rencontrez des contraintes de requête IAM, nous vous recommandons d'évaluer si votre projet peut utiliser l'Héritage d'autorisation IAM pour atténuer la contrainte.

Quotas	Par défaut	Notes
Requêtes IamPolicy par minute et par utilisateur	1 500 requêtes par minute et par utilisateur	Chaque utilisateur peut générer jusqu'à 1 500 requêtes IAM par minute et par projet. Afficher le quota dans la console Google Cloud
IamPolicy requêtes par minute et par projet	3 000 requêtes par minute et par projet	Votre projet peut générer jusqu'à 3 000 requêtes IAM par minute. Afficher le quota dans la console Google Cloud
Requêtes régionales SetIAMPolicy par minute et par projet	1 000 requêtes par minute et par projet	Votre projet régional peut envoyer jusqu'à 1 000 requêtes par minute. Afficher le quota dans la console Google Cloud
Requêtes SetIAMPolicy multirégionales par minute et par projet	2 000 requêtes par minute et par projet	Votre projet multirégional peut envoyer jusqu'à 2 000 requêtes par minute. Afficher le quota dans la console Google Cloud
Requêtes SetIAMPolicy pour les Régions Omni par minute et par projet	200 requêtes par minute et par projet	Votre projet Omni-region peut envoyer jusqu'à 200 requêtes par minute. Afficher le quota dans la console Google Cloud

API Storage Read

Les quotas suivants s'appliquent aux requêtes de l'API BigQuery Storage Read :

Quota	Par défaut	Remarques
Requêtes de lecture du plan de données par minute et par utilisateur	25 000 requêtes	Chaque utilisateur peut effectuer jusqu'à 25 000 appels ReadRows par minute et par projet. Afficher le quota dans la console Google Cloud
Requêtes de lecture du plan de contrôle par minute et par utilisateur	5 000 requêtes	Chaque utilisateur peut effectuer jusqu'à 5 000 appels d'opérations de métadonnées d'API Read Storage par minute et par projet. Les appels de métadonnées incluent les méthodes CreateReadSession et SplitReadStream. Afficher le quota dans la console Google Cloud

Les limites suivantes s'appliquent aux requêtes de l'API BigQuery Storage Read :

Limite	Par défaut	Remarques
Longueur maximale de ligne/filtre	1 Mo	Lorsque vous utilisez l'appel CreateReadSession de l'API Storage Read, vous êtes limité à 1 Mo au maximum pour chaque ligne ou filtre.
Taille maximale des données sérialisées	128 Mo	Lorsque vous utilisez l'appel ReadRows de l'API Storage Read, la représentation sérialisée des données dans un message ReadRowsResponse individuel ne peut pas dépasser 128 Mo.
Nombre maximal de connexions simultanées	2 000 dans les emplacements multirégionaux, 400 dans les régions	Vous pouvez ouvrir jusqu'à 2 000 connexions ReadRows simultanées par projet dans les emplacements multirégionaux us et eu, et 400 connexions ReadRows simultanées dans d'autres régions. Dans certains cas, vous pouvez être soumis à un nombre de connexions simultanées inférieur à cette limite.
Utilisation maximale de la mémoire par flux	1,5 Go	La mémoire maximale par flux est approximative, car la limite est basée sur la représentation interne des données de ligne. Les flux utilisant plus de 1,5 Go de mémoire pour une seule ligne peuvent échouer. Pour en savoir plus, consultez la section Résoudre les problèmes de dépassement de ressources.

API Storage Write

Les quotas suivants s'appliquent aux requêtes API Storage Write : Les quotas suivants peuvent être appliqués au niveau du dossier. Ces quotas sont ensuite agrégés et partagés entre tous les projets enfants. Pour activer cette configuration, contactez l'assistance Cloud Customer Care.

Remarque : Les projets ayant opté pour l'application de quotas au niveau du dossier ne peuvent vérifier que l'utilisation et la limite de quota au niveau du dossier sur la page des quotas de la console Google Cloud pour le dossier. L'utilisation et la limite du quota au niveau du projet ne seront pas affichées. Dans ce cas, les métriques de surveillance au niveau du projet constituent toujours une bonne source concernant l'utilisation au niveau du projet.

Si vous prévoyez de demander une augmentation de limite de quota, incluez le message d'erreur dans votre demande pour accélérer le traitement.

Quota	Par défaut	Remarques
Connexions simultanées	1 000 dans une région ; 10 000 dans un emplacement multirégional	Le quota de connexions simultanées est basé sur le projet client qui lance la requête de l'API Storage Write, et non sur le projet contenant la ressource d'ensemble de données BigQuery. Le projet à l'origine du projet est le projet associé à la clé API ou au compte de service. Votre projet peut fonctionner sur 1 000 connexions simultanées dans une région ou 10 000 connexions simultanées dans les emplacements multirégionaux US et EU. Lorsque vous utilisez le flux par défaut en Java ou Go, nous vous recommandons d'utiliser le multiplexage de l'API Storage Write pour écrire dans plusieurs tables de destination avec des connexions partagées afin de réduire le nombre de connexions globales nécessaires. Si vous utilisez le connecteur Beam avec une sémantique "au moins une fois", vous pouvez définir UseStorageApiConnectionPool sur TRUE pour activer le multiplexage. Afficher le quota dans la console Google Cloud Vous pouvez afficher les métriques de quota et de limites d'utilisation de vos projets dans Cloud Monitoring. Sélectionnez le nom de la limite de connexions simultanées en fonction de votre région. Les options sont ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU et ConcurrentWriteConnectionsPerProjectRegion pour us, eu et d'autres régions, respectivement. Nous vous recommandons vivement de configurer des alertes pour surveiller votre utilisation et vos limites de quotas. De plus, si vos modèles de trafic connaissent des pics et/ou une croissance naturelle régulière, vous pouvez envisager de surprovisionner votre quota de 25 à 50 % afin de gérer la demande inattendue.
Débit	Débit de 3 Go par seconde dans les emplacements multirégionaux ; 300 Mo par seconde dans les régions	Vous pouvez diffuser jusqu'à 3 Go/s dans les emplacements multirégionaux us et eu, et 300 Mbit/s dans les autres régions par projet. Afficher le quota dans la console Google Cloud Vous pouvez afficher les métriques de quota et de limites d'utilisation de vos projets dans Cloud Monitoring. Sélectionnez le nom de la limite de débit en fonction de votre région. Les options sont AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU et AppendBytesThroughputPerProjectRegion pour us, eu et d'autres régions, respectivement. Le quota de débit en écriture est mesuré en fonction du projet où réside l'ensemble de données cible, et non du projet client. Nous vous recommandons vivement de configurer des alertes pour surveiller votre utilisation et vos limites de quotas. De plus, si vos modèles de trafic connaissent des pics et/ou une croissance naturelle régulière, vous pouvez envisager de surprovisionner votre quota de 25 à 50 % afin de gérer la demande inattendue.
Requêtes CreateWriteStream	10 000 diffusions toutes les heures, par projet et par région.	Vous pouvez appeler CreateWriteStream jusqu'à 10 000 fois par heure, par projet et par région. Envisagez d'utiliser le flux par défaut si vous n'avez pas besoin d'une sémantique de type "exactement une fois". Ce quota est calculé par heure, mais la métrique affichée dans la console Google Cloud est par minute.
Octets de flux en attente	10 To dans les emplacements multirégionaux et 1 To dans les régions	Pour chaque commit que vous déclenchez, vous pouvez valider jusqu'à 10 To dans les emplacements multirégionaux us et eu, et 1 To dans les autres régions. Il n'y a pas de rapports de quota pour ce quota.

Les limites suivantes s'appliquent aux requêtes d'API Storage Write :

Limite	Par défaut	Remarques
Commits par lot	10 000 diffusions par table	Vous pouvez valider jusqu'à 10 000 diffusions dans chaque appel BatchCommitWriteStream.
Taille de requête AppendRows	10 Mo	La taille maximale de la requête est de 10 Mo.

Insertions en flux continu

Les quotas et limites suivants s'appliquent lorsque vous insérez des données en flux continu dans BigQuery à l'aide de l'ancienne API de streaming. Pour découvrir des stratégies qui vous aideront à respecter ces limites, consultez la page Dépannage des erreurs de quota. Si vous dépassez ces quotas, des erreurs quotaExceeded sont générées.

Limite	Par défaut	Remarques
Nombre maximal d'octets par seconde et par projet dans les emplacements multirégionaux us et eu	1 Go par seconde	Votre projet peut diffuser jusqu'à 1 Go par seconde. Ce quota est cumulatif au sein d'un emplacement multirégional donné. En d'autres termes, la somme des octets par seconde transmis à l'ensemble des tables pour un projet donné au sein d'un emplacement multirégional est limitée à 1 Go. Le dépassement de cette limite entraîne des erreurs quotaExceeded. Si nécessaire, vous pouvez demander une augmentation de quota en contactant Cloud Customer Care. Demandez une augmentation dès que possible, au moins deux semaines avant que vous n'en ayez besoin. Il faut du temps pour augmenter les quotas, en particulier dans le cas d'une augmentation significative.
Nombre maximal d'octets par seconde et par projet dans tous les autres emplacements	300 Mo par seconde	Votre projet peut diffuser jusqu'à 300 Mo par seconde dans tous les emplacements sauf les emplacements multirégionaux us et eu. Ce quota est cumulatif au sein d'un emplacement multirégional donné. En d'autres termes, la somme des octets par seconde transmis à l'ensemble des tables pour un projet donné au sein d'un emplacement régional est limitée à 300 Mo. Le dépassement de cette limite entraîne des erreurs quotaExceeded. Si nécessaire, vous pouvez demander une augmentation de quota en contactant Cloud Customer Care. Demandez une augmentation dès que possible, au moins deux semaines avant que vous n'en ayez besoin. Il faut du temps pour augmenter les quotas, en particulier dans le cas d'une augmentation significative.
Taille maximale des lignes	10 Mo	Si vous dépassez cette valeur, des erreurs invalid sont générées.
Taille limite des requêtes HTTP	10 Mo	Si vous dépassez cette valeur, des erreurs invalid sont générées. En interne, la requête est traduite de HTTP JSON en une structure de données interne. La structure de données traduite applique sa propre limite de taille. Il est difficile de prédire la taille de la structure de données interne obtenue. Toutefois, si vous conservez des requêtes HTTP de 10 Mo ou moins, le risque d'atteindre la limite interne est faible.
nombre maximal de lignes par requête	50 000 Lignes	Nous recommandons un maximum de 500 lignes. La mise en lots peut augmenter les performances et le débit jusqu'à un certain point, mais au prix d'une latence des requêtes. Si le nombre de lignes par requête est trop faible, l'impact de chaque requête peut rendre l'ingestion inefficace. Si le nombre de lignes par requête est trop important, le débit peut s'affaiblir. Testez des données représentatives (tailles de schémas et de données) pour déterminer la taille de lot idéale pour vos données.
Longueur du champ insertId	128 caractères	Si vous dépassez cette valeur, des erreurs invalid sont générées.

Pour obtenir des quotas de streaming supplémentaires, consultez la page Demander une augmentation de quota.