Quotas et limites

Ce document recense les quotas et limites système qui s'appliquent à BigQuery.

• Les quotas ont des valeurs par défaut, mais vous pouvez généralement demander des ajustements.
• Les limites système sont des valeurs fixes qui ne peuvent pas être modifiées.

Google Cloud utilise des quotas pour garantir l'équité et réduire les pics d'utilisation et de disponibilité des ressources. Un quota limite la quantité d'une ressourceGoogle Cloud que votre projet Google Cloud peut utiliser. Les quotas s'appliquent à différents types de ressources, y compris les composants matériels, logiciels et réseau. Par exemple, ils peuvent limiter le nombre d'appels d'API à un service, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Ils protègent la communauté des utilisateurs deGoogle Cloud en empêchant la surcharge des services. Les quotas vous aident également à gérer vos propres ressources Google Cloud .

Le système Cloud Quotas permet d'effectuer les opérations suivantes :

• Surveiller votre consommation de produits et services Google Cloud
• Limiter votre consommation de ces ressources
• Demander des modifications de la valeur du quota et automatiser les ajustements de quota

Dans la plupart des cas, lorsque vous tentez d'utiliser une ressource plus que son quota ne le permet, le système bloque l'accès à la ressource et la tâche que vous essayez d'effectuer échoue.

Les quotas s'appliquent généralement au niveau du projet Google Cloud . Votre utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet. Dans un projet Google Cloud , les quotas sont partagés entre toutes les applications et adresses IP.

Pour en savoir plus, consultez la présentation des quotas Cloud.

Des limites système s'appliquent également aux ressources BigQuery. Elles ne peuvent pas être modifiées.

Certains messages d'erreur indiquent des quotas ou des limites que vous pouvez augmenter, tandis que d'autres indiquent des quotas ou des limites que vous ne pouvez pas augmenter. Atteindre une limite stricte signifie que vous devez mettre en œuvre des solutions de contournement temporaires ou permanentes, ou des bonnes pratiques pour votre charge de travail. Il s'agit d'une bonne pratique, même pour les quotas ou les limites qui peuvent être augmentés. Pour en savoir plus sur ces deux types d'erreurs, consultez Résoudre les erreurs de quota et de limite.

Calcul de l'utilisation du quota d'emplacements

Pour les projets utilisant le modèle de tarification basée sur la capacité, y compris les éditions BigQuery, la colonne Utilisé du quota Nombre total d'emplacements reflète votre capacité totale allouée dans une région spécifique. Cette valeur inclut tous les emplacements de base définis dans vos réservations, ainsi que tous les engagements de capacité actifs. Étant donné que les emplacements de référence sont des ressources disponibles dédiées, ils apparaissent comme "utilisés" par le système de quotas, même lorsqu'ils sont inactifs. Pour en savoir plus sur la différence avec la surveillance des ressources, consultez Comprendre les métriques d'emplacements.

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 utilisateur, de l'historique d'Service Usage et d'autres facteurs, et sont susceptibles d'être modifiées sans préavis.

Renouvellement de quota

Les quotas quotidiens sont réinitialisés à intervalles réguliers tout au long de la journée, ce qui reflète leur objectif de guider les comportements de limitation du débit. 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 ajuster la plupart des quotas, utilisez la console Google Cloud . Pour en savoir plus, consultez Demander un ajustement 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 créant un remplacement de quota, consultez Créer un remplacement de quota.

Autorisations requises

Pour afficher et mettre à jour vos quotas BigQuery dans la consoleGoogle Cloud , vous avez besoin des mêmes autorisations que pour tout quota Google Cloud. Pour en savoir plus, consultez Autorisations de quotaGoogle Cloud .

Résoudre les problèmes

Pour en savoir plus sur le dépannage des erreurs liées aux quotas et aux limites, consultez la page Dépannage des erreurs de quota BigQuery.

Obtenir les noms des métriques de quota et de limite du système

Vous pouvez utiliser la console Google Cloud ou la Google Cloud CLI pour trouver les noms des métriques et les ID de quota (également appelés noms de limites) pour vos quotas et limites système BigQuery :

Console

1. Dans la console Google Cloud , accédez à la page Quotas et limites du système.

   Accéder à la page Quotas et limites du système

2. Cliquez sur Filtrer, sélectionnez Service, puis sélectionnez le service BigQuery que vous souhaitez inspecter (par exemple, API BigQuery, API BigQuery Reservation ou API BigQuery Storage).

3. Dans l'en-tête du tableau, cliquez sur Options d'affichage des colonnes, sélectionnez Métrique et Nom de la limite, puis cliquez sur OK.

gcloud

Exécutez la commande gcloud beta quotas info list :

gcloud beta quotas info list --project=PROJECT_ID_OR_NUMBER \
    --service=SERVICE_NAME \
    --format="table(metric, name, quota_id, dimensions)"

Remplacez les éléments suivants :

• PROJECT_ID_OR_NUMBER : ID ou numéro de votre projet Google Cloud .
• SERVICE_NAME : nom du service BigQuery que vous souhaitez inspecter :
• API BigQuery principale : bigquery.googleapis.com
• API Storage Read et API Storage Write (gRPC) : bigquerystorage.googleapis.com
• API BigQuery Reservation : bigqueryreservation.googleapis.com
• API BigQuery Migration : bigquerymigration.googleapis.com
• API Service de transfert de données BigQuery : bigquerydatatransfer.googleapis.com
• API BigQuery Connection : bigqueryconnection.googleapis.com
• API BigLake : biglake.googleapis.com
• API BigQuery Sharing (anciennement Analytics Hub) : analyticshub.googleapis.com
• API BigQuery DataPolicy : bigquerydatapolicy.googleapis.com

Jobs

Les quotas et les limites s'appliquent aux jobs que BigQuery exécute en votre nom, qu'ils soient exécutés à l'aide de la console Google Cloud , 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.

Jobs en attente

La limite suivante s'applique aux jobs en attente dans BigQuery :

Limite système	Par défaut	Remarques
Nombre maximal de jobs en attente	50 000 jobs par projet et par région	Nombre de jobs simultanés pouvant être à l'état "En attente". Cette limite ne peut pas être augmentée. Pour en savoir plus, consultez Dépannage des erreurs de quota BigQuery.

Tâches de requête

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

Pour en savoir plus sur le dépannage, consultez la page Dépannage de BigQuery.

Quota	ID de métrique et de quota	Par défaut	Remarques
Utilisation des requêtes par jour	Métrique : bigquery.googleapis.com/quota/query/usage ID de quota : QueryUsagePerDay	200 tébioctets (Tio)	Ce quota ne s'applique qu'au modèle de tarification des requêtes à la demande. Votre projet peut exécuter jusqu'à 200 Tio de requêtes par jour. Vous pouvez modifier cette limite à tout moment. Pour en savoir plus sur le contrôle des coûts, consultez Créer des quotas de requêtes personnalisés.
Utilisation des requêtes par jour et par utilisateur	Métrique : bigquery.googleapis.com/quota/query/usage ID de quota : QueryUsagePerUserPerDay	Illimité	Ce quota ne s'applique qu'au modèle de tarification des requêtes à la demande. Par défaut, il n'y a pas de limite au nombre de Tio de requêtes qu'un utilisateur peut exécuter par jour. Vous pouvez définir la limite à tout moment. Quelle que soit la limite par utilisateur, l'utilisation totale de tous les utilisateurs du projet ne peut jamais dépasser la limite d'utilisation des requêtes par jour. Pour en savoir plus sur le contrôle des coûts, consultez Créer des quotas de requêtes personnalisés.
Octets de requêtes fédérées GoogleSQL interrégionales par jour	Métrique : bigquery.googleapis.com/quota/query/cloud_sql_federated_query_cross_region_bytes ID de quota : CloudSqlFederatedQueryCrossRegionBytesPerDay	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.
Octets transférés par BigQuery Omni par jour	Métrique : bigquery.googleapis.com/quota/query/cross_cloud_transfer_bytes ID de quota : CrossCloudTransferBytesPerDay	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.
Taille totale des résultats de requête BigQuery Omni par jour	Métrique : bigquery.googleapis.com/quota/query/omni_query_bytes ID de quota : OmniQueriesBytesPerDay	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.

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

Limite système	Valeur	Remarques
Octets transférés par BigQuery Omni par job	60 Go	La taille de transfert maximale par job est de 60 Go lorsque vous exécutez des instructions CREATE TABLE AS SELECT (CTAS) ou INSERT INTO SELECT dans des régions BigQuery Omni pour filtrer les données lors d'un transfert cross-cloud. Cette limite s'applique également aux jointures BigQuery Omni, qui exécutent une requête Omni CTAS en arrière-plan pour transférer des données vers une table temporaire dans votre région BigQuery. Pour demander une augmentation, contactez l'assistance. Pour en savoir plus, consultez Coûts des jointures BigQuery Omni.
Octets transférés par des requêtes globales par jour et par paire de régions	180 To	Vous pouvez transférer jusqu'à 180 To de données par jour entre chaque paire de régions avec des requêtes globales. Pour demander une augmentation de quota, contactez l'assistance.
Jobs de copie de requêtes globales par projet	10 000	Vous pouvez exécuter jusqu'à 10 000 jobs de copie par projet lorsque vous exécutez des requêtes globales qui copient des données entre les régions. Une requête globale peut déclencher plusieurs jobs de copie. Pour demander une augmentation de quota, contactez l'assistance.
Octets transférés par une seule tâche de copie dans une requête globale	100 Go	Par défaut, un job de copie unique faisant partie d'une requête globale peut transférer un maximum de 100 Go. Pour demander une augmentation de la limite, contactez l'assistance.
Mises à jour des options globales au niveau du projet	5	Lorsque vous exécutez une instruction LDD qui modifie les options de configuration globales, vous pouvez exécuter jusqu'à cinq instructions toutes les 10 secondes. Cette limite s'applique aux instructions LDD suivantes : ALTER PROJECT SET OPTIONS ALTER ORGANIZATION SET OPTIONS
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. Pour résoudre ces erreurs, consultez Éviter les limites pour les requêtes interactives à volume élevé.
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 Nombre maximal d'opérations de table 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 la console Google Cloud ou l'outil de ligne de commande bq, ou bien en appelant les méthodes d'API jobs.query et jobs.insert de type requête.
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. Toutefois, BigQuery peut relancer en interne un job de requête en raison de problèmes temporaires, tels que des redémarrages de serveur. BigQuery peut tenter une requête jusqu'à trois fois, 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 (jusqu'à 18 heures). Pour vérifier si un job a été relancé, vous pouvez rechercher les signaux suivants : ConsoleGoogle Cloud  : dans l'explorateur de jobs, comparez deux jobs. Dans la section Analyse au niveau de la requête, cochez le champ Nouvelle tentative dans l'onglet Métriques. INFORMATION_SCHEMA : dans les vues INFORMATION_SCHEMA.JOBS, vérifiez la colonne final_execution_duration_ms. Si la différence entre start_time et end_time est nettement supérieure à final_execution_duration_ms, la requête a été relancée. API BigQuery : dans l'objet JobStatistics, vérifiez le champ finalExecutionDurationMs. Si la différence entre startTime et endTime est nettement supérieure à finalExecutionDurationMs, la requête a été relancée. Pour en savoir plus, consultez Durée d'exécution dans la documentation sur le dépannage des requêtes. Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des jobs de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 48 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 des requêtes SQL en caractères	1 024 000 caractères	Une requête SQL peut comporter jusqu'à 1 024 000 caractères. Cette limite inclut les commentaires et les espaces blancs. 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 et de diviser une requête longue en plusieurs requêtes dans la session.
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. Cela inclut les colonnes imbriquées et répétées. Les colonnes supprimées peuvent continuer à être comptabilisées dans le nombre total de colonnes. Si vous avez supprimé des colonnes, vous pouvez recevoir des erreurs de quota jusqu'à ce que le total soit réinitialisé.
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. BigQuery tente d'allouer équitablement les emplacements 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 dépasser cette limite pour accélérer vos requêtes. La capacité est soumise à disponibilité. 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 Messages d'erreur.
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 Microsoft 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 maximale des lignes BigQuery Omni	10 Mio	La taille maximale des lignes est de 10 Mio lors de l'interrogation de données Microsoft Azure ou AWS. Pour en savoir plus, consultez la page Limites de BigQuery Omni.
Transfert de requêtes globales	2 Gio/s	Bande passante de transfert utilisée par les requêtes globales, par projet et par paire de régions

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'extraction

Les quotas suivants s'appliquent aux jobs qui extraient des données de 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 extraction :

Quota	ID de métrique et de quota	Par défaut	Remarques
Nombre maximal d'octets extraits par jour	Métrique : bigquery.googleapis.com/quota/extract/bytes ID de quota : ExtractBytesPerDay	50 Tio	La limite de 50 Tio par jour (ExtractBytesPerDay) est une limite de prévention des abus qui ne s'applique qu'aux jobs d'extraction utilisant le pool d'emplacements partagés sans frais. Vous pouvez extraire sans frais jusqu'à 50 Tio de données par jour 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 extraits. Les jobs d'extraction sont exemptés de la limite quotidienne de 50 Tio et peuvent la dépasser si vous effectuez l'une des opérations suivantes : Créez une réservation d'emplacement ou utilisez une réservation existante, puis attribuez votre projet à la réservation avec le type de mission PIPELINE. Comme les jobs d'extraction utilisent une capacité d'emplacements dédiée ou en autoscaling au lieu du pool partagé, ils contournent le quota quotidien de 50 Tio. Vous êtes facturé selon la tarification basée sur la capacité. Les instructions EXPORT DATA ne sont pas compatibles avec les réservations PIPELINE. Utilisez l'instruction SQL EXPORT DATA. Étant donné que l'instruction s'exécute en tant que job de requête utilisant la capacité de requête plutôt que le pool d'extraction partagé, elle est exemptée du quota d'octets d'extraction. Vous êtes facturé à la demande ou selon la capacité, en fonction de la configuration de votre projet. Utilisez l'API Storage Read. Comme les lectures en flux continu lisent directement à partir de l'espace de stockage BigQuery, elles contournent les quotas des jobs d'extraction. Vous serez facturé selon le tarif des lectures en streaming. Le délai d'expiration minimal est garanti à au moins 6 heures, à compter de la création de la session.
Nombre maximal de jobs d'extraction par jour	Métrique : bigquery.googleapis.com/quota/extract/count ID de quota : ExtractJobsPerDay	100 000 jobs d'extraction	La limite de 100 000 jobs d'extraction par jour est une limite de prévention des abus qui ne s'applique qu'aux jobs d'extraction utilisant le pool d'emplacements partagé sans frais. Vous pouvez exécuter jusqu'à 100 000 jobs d'extraction par jour dans un projet sans frais à l'aide du pool d'emplacements partagé. Les jobs d'extraction sont exemptés de la limite de 100 000 jobs par jour et peuvent la dépasser si vous effectuez l'une des opérations suivantes : Créez une réservation d'emplacement ou utilisez une réservation existante, puis attribuez votre projet à la réservation avec le type de mission PIPELINE. Étant donné que les jobs d'extraction utilisent une capacité dédiée ou autoscalée au lieu du pool partagé, ils contournent complètement la limite quotidienne de jobs d'extraction. Vous êtes facturé selon la tarification basée sur la capacité. Utilisez l'instruction SQL EXPORT DATA. Comme l'instruction s'exécute en tant que job de requête, elle est exemptée des limites quotidiennes des jobs d'extraction. Vous êtes facturé à la demande ou selon la capacité, en fonction de la configuration de votre projet. Utilisez l'API Storage Read. Comme les lectures en flux continu lisent directement à partir de l'espace de stockage BigQuery, elles contournent les quotas des jobs d'extraction. Vous serez facturé selon le tarif des lectures en streaming. Le délai d'expiration minimal est garanti à au moins 6 heures, à compter de la création de la session.

Les limites système suivantes s'appliquent aux jobs d'extraction :

Limite système	Valeur	Remarques
Taille maximale de table extraite vers un seul fichier	1 Go	Vous pouvez extraire jusqu'à 1 Go de données de table dans un seul fichier. Pour extraire plus de 1 Go de données, utilisez un caractère générique pour extraire 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 job d'extraction	500 URI	Un job d'extraction peut comporter jusqu'à 500 URI génériques.

Pour en savoir plus sur votre utilisation actuelle des jobs d'extraction, consultez la page Afficher l'utilisation actuelle des quotas. Pour en savoir plus, consultez Résoudre les problèmes d'exportation.

Tâches de chargement

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

Limite système	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. Cela inclut les colonnes imbriquées et répétées.
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. Cette limite ne s'applique pas aux jobs avec une réservation.
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 délimité par un retour à la ligne (ndJSON) : taille maximale des lignes	100 Mo	La taille des lignes ndJSON peut atteindre 100 Mo.
ndJSON : taille maximale du fichier (compressé)	4 Go	La taille maximale d'un fichier ndJSON compressé est de 4 Go.
ndJSON : taille maximale du fichier (non compressé)	5 To	La taille maximale d'un fichier ndJSON 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 système	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. Pour en savoir plus sur la résolution des problèmes liés aux jobs de copie, consultez Nombre maximal de jobs de copie par jour et par erreur de quota de projet.

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

Limite système	Par défaut	Remarques
Nombre maximal de tables dans l'ensemble de données source	25 000 tables	Un ensemble de données source peut contenir jusqu'à 25 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 jusqu'à 20 000 tables par exécution dans un ensemble de données de destination situé dans la même région. Si un ensemble de données source contient plus de 20 000 tables, le service de transfert de données BigQuery planifie des exécutions séquentielles, chacune copiant jusqu'à 20 000 tables, jusqu'à ce que toutes les tables soient copiées. Ces exécutions sont séparées par un intervalle par défaut de 24 heures, que les utilisateurs peuvent personnaliser jusqu'à un minimum de 12 heures.
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 jusqu'à 1 000 tables par exécution dans un ensemble de données de destination situé dans une région différente. Si un ensemble de données source contient plus de 1 000 tables, le service de transfert de données BigQuery planifie des exécutions séquentielles, chacune copiant jusqu'à 1 000 tables, jusqu'à ce que toutes les tables soient copiées. Ces exécutions sont séparées par un intervalle par défaut de 24 heures, que les utilisateurs peuvent personnaliser jusqu'à un minimum de 12 heures.

Réservations

Les quotas suivants s'appliquent aux réservations :

Quota	ID de métrique et de quota	Par défaut	Remarques
Nombre total d'emplacements pour la région UE	Métrique : bigqueryreservation.googleapis.com/total_slots_eu ID de quota : TotalSlotsPerProjectEU	5 000 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans l'emplacement multirégional UE à l'aide de la console Google Cloud .
Nombre total d'emplacements pour la région États-Unis	Métrique : bigqueryreservation.googleapis.com/total_slots_us ID de quota : TotalSlotsPerProjectUS	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 .
Nombre total d'emplacements pour la région us-east1	Métrique : bigqueryreservation.googleapis.com/total_slots ID de quota : TotalSlotsPerProject	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 .
Nombre total d'emplacements pour les régions suivantes : asia-south1, asia-southeast1, europe-west2, us-central1, us-west1	Métrique : bigqueryreservation.googleapis.com/total_slots ID de quota : TotalSlotsPerProject	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 .
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	Métrique : bigqueryreservation.googleapis.com/total_slots ID de quota : TotalSlotsPerProject	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 .
Nombre total d'emplacements pour les régions BigQuery Omni	Métrique : bigqueryreservation.googleapis.com/totalslotsOMNI_REGION (par exemple, bigqueryreservation.googleapis.com/total_slots_aws-us-east-1) ID de quota : TotalSlotsPerProjectOMNI_REGION (par exemple, TotalSlotsPerProjectAwsUSEast1)	100 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans les régions BigQuery Omni à l'aide de la console Google Cloud .
Nombre total d'emplacements pour toutes les autres régions	Métrique : bigqueryreservation.googleapis.com/total_slots ID de quota : TotalSlotsPerProject	500 emplacements	Nombre maximal d'emplacements BigQuery que vous pouvez acheter dans d'autres régions à l'aide de la console Google Cloud .
Nombre de projets d'administration pour les réservations d'emplacements	Métrique : bigqueryreservation.googleapis.com/total_admin_projects ID de quota : TotalAdminProjectsPerOrganization	10 projets par organisation	Nombre maximal de projets d'administration dans une organisation pouvant contenir une réservation ou un engagement actif pour des emplacements correspondant à une localisation ou une région donnée.

Les limites système suivantes s'appliquent aux réservations :

Limite système	Valeur	Remarques
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 d'é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.
Nombre maximal d'emplacements dans une réservation associée à une attribution de réservation avec un type de mission CONTINUOUS.	500 emplacements	Lorsque vous souhaitez créer une attribution de réservation avec un type de mission CONTINUOUS, la réservation associée ne peut pas comporter plus de 500 emplacements.

Ensembles de données

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

Limite système	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'à 2 500 ressources autorisées au total, y compris des vues autorisées, des ensembles de données autorisés et des fonctions autorisées. Si vous dépassez cette limite en raison d'un grand nombre de vues autorisées, envisagez de regrouper les vues dans des ensembles de données autorisés. Nous vous recommandons de regrouper les vues associées dans des ensembles de données autorisés lorsque vous concevez de nouvelles architectures BigQuery, en particulier des architectures mutualisées.
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 : ConsoleGoogle Cloud L'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 que vous la supprimez puis la recréez, le quota ou la limite ne sont pas réinitialisés, car le nom de la table n'a pas changé.

Limite système	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).
Longueur maximale d'une description de table	16 384 caractères	Lorsque vous ajoutez une description à une table, le texte ne doit pas comporter plus de 16 384 caractères.

Pour en savoir plus sur la résolution des problèmes liés aux quotas ou aux limites des tables, consultez la page Résoudre les problèmes liés à BigQuery.

Tables standards

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

Limite système	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. Une tâche de chargement, une tâche de copie ou une tâche de requête qui ajoute ou écrase des données de table compte comme une modification de la table. Cette limite ne peut pas être modifiée. Cette limite est appliquée en tant que limite de débit tout au long de la journée, et non en tant que quota unique alloué en une seule fois. BigQuery réapprovisionne régulièrement le quota disponible. Les pics d'opérations à haute fréquence peuvent épuiser le quota disponible, ce qui entraîne des erreurs quotaExceeded même si votre volume quotidien total est bien inférieur à la limite quotidienne de 1 500 modifications. Pour optimiser l'ingestion à haute fréquence, envisagez de regrouper les opérations par lot, d'espacer les jobs de manière uniforme dans le temps ou de migrer vers l'API BigQuery Storage Write (gRPC). Les instructions LMD sont exclues et ne sont pas comptabilisées dans le nombre de modifications de table par jour. Les données de flux sont exclues et 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 : ConsoleGoogle Cloud L'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 Résoudre les erreurs de quota pour savoir comment diagnostiquer et résoudre 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. Cela inclut les colonnes imbriquées et répétées.

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 système	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 300 000 000 de fichiers	Une table externe peut référencer un bucket Cloud Storage contenant jusqu'à 300 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 système	Par défaut	Remarques
Nombre de partitions par table partitionnée	10 000 partitions	Chaque table partitionnée peut comporter jusqu'à 10 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 partitions pendant l'ingestion par table partitionnée et par jour	11 000 modifications	Votre projet peut effectuer jusqu'à 11 000 modifications de partition par jour. Une modification de partition consiste à ajouter, mettre à jour, supprimer ou tronquer des données dans une table partitionnée. Une modification de partition est comptabilisée pour chaque type de modification de données que vous effectuez. Par exemple, la suppression d'une ligne est comptabilisée comme une modification de partition, tout comme la suppression d'une partition entière. Si vous supprimez une ligne d'une partition, puis l'insérez dans une autre partition, cela compte comme deux modifications de partition. Les modifications effectuées à l'aide d'instructions LMD ou de l'API Streaming 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 de flux 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 : ConsoleGoogle Cloud L'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 système	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 système	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 système	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.
Longueur maximale d'une description de vue	16 384 caractères	Lorsque vous ajoutez une description à une vue, le texte ne doit pas comporter plus de 16 384 caractères.

Vues matérialisées

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

Limite système	Par défaut	Remarques
Références à des tables 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 de table de base (organisation entière)	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.
Longueur maximale d'une description de vue matérialisée	16 384 caractères	Lorsque vous ajoutez une description à une vue matérialisée, le texte ne doit pas comporter plus de 16 384 caractères.
Limite de temps d'exécution d'une tâche d'actualisation de vue matérialisée	12 heures	Un job d'actualisation de vue matérialisée peut s'exécuter pendant 12 heures maximum avant d'échouer.

Index de recherche

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

Limite système	Par défaut	Remarques
Nombre d'instructions LDD CREATE INDEX ou ALTER INDEX par projet, par région et par jour	500 opérations	Votre projet peut émettre jusqu'à 500 opérations LDD CREATE INDEX ou ALTER 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, ALTER 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.
Nombre de colonnes indexées avec un niveau de détail par colonne et par table	63 colonnes par table	Une table peut comporter jusqu'à 63 colonnes dont la valeur index_granularity est définie sur COLUMN. Les colonnes indexées avec une précision COLUMN en définissant l'option default_index_column_granularity sont comptabilisées dans cette limite. Le nombre de colonnes indexées avec une précision GLOBAL n'est pas limité. Pour en savoir plus, consultez Indexer avec une précision au niveau des colonnes.

Index vectoriels

Les limites suivantes s'appliquent aux index vectoriels BigQuery :

Limite système	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 de la table de base pour le type d'index IVF	10 000 000 000 de lignes	Une table peut contenir au maximum 10 000 000 000 lignes pour créer un index vectoriel IVF.
Nombre maximal de lignes de la table de base pour le type d'index TREE_AH	200 000 000 de lignes	Une table peut contenir au maximum 200 000 000 lignes pour créer un index vectoriel TREE_AH.
Nombre maximal de lignes de la table de base pour le type d'index partitionné TREE_AH	10 000 000 000 de lignes au total 200 000 000 de lignes pour chaque partition	Une table peut contenir au maximum 10 000 000 000 de lignes, et chaque partition peut contenir au maximum 200 000 000 de lignes pour créer un index vectoriel partitionné TREE_AH.
Taille maximale du tableau dans la colonne indexée	4 096 éléments	La colonne à indexer peut contenir au maximum 4 096 é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	6 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 à 6 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 système	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 SQL simultanées en ancien SQL avec des UDF JavaScript	6 requêtes	Votre projet peut comporter jusqu'à six requêtes simultanées en ancien SQL et 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 UDF persistantes :

Limite système	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.
UDF Python : octets de stockage d'images par projet et par région	10 Gio	Taille totale en octets de toutes les images de conteneurs utilisées par les fonctions définies par l'utilisateur Python dans un projet et une région spécifiques.
UDF Python : limite de mutation	30 par minute	Vous pouvez créer ou mettre à jour des UDF Python jusqu'à 30 fois par minute, par région et par projet.
UDF Python : nombre maximal d'UDF Python simultanées	10	Vous pouvez exécuter jusqu'à 10 requêtes simultanées qui référencent des fonctions définies par l'utilisateur en Python par projet.

Fonctions distantes

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

Pour en savoir plus sur le dépannage, consultez Nombre maximal de requêtes simultanées contenant des fonctions distantes.

Limite système	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 Run Functions 1re génération)	10 Mo	Le corps de la réponse HTTP de votre fonction Cloud Run 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 Run Functions 2e génération ou Cloud Run)	15 Mo	Le corps de la réponse HTTP de la fonction Cloud Run 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 (fonctions Cloud Run 1re génération)	9 minutes	Vous pouvez définir votre propre limite de temps pour votre fonction Cloud Run 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 Run de 1re génération peut entraîner des échecs d'appels HTTP et des requêtes.
Durée maximale de l'appel HTTP (fonctions Cloud Run 2e génération ou Cloud Run)	20 minutes	La limite de temps pour un appel HTTP individuel à votre fonction Cloud Run 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.
Nombre maximal de nouvelles tentatives d'appel HTTP	20	Nombre maximal de nouvelles tentatives pour un appel HTTP individuel à votre fonction Cloud Run de 1re ou 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.

Fonctions de table

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

Limite système	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 du système	Par défaut	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 comptabilisées dans cette limite. 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 un emplacement régional situés dans la même zone géographique, vos requêtes peuvent consommer le même quota de processeur simultané.
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 qui ont déjà été traitées ne sont pas comptabilisées dans cette limite. Si vous exécutez des requêtes simultanées dans un emplacement multirégional et un emplacement régional situés dans la même zone géographique, vos requêtes peuvent consommer le même quota de disques persistants standards.

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 du système	Par défaut	Notes
Taille maximale du notebook	20 Mo	La taille d'un notebook correspond à la somme de son contenu, de ses métadonnées et de la surcharge d'encodage. Vous pouvez afficher la taille du contenu d'un notebook en développant l'en-tête du notebook, puis en cliquant sur Afficher et 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.

Requêtes enregistrées

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

Limite du système	Par défaut	Notes
Taille maximale d'une requête enregistrée	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 système	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 INSERT simultanées par table et par jour	1 500 instructions	Les 1 500 premières instructions INSERT s'exécutent immédiatement après leur envoi. Une fois cette limite atteinte, les instructions INSERT simultanées qui écrivent dans une table sont limitées à 10. Des instructions INSERT supplémentaires sont ajoutées à une file d'attente PENDING. Jusqu'à 100 instructions INSERT peuvent être placées en file d'attente sur une table à tout moment. Lorsqu'une instruction INSERT se termine, l'instruction INSERT suivante est supprimée de la file d'attente et exécutée. Si vous devez exécuter des instructions LMD INSERT plus fréquemment, envisagez de diffuser des données dans votre table à l'aide de l'API Storage Write (gRPC).
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	7 heures	Une instruction LMD interactive prioritaire peut attendre dans la file d'attente pendant sept heures maximum. Si l'instruction n'est pas exécutée au bout de sept 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 système	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 système	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 du système	Par défaut	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 système	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 système	Par défaut	Remarques
CREATE MODEL requêtes avec instruction par période de 48 heures et par projet	20 000 requête avec instruction	Certains modèles sont entraînés à l'aide de services Vertex AI, qui possèdent leur propre gestion des ressources et des quotas.
Limite de durée d'exécution	24 ou 48 heures	Le délai avant expiration du job CREATE MODEL est défini par défaut sur 24 heures, à l'exception des jobs de série temporelle, des jobs AutoML et des jobs de réglage d'hyperparamètres qui expirent après 48 heures.

Fonctions d'IA générative

Les limites suivantes s'appliquent aux fonctions qui utilisent des grands modèles de langage (LLM) Agent Platform. Pour en savoir plus, consultez Définitions des quotas de fonctions.

Limites de requêtes par minute

Les limites suivantes s'appliquent aux modèles Agent Platform qui utilisent une limite de requêtes par minute.

Fonction	Modèle	Région	Requêtes par minute	Lignes par job
AI.GENERATE_TEXT ML.GENERATE_TEXT AI.GENERATE_TABLE AI.GENERATE AI.GENERATE_BOOL AI.GENERATE_DOUBLE AI.GENERATE_INT	gemini-2.0-flash-lite-001	Emplacements multirégionaux US et EU Régions uniques, comme indiqué pour gemini-2.0-flash-lite-001 dans Emplacements des points de terminaison des modèles Google	Aucun quota défini. Quota déterminé par le quota partagé dynamique (DSQ)^1 et le débit provisionné^2	N/A pour le débit provisionné 10 500 000 pour DSQ, pour un appel avec une moyenne de 500 jetons d'entrée et 50 jetons de sortie
	gemini-2.0-flash-001	Emplacements multirégionaux US et EU Régions uniques, comme indiqué pour gemini-2.0-flash-001 dans Emplacements des points de terminaison des modèles Google		N/A pour le débit provisionné 10 200 000 pour les requêtes par seconde, pour un appel avec une moyenne de 500 jetons d'entrée et 50 jetons de sortie
	gemini-2.5-flash	Emplacements multirégionaux US et EU Régions uniques, comme indiqué pour gemini-2.5-flash dans Emplacements des points de terminaison des modèles Google		N/A pour le débit provisionné 9 300 000 pour DSQ, pour un appel avec une moyenne de 500 jetons d'entrée et 50 jetons de sortie
	gemini-2.5-pro	Emplacements multirégionaux US et EU Régions uniques, comme indiqué pour gemini-2.5-pro dans Emplacements des points de terminaison des modèles Google		N/A pour le débit provisionné 7 600 000 pour DSQ, pour un appel avec une moyenne de 500 jetons d'entrée et 50 jetons de sortie
AI.IF AI.SCORE AI.CLASSIFY	Différents modèles gemini-2.5-*	Emplacements multirégionaux US et EU Toute région unique compatible avec l'un des gemini-2.5-* models dans les emplacements de points de terminaison de modèle Google	Aucun quota défini. Quota déterminé par le quota partagé dynamique (DSQ)^1	10 000 000 pour un appel avec une moyenne de 500 jetons dans chaque ligne d'entrée et 50 jetons de sortie.
AI.AGG	Différents modèles Gemini	Consultez la page Emplacements.	Aucun quota défini. Quota déterminé par le quota partagé dynamique (QPD)^1.	20 000 000
AI.GENERATE_TEXT ML.GENERATE_TEXT	Anthropic Claude	Consultez Quotas par modèle et par région.	Consultez Quotas par modèle et par région.	Valeur des requêtes par minute * 60 * 6
	Llama	Consultez Disponibilité et quotas des régions d'un modèle Llama.	Consultez Disponibilité et quotas des régions d'un modèle Llama.
	Mistral AI	Consultez Disponibilité et quotas des régions d'un modèle Mistral AI.	Consultez Disponibilité et quotas des régions d'un modèle Mistral AI.
AI.GENERATE_EMBEDDING^5 AI.EMBED AI.SIMILARITY AI.SEARCH VECTOR_SEARCH ML.GENERATE_EMBEDDING^5	text-embedding text-multilingual-embedding	Toutes les régions compatibles avec les modèles distants	1 500^3,4	80 000 000 pour un appel avec une moyenne de 50 jetons dans chaque ligne d'entrée 14 000 000 pour un appel avec une moyenne de 600 jetons dans chaque ligne d'entrée
	multimodalembedding	Régions européennes uniques compatibles	120^3	43 200
		Régions autres que les régions uniques européennes compatibles	600^3	216 000
	gemini-embedding-2	US, EU et global	Aucun quota défini. Quota déterminé par le quota partagé dynamique (QPD)^1.	N/A

¹ Lorsque vous utilisez le DSQ, aucune limite de quota prédéfinie ne s'applique à votre utilisation. À la place, DSQ donne accès à un grand pool de ressources partagé, qui sont allouées de manière dynamique en fonction de la disponibilité des ressources en temps réel et de la demande des clients pour le modèle donné. Lorsque davantage de clients sont actifs, chaque client obtient moins de débit. De même, lorsque moins de clients sont actifs, chaque client peut obtenir un débit plus élevé.

² Le débit provisionné est un abonnement à coût fixe et à durée fixe, disponible pour plusieurs durées. Le débit provisionné vous permet de réserver du débit pour les modèles d'IA générative compatibles sur Agent Platform.

³ Pour augmenter le quota, demandez un ajustement du quota de RPM dans Agent Platform. Prévoyez 30 minutes pour que la valeur de quota augmentée se propage.

⁴ Vous pouvez augmenter le quota des modèles Agent Platform text-embedding et text-multilingual-embedding à 10 000 RPM sans approbation manuelle. Cela permet d'augmenter le débit à 500 000 000 de lignes par job ou plus, sur la base d'un appel avec une moyenne de 50 jetons dans chaque ligne d'entrée.

⁵ Cette fonction est limitée à un maximum de cinq jobs exécutés simultanément par projet.

Pour en savoir plus sur les quotas des LLM Agent Platform, consultez Limites de quota de l'IA générative sur Agent Platform.

Limites de jetons par minute

Les limites suivantes s'appliquent aux modèles Agent Platform qui utilisent une limite de jetons par minute :

Fonction	Jetons par minute	Lignes par job	Nombre de jobs exécutés simultanément
AI.GENERATE_EMBEDDING ou ML.GENERATE_EMBEDDING lors de l'utilisation d'un modèle distant sur un modèle gemini-embedding-001	10 000 000	12 000 000, pour un appel avec une moyenne de 300 jetons par ligne	5
AI.GENERATE_EMBEDDING ou ML.GENERATE_EMBEDDING lors de l'utilisation d'un modèle distant sur un modèle gemini-embedding-2	5 000 000	1 440 000	5

Limites de jetons par jour

Les limites quotidiennes suivantes s'appliquent à l'utilisation des jetons pour les grands modèles de langage accessibles via les fonctions d'IA générative de BigQuery. Ces limites s'appliquent globalement à toutes les régions, et vous pouvez demander un ajustement. Pour en savoir plus, consultez Contrôler les coûts avec des quotas de jetons.

Quota	ID de métrique et de quota	Par défaut	Remarques
Jetons d'entrée d'IA par jour	Métrique : bigquery.googleapis.com/quota/query/ai_input_tokens ID de quota : GenAiInputTokensPerDay	200 000 000 000	Jetons d'entrée utilisés par le LLM. S'applique par jour et par projet.
Jetons d'entrée d'IA par jour et par utilisateur	Métrique : bigquery.googleapis.com/quota/query/ai_input_tokens ID de quota : GenAiInputTokensPerUserPerDay	150 000 000 000	Jetons d'entrée utilisés par le LLM. S'applique par jour, par projet et par utilisateur.
Jetons de sortie d'IA par jour	Métrique : bigquery.googleapis.com/quota/query/ai_output_tokens ID de quota : GenAiOutputTokensPerDay	20 000 000 000	Jetons de sortie et de pensée utilisés par le LLM. S'applique par jour et par projet.
Jetons de sortie d'IA par jour et par utilisateur	Métrique : bigquery.googleapis.com/quota/query/ai_output_tokens ID de quota : GenAiOutputTokensPerUserPerDay	15 000 000 000	Jetons de sortie et de pensée utilisés par le LLM. S'applique par jour, par projet et par utilisateur.

Fonctions des services d'IA Cloud

Les limites suivantes s'appliquent aux fonctions qui utilisent des services d'IA Cloud :

Fonction	Requêtes par minute	Lignes par job	Nombre de jobs exécutés simultanément
ML.PROCESS_DOCUMENT avec des documents d'une cinquantaine de pages en moyenne	600	100 000 (sur la base d'une moyenne de 50 pages par document d'entrée)	5
ML.TRANSCRIBE	200	10 000 (sur la base d'une durée moyenne d'une minute pour chaque fichier audio d'entrée)	5
ML.ANNOTATE_IMAGE	1 800	648 000	5
ML.TRANSLATE	6 000	2 160 000	5
ML.UNDERSTAND_TEXT	600	21 600	5

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

• 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

Définitions des quotas de fonctions

La liste suivante décrit les quotas qui s'appliquent aux fonctions des services d'IA générative et d'IA Cloud :

• Les fonctions qui appellent un modèle Agent Platform utilisent un quota Agent Platform, à 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 Agent Platform. 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 de modèles Agent Platform, consultez Limites de quota de l'IA générative sur Agent Platform.
• Les fonctions qui appellent un service d'IA Cloud utilisent les quotas de requêtes du service cible. Consultez la documentation de référence sur les quotas du service d'IA Cloud concerné pour plus de détails.

• BigQuery ML utilise les quotas suivants :

  • 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 Agent Platform ou du service IA Cloud. Cette limite s'applique à chaque projet et est partagée entre tous les jobs utilisant le même point de terminaison de modèle.

    Les appels aux modèles Gemini d'Agent Platform ne sont pas soumis à des limites de quota prédéfinies, car les modèles Gemini utilisent un quota partagé dynamique (DSQ). DSQ donne accès à un grand pool de ressources partagées, qui sont allouées de manière dynamique en fonction de la disponibilité en temps réel des ressources et de la demande des clients pour le modèle donné.

  • Jetons par minute. Ce quota correspond au nombre maximal de jetons par minute que les fonctions peuvent envoyer à l'API du modèle Agent Platform. Cette limite s'applique à chaque projet.

    Pour les fonctions qui appellent un modèle de fondation Agent Platform, le nombre de jetons par minute varie en fonction du point de terminaison, de la version et de la région du modèle Agent Platform, ainsi que de la réputation de votre projet. Ce quota est conceptuellement identique au quota de RPM utilisé par Agent Platform.

  • Lignes par job. La valeur Rows per job sert de benchmark de performances, en estimant la capacité de traitement lorsqu'un seul job utilise exclusivement les ressources de point de terminaison du modèle du projet. Le nombre réel de lignes traitées dépend de nombreux facteurs, y compris la taille de la requête d'entrée envoyée au modèle, la taille des réponses de sortie du modèle et la disponibilité du quota partagé dynamique. Les exemples suivants illustrent des scénarios courants :

    • Pour le point de terminaison gemini-2.0-flash-lite-001, le nombre de lignes pouvant être traitées par la fonction AI.GENERATE_TEXT ou ML.GENERATE_TEXT dépend du nombre de jetons d'entrée et de sortie. Le service peut traiter environ 7,6 millions de lignes pour les appels dont le nombre moyen de jetons d'entrée est de 2 000 et le nombre maximal de jetons de sortie est de 50. Ce nombre diminue à environ 1 million de lignes si le nombre moyen de jetons d'entrée est de 10 000 et que le nombre maximal de jetons de sortie est de 3 000.

      De même, le point de terminaison gemini-2.0-flash-001 peut traiter 4,4 millions de lignes pour les appels dont le nombre moyen de jetons d'entrée est de 2 000 et le nombre maximal de jetons de sortie est de 50, mais seulement environ 1 million de lignes pour les appels avec 10 000 jetons d'entrée et 3 000 jetons de sortie.

    • La fonction ML.PROCESS_DOCUMENT peut traiter plus de lignes par job pour les documents courts que pour les documents longs.

    • La fonction ML.TRANSCRIBE peut traiter plus de lignes par job pour les clips audio courts que pour les clips audio longs.

  • 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 Agent Platform. 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 Agent Platform, 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 Agent Platform, 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 Agent Platform. 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.

Graphique BigQuery

Les limites suivantes s'appliquent à BigQuery Graph :

Limite système	Par défaut	Remarques
Nombre maximal de tables référencées par un graphique	1 000 tables	Un graphique peut référencer jusqu'à 1 000 tables de nœuds et d'arêtes au total dans ses définitions de nœuds et d'arêtes.
Nombre maximal de colonnes de clé par table de nœuds ou d'arêtes	16 colonnes	Vous pouvez définir une clé qui utilise jusqu'à 16 colonnes sur une table de nœuds ou d'arêtes d'un graphe.
Nombre maximal de colonnes par référence de nœud	16 colonnes	Une clé source ou une clé de destination peut référencer jusqu'à 16 colonnes d'une table de nœuds dans un graphique.
Nombre maximal de colonnes par référence de périphérie	16 colonnes	La clé source ou la clé de destination d'une arête peut référencer jusqu'à 16 colonnes de la table d'arêtes.
Nombre maximal d'étiquettes sur un graphique	1 000 libellés	Vous pouvez définir jusqu'à 1 000 étiquettes de nœud et d'arête au total sur un graphique.
Nombre maximal d'étiquettes définies par nœud ou par périphérie	20 étiquettes	Vous pouvez définir jusqu'à 20 étiquettes sur un nœud ou un arc d'un graphique.
Nombre maximal de propriétés définies sur un graphique	5 000 propriétés	Vous pouvez définir jusqu'à 5 000 propriétés sur un graphique.
Nombre maximal de propriétés définies par libellé	1 000 propriétés	Vous pouvez définir jusqu'à 1 000 propriétés par libellé sur un graphique.

BI Engine

Les limites suivantes s'appliquent à BigQuery BI Engine.

Limite système	Par défaut	Remarques
Taille maximale de réservation par projet et par emplacement (BigQuery BI Engine)	250 Gio	La taille de réservation maximale par défaut est de 250 Gio par projet et par emplacement. 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 peuvent prendre au moins trois jours ouvrés, selon l'ampleur de l'augmentation demandée. Veuillez contacter votre représentant Google Cloudou Cloud Customer Care pour les demandes urgentes.
Nombre maximal de lignes par requête	7 milliards	Nombre maximal de lignes par requête.

BigQuery Sharing (anciennement Analytics Hub)

Les limites suivantes s'appliquent à BigQuery Sharing (anciennement Analytics Hub) :

Limite système	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 à BigQuery Sharing combinés peuvent posséder un maximum de 1 000 ensembles de données associés par ensemble de données partagé.

Découverte automatique Knowledge Catalog

Les limites suivantes s'appliquent à la découverte automatique de Knowledge Catalog :

Limite système	Par défaut	Remarques
Nombre maximal de tables BigQuery, BigLake ou externes par bucket Cloud Storage qu'une analyse de découverte accepte	1 000 tables BigQuery par bucket	Vous pouvez créer jusqu'à 1 000 tables BigQuery par bucket Cloud Storage.

Quotas et limites des API

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

API BigQuery

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

Quota	ID de métrique et de quota	Par défaut	Remarques
Requêtes par jour	Métrique : bigquery.googleapis.com/unlimited_requests ID de quota : UnlimitedRequestsPerDayPerProject	Illimité	Votre projet peut effectuer un nombre illimité de requêtes API BigQuery par jour.
Nombre maximal d'octets tabledata.list par minute	Métriques : bigquery.googleapis.com/quota/tabledata/list_bytes_us, bigquery.googleapis.com/quota/tabledata/list_bytes_eu, bigquery.googleapis.com/quota/tabledata/list_bytes_regional ID de quota : ListBytesPerSecondUs, ListBytesPerSecondEu, ListBytesPerSecondRegional	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 à l'aide de 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. Pour en savoir plus, consultez la page Dépannage. 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 système suivantes s'appliquent aux requêtes API BigQuery (cœur) :

Remarque : Bien que la plupart des méthodes principales de l'API BigQuery soient limitées à 100 requêtes API par utilisateur et par méthode, certaines méthodes principales peuvent avoir des limites de débit différentes.

Limite système	Valeur	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. Pour en savoir plus sur le dépannage, consultez la page Dépannage.
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	Dix requêtes	Un utilisateur peut effectuer jusqu'à 10 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 Référence : Limites et critères 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	Un utilisateur 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.

API BigQuery Connection

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

Quota	ID de métrique et de quota	Par défaut	Remarques
Requêtes de lecture par minute	Métrique : bigqueryconnection.googleapis.com/read_requests ID de quota : ReadRequestsPerMinutePerProject	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.
Requêtes d'écriture par minute	Métrique : bigqueryconnection.googleapis.com/write_requests ID de quota : WriteRequestsPerMinutePerProject	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.
Connexions BigQuery Omni créées par minute	Métrique : bigqueryconnection.googleapis.com/bq_omni_connection_creations ID de quota : BQOmniConnectionsCreatedPerMinute	10 connexions créées par minute	Votre projet peut créer jusqu'à 10 connexions BigQuery Omni au total sur AWS et Azure par minute.
Utilisations de la connexion BigQuery Omni	Métrique : bigqueryconnection.googleapis.com/bq_omni_connection_uses ID de quota : BQOmniConnectionUsesPerMinute	500 utilisations de connexion par minute	Votre projet peut utiliser une connexion BigQuery Omni jusqu'à 500 fois par minute. Cela s'applique aux opérations qui utilisent votre connexion pour accéder à votre compte AWS, comme l'interrogation d'une table.

API BigQuery Migration

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 :

Quota	ID de métrique et de quota	Par défaut	Remarques
Requêtes de listes d'EDWMigration Service par minute	Métrique : bigquerymigration.googleapis.com/edwmigration_service_list_requests ID de quota : ListRequestsPerMinutePerProject	12 000 requêtes	Votre projet peut envoyer jusqu'à 12 000 requêtes de liste de l'API Migration par minute.
Requêtes de listes d'EDWMigration Service par minute et par utilisateur	Métrique : bigquerymigration.googleapis.com/edwmigration_service_list_requests ID de quota : ListRequestsPerMinutePerProjectPerUser	2 500 requêtes	Chaque utilisateur peut générer jusqu'à 2 500 requêtes de liste de l'API Migration par minute.
Requêtes GET d'EDWMigration Service par minute	Métrique : bigquerymigration.googleapis.com/edwmigration_service_get_requests ID de quota : GetRequestsPerMinutePerProject	25 000 requêtes	Votre projet peut générer jusqu'à 25 000 requêtes GET de l'API Migration par minute.
Requêtes GET d'EDWMigration Service par minute et par utilisateur	Métrique : bigquerymigration.googleapis.com/edwmigration_service_get_requests ID de quota : GetRequestsPerMinutePerProjectPerUser	2 500 requêtes	Chaque utilisateur peut générer jusqu'à 2 500 requêtes GET de l'API Migration par minute.
Autres requêtes d'EDWMigration Service par minute	Métrique : bigquerymigration.googleapis.com/edwmigration_service_other_requests ID de quota : OtherRequestsPerMinutePerProject	25 requêtes	Votre projet peut envoyer jusqu'à 25 autres requêtes API de migration par minute.
Autres requêtes d'EDWMigration Service par minute et par utilisateur	Métrique : bigquerymigration.googleapis.com/edwmigration_service_other_requests ID de quota : OtherRequestsPerMinutePerProjectPerUser	5 requêtes	Chaque utilisateur peut envoyer jusqu'à 5 autres requêtes de l'API Migration par minute.
Requêtes de traduction SQL interactives par minute	Métrique : bigquerymigration.googleapis.com/sql_translation_translate_requests ID de quota : TranslationRequestsPerMinutePerProject	200 requêtes	Votre projet peut envoyer jusqu'à 200 demandes de service de traduction SQL par minute.
Requêtes de traduction SQL interactives par minute et par utilisateur	Métrique : bigquerymigration.googleapis.com/sql_translation_translate_requests ID de quota : TranslationRequestsPerMinutePerProjectPerUser	50 requêtes	Chaque utilisateur peut envoyer jusqu'à 50 requêtes de service de traduction SQL par minute.

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

Limite système	Valeur	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. Lorsque vous exécutez des traductions interactives à l'aide de l'API Translation, cette limite s'applique à la taille totale de toutes les entrées de chaîne.
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.
Nombre maximal de suggestions Gemini par heure	1 000 (peut être cumulé jusqu'à 10 000 s'il n'est pas utilisé)	Si nécessaire, vous pouvez demander une augmentation de quota en contactant Cloud Customer Care.

API BigQuery Reservation

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

Quota	ID de métrique et de quota	Par défaut	Remarques
Requêtes par minute et par région	Métrique : bigqueryreservation.googleapis.com/requests ID de quota : RequestsPerMinutePerProjectPerRegion	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.
Nombre d'appels SearchAllAssignments par minute et par région	Métrique : bigqueryreservation.googleapis.com/search_all_assignments_requests ID de quota : SearchAllAssignmentsRequestsPerMinutePerProjectPerRegion	100 requêtes	Votre projet peut envoyer jusqu'à 100 appels vers la méthode SearchAllAssignments par minute et par région.
Requêtes pour SearchAllAssignments par minute, par région et par utilisateur	Métrique : bigqueryreservation.googleapis.com/search_all_assignments_requests ID de quota : SearchAllAssignmentsRequestsPerMinutePerProjectPerUserPerRegion	Dix requêtes	Chaque utilisateur peut envoyer jusqu'à 10 appels à la méthode SearchAllAssignments par minute et par région.

API BigQuery DataPolicy

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

Limite système	Par défaut	Remarques
Nombre maximal d'appels dataPolicies.list.	400 requêtes par minute et par projet 600  requêtes par minute et par organisation
Nombre maximal d'appels dataPolicies.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 dataPolicies.get et dataPolicies.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 à : dataPolicies.create dataPolicies.delete dataPolicies.setIamPolicy dataPolicies.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 de langage de contrôle de données (LCD) 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.

Quota	ID de métrique et de quota	Par défaut	Notes
IamPolicy requêtes par minute et par utilisateur	Métrique : bigquery.googleapis.com/iam_policy_requests ID de quota : IamPolicyRequestsPerMinutePerUser	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.
IamPolicy requêtes par minute et par projet	Métrique : bigquery.googleapis.com/iam_policy_requests ID de quota : IamPolicyRequestsPerMinutePerProject	3 000 requêtes par minute et par projet	Votre projet peut générer jusqu'à 3 000 requêtes IAM par minute.
Requêtes SetIAMPolicy régionales par minute et par projet	Métrique : bigquery.googleapis.com/set_iam_policy_requests ID de quota : SetIamPolicyRequestsPerMinutePerProject	1 000 requêtes par minute et par projet	Votre projet régional peut effectuer jusqu'à 1 000 requêtes par minute.
Requêtes SetIAMPolicy multirégionales par minute et par projet	Métrique : bigquery.googleapis.com/set_iam_policy_requests_global ID de quota : SetIamPolicyRequestsPerMinutePerProjectGlobal	2 000 requêtes par minute et par projet	Votre projet multirégional peut générer jusqu'à 2 000 requêtes par minute.
SetIAMPolicy requêtes pour les régions Omni par minute et par projet	Métrique : bigquery.googleapis.com/set_iam_policy_requests_OMNI_REGION (par exemple, bigquery.googleapis.com/set_iam_policy_requests_aws-us-east-1) ID de quota : SetIamPolicyRequestsPerMinutePerProjectOMNI_REGION (par exemple, SetIamPolicyRequestsPerMinutePerProjectAwsUsEast1)	200 requêtes par minute et par projet	Votre projet Omni-région peut effectuer jusqu'à 200 requêtes par minute.

API Storage Read

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

Quota	ID de métrique et de quota	Par défaut	Remarques
Requêtes de lecture du plan de données par minute et par utilisateur	Métrique : bigquerystorage.googleapis.com/data_plane_requests ID de quota : DataPlaneRequestsPerMinutePerProjectPerUser	25 000 requêtes	Chaque utilisateur peut effectuer jusqu'à 25 000 appels ReadRows par minute et par projet.
Nombre maximal de connexions de lecture simultanées	Métriques : bigquerystorage.googleapis.com/read/max_concurrent_connections_us, bigquerystorage.googleapis.com/read/max_concurrent_connections_eu, bigquerystorage.googleapis.com/read/max_concurrent_connections_region ID de quota : MaxConcurrentReadConnectionsPerProjectUS, MaxConcurrentReadConnectionsPerProjectEU, MaxConcurrentReadConnectionsPerProjectRegion	2 000 dans les emplacements multirégionaux, 400 dans les régions	Nombre maximal de connexions ReadRows simultanées par projet. La valeur par défaut est de 2 000 connexions dans les emplacements multirégionaux us et eu, et de 400 connexions dans les autres régions. La disponibilité réelle de la connexion peut varier en fonction de la charge et de la demande globales du service à l'échelle de la région. Cet ajustement dynamique garantit une distribution équitable des ressources et maintient la stabilité du service pour tous les utilisateurs. Lorsqu'un flux est fermé pour des raisons d'équité ou lorsque vous atteignez la limite de connexion, vous recevez une erreur RESOURCE_EXHAUSTED (HTTP 429). Les demandes d'augmentation de quota sont examinées en fonction des habitudes d'utilisation passées du projet et de la disponibilité générale des ressources dans la région.
Requêtes de lecture du plan de contrôle par minute et par utilisateur	Métrique : bigquerystorage.googleapis.com/control_plane_requests ID de quota : ControlPlaneRequestsPerMinutePerProjectPerUser	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.

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

Limite système	Valeur	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.
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 Résoudre les problèmes liés au dépassement de ressources.

API Storage Write (gRPC)

Les quotas suivants s'appliquent aux requêtes de l'API Storage Write (gRPC) : 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.

Remarque : En raison de l'optimisation des performances, BigQuery peut signaler une utilisation du quota de connexions simultanées supérieure à l'utilisation réelle du quota. L'écart peut atteindre 1 % du quota total ou 100 connexions, selon la valeur la plus faible, multiplié par un facteur de 1 à 4. Cela signifie que l'utilisation signalée peut s'écarter d'au plus 400 connexions dans les emplacements multirégionaux avec un quota par défaut de 10 000, et de 40 connexions dans les petites régions avec un quota par défaut de 1 000. L'application des quotas est toujours basée sur l'utilisation réelle, et non sur la valeur signalée.

Si vous prévoyez de demander un ajustement de quota, incluez le message d'erreur dans votre demande pour accélérer le traitement. BigQuery peut réduire votre quota provisionné si celui-ci est largement sous-utilisé pendant plus d'un an.

Quota	ID de métrique et de quota	Par défaut	Remarques
Connexions d'écriture simultanées	Métriques : bigquerystorage.googleapis.com/write/max_active_streams, bigquerystorage.googleapis.com/write/max_active_streams_eu, bigquerystorage.googleapis.com/write/max_active_streams_region ID de quota : ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU, ConcurrentWriteConnectionsPerProjectRegion	5 000 dans une région ; 20 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 (gRPC), et non sur le projet contenant la ressource d'ensemble de données BigQuery. Le projet initiateur est le projet associé à la clé API ou au compte de service. Votre projet peut fonctionner sur 5 000 connexions simultanées dans une région ou 20 000 connexions simultanées dans les emplacements multirégionaux US et EU. Une connexion doit être de longue durée et utilisée pour envoyer autant de requêtes que possible. L'utilisation de connexions de courte durée est déconseillée et peut entraîner une utilisation excessive du quota de connexions simultanées. Pour la comptabilisation des quotas, nous vous suggérons une durée de vie de connexion d'au moins plusieurs minutes. Lorsque vous utilisez le flux par défaut en Java ou Go, nous vous recommandons d'utiliser le multiplexage de l'API Storage Write (gRPC) 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. 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 les autres régions, respectivement. Nous vous recommandons vivement de configurer des alertes pour surveiller l'utilisation et les limites de vos 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	Métriques : bigquerystorage.googleapis.com/write/append_bytes, bigquerystorage.googleapis.com/write/append_bytes_eu, bigquerystorage.googleapis.com/write/append_bytes_region ID de quota : AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU, AppendBytesThroughputPerProjectRegion	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. Vous pouvez afficher les métriques d'utilisation et de limites de quota pour 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 les 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 l'utilisation et les limites de vos 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.
CreateWriteStream requêtes	Métriques : bigquerystorage.googleapis.com/write/create_stream_requests, bigquerystorage.googleapis.com/write/create_stream_requests_eu, bigquerystorage.googleapis.com/write/create_stream_requests_region ID de quota : CreateWriteStreamRequestsPerMinutePerProject, CreateWriteStreamRequestsPerMinutePerProjectEU, CreateWriteStreamRequestsPerMinutePerProjectRegion	10 000 flux par heure, 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	Métriques : bigquerystorage.googleapis.com/write/pending_stream_bytes, bigquerystorage.googleapis.com/write/pending_stream_bytes_eu, bigquerystorage.googleapis.com/write/pending_stream_bytes_region ID de quota : PendingWriteStreamBytesPerProject, PendingWriteStreamBytesPerProjectEU, PendingWriteStreamBytesPerProjectRegion	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'existe aucun rapport sur ce quota.

Les limites système suivantes s'appliquent aux requêtes de l'API Storage Write (gRPC) :

Limite système	Valeur	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	20 Mo	La taille maximale de la requête est de 20 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'API BigQuery Storage Write (REST). 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, BigQuery renvoie une erreur quotaExceeded. BigQuery peut réduire votre quota provisionné si celui-ci est largement sous-utilisé pendant plus d'un an.

Quota	ID de métrique et de quota	Par défaut	Remarques
Nombre maximal d'octets par seconde et par projet dans les emplacements multirégionaux us et eu	Métriques : bigquery.googleapis.com/quota/streaming/insert_bytes_us, bigquery.googleapis.com/quota/streaming/insert_bytes_eu ID de quota : StreamingInsertBytesPerSecondUs, StreamingInsertBytesPerSecondEu	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	Métrique : bigquery.googleapis.com/quota/streaming/insert_bytes ID de quota : StreamingInsertBytesPerSecond	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.

Les limites système suivantes s'appliquent lorsque vous diffusez des données en streaming dans BigQuery à l'aide de l'API BigQuery Storage Write (REST) :

Limite système	Valeur	Remarques
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 du format HTTP JSON vers une structure de données interne. La structure de données traduite applique sa propre limite de taille. Il est difficile de prévoir la taille de la structure de données interne qui en résulte, mais si vous limitez vos requêtes HTTP à 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.

Bande passante

Les quotas suivants s'appliquent à la bande passante de la réplication d'ensembles de données interrégionaux :

Quota	Par défaut	Remarques
Bande passante maximale de réplication interrégionale d'ensembles de données pour le backfill initial pour chaque région ayant une sortie de données interrégionale de l'instance répliquée principale vers les instances répliquées secondaires.	10 Gio/s physiques par région et par organisation
Bande passante maximale de réplication interrégionale d'ensembles de données pour chaque région ayant une sortie de données interrégionale de l'instance répliquée principale vers les instances répliquées secondaires.	5 Gio/s physiques par région et par organisation
Bande passante maximale de réplication turbo interrégionale d'ensembles de données pour chaque région ayant une sortie de données interrégionale de l'instance répliquée principale vers les instances répliquées secondaires.	5 Gio/s physiques par région et par organisation	Le quota de bande passante de la réplication turbo interrégionale d'ensembles de données ne s'applique pas à l'opération de remplissage initial.

Lorsque la bande passante de réplication d'ensembles de données interrégionaux d'un projet dépasse un certain quota, la réplication d'ensembles de données interrégionaux à partir des projets concernés peut s'arrêter avec l'erreur rateLimitExceeded, qui inclut les détails du quota dépassé.

Les quotas suivants s'appliquent à la bande passante de copie de table interrégionale :

Quota	Par défaut	Remarques
Bande passante de copie maximale pour chaque région ayant une sortie de données interrégionale de la table source vers la table de destination.	2 Gio/s physiques par paire de régions et par organisation.