Cotas e limites

Neste documento, listamos as cotas e limites que se aplicam ao BigQuery.

Uma cota restringe quanto de um determinado recurso compartilhado do Google Cloud o projeto do Google Cloud pode usar, incluindo hardware, software e componentes de rede. Dessa forma, as cotas fazem parte de um sistema que:

  • monitora o uso ou o consumo de produtos e serviços do Google Cloud;
  • restringe o consumo desses recursos por motivos, que garantem imparcialidade e reduzem picos de uso;
  • mantém as configurações que aplicam automaticamente restrições prescritas;
  • fornece um meio de solicitar ou faz alterações na cota.

Na maioria dos casos, quando uma cota é excedida, o sistema bloqueia imediatamente o acesso ao recurso relevante do Google. Além disso, a tarefa que você está tentando executar falha. Na maioria dos casos, as cotas se aplicam a todos os projetos do Google Cloud. Além disso, elas são compartilhadas entre todos os aplicativos e endereços IP que usam esse projeto.

Também há limites nos recursos do BigQuery. Esses limites não estão relacionados ao sistema de cotas. Não é possível mudar os limites, a menos que seja indicado o contrário.

Por padrão, as cotas e limites do BigQuery são aplicados por projeto. As cotas e os limites aplicáveis de maneira diferente são indicados como tal. por exemplo, o número máximo de colunas por tabela ou o número máximo de solicitações de API simultâneas por usuário. As políticas específicas variam de acordo com a disponibilidade do recurso, o perfil do usuário, o histórico de uso do serviço e outros fatores, e estão sujeitas a alterações sem aviso prévio.

Reposição de cota

As cotas diárias são reabastecidas em intervalos regulares ao longo do dia, refletindo a intenção de orientar comportamentos que limitem a taxa. A atualização intermitente também é feita para evitar interrupções longas quando a cota estiver esgotada. As cotas são geralmente renovadas em questão de minutos, em vez de restauradas de maneira integral uma vez ao dia.

Solicitar aumento de cota

Para aumentar ou diminuir a maioria das cotas, use o console do Google Cloud. Para mais informações, consulte Solicitar uma cota maior.

Para ver instruções passo a passo sobre o processo de solicitação de aumento de cota no console do Google Cloud, clique em Orientações:

Orientações

Limitar uso de cotas

Para saber como limitar o uso de um recurso específico especificando uma cota menor que a padrão, consulte Como limitar o uso.

Permissões necessárias

Para visualizar e atualizar suas cotas do BigQuery no console do Google Cloud, você precisa das mesmas permissões que qualquer cota do Google Cloud. Para mais informações, consulte Permissões de cota do Google Cloud.

Resolver problemas

Para ver informações sobre como solucionar erros relacionados a cotas e limites, consulte Como solucionar problemas de erros de cota no BigQuery.

Jobs

As cotas e limites se aplicam aos jobs que o BigQuery executa em seu nome, seja usando o console do Google Cloud, a ferramenta de linha de comando bq, de forma programática usando a API REST ou as bibliotecas de cliente.

Jobs de consulta

As cotas a seguir se aplicam a jobs de consulta criados automaticamente com a execução de consultas interativas, consultas programadas e jobs enviados usando o jobs.query e o tipo de consulta jobs.insertmétodos de API:

Cota Padrão Observações
Uso de consultas por dia Ilimitado Não há limite para o número de bytes que podem ser processados por consultas em um projeto.
Veja a cota no Console do Google Cloud
Uso de consultas por dia por usuário Ilimitado Não há limite para o número de bytes que as consultas de um usuário podem processar por dia.
Veja a cota no Console do Google Cloud
Bytes por região entre consultas federadas do Cloud SQL por dia 1 TB Se o local de processamento da consulta do BigQuery e o local da instância do Cloud SQL forem diferentes, a consulta será entre regiões. Seu projeto pode executar até 1 TB em consultas entre regiões por dia. Veja as consultas federadas do Cloud SQL.
Veja a cota no Console do Google Cloud
Bytes transferidos por entre nuvens por dia 1 TB É possível transferir até 1 TB de dados por dia de um bucket do Amazon S3 ou do Armazenamento de Blob do Azure. Para mais informações, consulte Transferência entre nuvens do Amazon S3 e Azure.
Veja a cota no console do Google Cloud

Os limites a seguir se aplicam a jobs de consulta criados automaticamente com a execução de consultas interativas, consultas programadas e jobs enviados com os tipos de jobs.query e Métodos de API jobs.insert:

Limite Padrão Observações
Número máximo de consultas interativas na fila 1.000 consultas É possível colocar até 1.000 consultas interativas no seu projeto. Outras consultas interativas que excedem esse limite retornam um erro de cota.
Número máximo de consultas em lote na fila 20.000 consultas Seu projeto pode enfileirar até 20.000 consultas em lote. Outras consultas em lote que excedem esse limite retornam um erro de cota.
Número máximo de consultas interativas simultâneas nas fontes de dados externas do Bigtable 16 consultas O projeto pode executar até dezesseis consultas simultâneas em uma fonte de dados externa do Bigtable.
Número máximo de consultas simultâneas que contêm funções remotas 10 consultas Você pode executar até 10 consultas simultâneas com funções remotas por projeto.
Número máximo de consultas de múltiplas instruções simultâneas 1.000 consultas com várias instruções Seu projeto pode executar até 1.000 consultas com várias instruções simultâneas. Para outras cotas e limites relacionados a consultas com várias instruções, acesse este link.
Número máximo de consultas SQL legadas simultâneas que contêm UDFs 6 consultas O projeto pode executar até seis consultas SQL legadas simultâneas com funções definidas pelo usuário (UDFs). Esse limite inclui consultas interativas e em lote. Consultas interativas que contêm UDFs também são consideradas em relação ao limite simultâneo para consultas interativas. Esse limite não se aplica a consultas do GoogleSQL.
Limite diário do tamanho da consulta Ilimitado Por padrão, não há limite de tamanho de consulta diário. No entanto, é possível definir limites na quantidade de dados que os usuários podem consultar criando cotas personalizadas para controlar o uso de consulta por dia ou uso de consulta por dia por usuário.
Limite diário de atualização da tabela de destino Consulte o Número máximo de operações de tabela por dia. As atualizações nas tabelas de destino em um job de consulta são contabilizadas no limite do número máximo de operações de tabela por dia para as tabelas de destino. As atualizações da tabela de destino incluem operações de anexação e substituição, feitas por consultas executadas usando o console do Google Cloud, usando a ferramenta de linha de comando bq ou chamando o método jobs.query e métodos de API jobs.insert do tipo de consulta.
Limite de tempo de execução de consulta de várias instruções 6 horas

Uma consulta ou consulta de várias instruções pode ser executada por até seis horas e, em seguida, falha. No entanto, às vezes as consultas são repetidas. Uma consulta pode ser executada até três vezes, e cada tentativa pode ser executada por até seis horas. Dessa forma, é possível que uma consulta tenha um tempo de execução total de mais de seis horas.

O tempo limite padrão do job CREATE MODEL é de 24 horas, com exceção dos jobs de série temporal, AutoML e ajuste de hiperparâmetros, com um tempo limite de 72 horas.

Número máximo de recursos referenciados por consulta 1.000 recursos Uma consulta pode fazer referência a um total de até 1.000 tabelas, visualizações únicas, funções definidas pelo usuário (UDFs) únicas e funções com valor de tabela (TVFs) únicas após a expansão completa. Este limite inclui o seguinte:
  • Tabelas, visualizações, UDFs e funções de tabela referenciadas diretamente pela consulta.
  • Tabelas, visualizações, UDFs e funções de tabela referenciadas por outras funções de visualização/UDFs/tabela referenciadas na consulta.
Tamanho máximo de consulta de SQL legado não resolvido 256 KB Uma consulta de SQL legado não resolvida pode ter até 256 KB de comprimento. Se a consulta for mais longa, você receberá o seguinte erro: The query is too large. para permanecer dentro desse limite, substitua grandes matrizes ou listas por parâmetros de consulta.
Tamanho máximo não resolvido da consulta do GoogleSQL 1 MB Uma consulta não resolvida do GoogleSQL pode ter até 1 MB. Se a consulta for mais longa, você receberá o seguinte erro: The query is too large. para permanecer dentro desse limite, considere substituir grandes matrizes ou listas por parâmetros de consulta.
Tamanho máximo de uma consulta legada e do GoogleSQL resolvida 12 MB O limite no tamanho da consulta resolvida inclui o tamanho de todas as visualizações e tabelas curinga referenciadas pela consulta.
Número máximo de parâmetros de consulta do GoogleSQL 10.000 parâmetros Uma consulta GoogleSQL pode ter até 10.000 parâmetros.
Tamanho máximo da solicitação 10 MB O tamanho da solicitação pode ser de até 10 MB, incluindo propriedades extras, como parâmetros de consulta.
Tamanho máximo de resposta 10 GB compactados Os tamanhos variam de acordo com as taxas de compactação dos dados. O tamanho real da resposta pode ser significativamente superior a 10 GB. O tamanho máximo da resposta é ilimitado ao gravar grandes resultados de consultas em uma tabela de destino.
Tamanho máximo da linha 100 MB O tamanho máximo da linha é aproximado, porque o limite é baseado na representação interna dos dados da linha. Esse limite é aplicado durante determinados estágios da execução do job de consulta.
Máximo de colunas em uma tabela, um resultado de consulta ou uma definição de visualização 10.000 colunas Uma definição de tabela, resultado da consulta ou visualização pode ter até 10.000 colunas.
Máximo de slots simultâneos para preços sob demanda 2.000 slots Com o preço sob demanda, seu projeto pode ter até 2.000 slots simultâneos. Os slots do BigQuery são compartilhados entre todas as consultas em um único projeto. É possível que o BigQuery vá além desse limite para acelerar suas consultas. Para verificar quantos slots você está usando, consulte Como monitorar o BigQuery usando o Cloud Monitoring.
Uso máximo da CPU por dados verificados para preços sob demanda 256 segundos de CPU por MiB verificado Com os preços sob demanda, sua consulta pode usar até aproximadamente 256 segundos de CPU por MiB de dados verificados. Se a consulta consumir muita CPU para a quantidade de dados processados, ela falhará com um erro billingTierLimitExceeded. Para mais informações, consulte billingTierLimitExceeded.
Mutações em tabelas de transações de várias instruções 100 Tabelas Uma transação pode modificar os dados em, no máximo, 100 tabelas.
Modificações da partição de transações de várias instruções 100.000 modificações de partição Uma transação pode executar no máximo 100.000 modificações de partição.
Tamanho máximo do resultado da consulta do BigQuery Omni 20 GiB descompactados O tamanho máximo do resultado é 20 GiB de bytes lógicos ao consultar dados do Azure ou da AWS. Se o resultado da consulta for maior que 20 GiB, exporte os resultados para o Amazon S3 ou o Blob Storage. Para mais informações, consulte as limitações do BigQuery Omni.
Tamanho total do resultado da consulta do BigQuery Omni por dia 1 TB Os tamanhos totais dos resultados da consulta de um projeto são de 1 TB por dia. Para mais informações, consulte as limitações do BigQuery Omni.
Tamanho máximo da linha do BigQuery Omni 10 MiB O tamanho máximo da linha é de 10 MiB ao consultar dados do Azure ou da AWS. Para mais informações, consulte as limitações do BigQuery Omni.

As consultas programadas usam recursos do serviço de transferência de dados do BigQuery, mas não são transferências e não estão sujeitas a limites de job de carregamento.

Jobs de exportação

Confira a seguir os limites aplicados a jobs que exportam dados do BigQuery utilizando a ferramenta de linha de comando bq, o console do Google Cloud ou o método da API jobs.insert de tipo de exportação.

Limite Padrão Observações
Número máximo de bytes exportados por dia 50 TB É possível exportar até 50 TB (Tebibytes) de dados por dia de um projeto gratuitamente usando o pool de slots compartilhado. É possível configurar uma política de alertas do Cloud Monitoring que fornece notificações do número de bytes exportados. Para exportar mais de 50 TB (Tebibytes) de dados por dia, siga um destes procedimentos:
Número máximo de jobs de exportação por dia 100.000 exportações É possível executar até 100.000 exportações por dia em um projeto. Para executar mais de 100.000 exportações por dia, realize uma das seguintes ações:
Tamanho máximo da tabela exportado para um único arquivo 1 GB É possível exportar até 1 GB de dados da tabela para um único arquivo. Para exportar mais de 1 GB de dados, use um caractere curinga para exportar os dados para vários arquivos. Quando você exporta dados para vários arquivos, o tamanho deles varia. Em alguns casos, o tamanho dos arquivos de saída é maior que 1 GB.
URIs curinga por exportação 500 URIs Uma exportação pode ter até 500 URIs curinga.

Para saber mais sobre o uso atual do job de exportação, consulte Ver o uso de cota atual.

Jobs de carregamento

Os limites a seguir se aplicam ao carregar dados no BigQuery, usando o console do Google Cloud, a ferramenta de linha de comando bq ou o método de API jobs.insert de tipo de carga.

Limite Padrão Observações
Carregar jobs por tabela por dia 1.500 jobs Os jobs de carregamento, incluindo os com falha, contam para o limite no número máximo de operações de tabela por dia para a tabela de destino. Para informações sobre os limites de número de operações de tabela por dia para tabelas padrão e particionadas, consulte Tabelas.
Carregar jobs por dia 100.000 jobs O projeto pode executar até 100.000 jobs de carregamento por dia. Os jobs de carregamento com falha são contabilizados nesse limite.
Máximo de colunas por tabela 10.000 colunas Uma tabela pode ter até 10.000 colunas.
Tamanho máximo por job de carregamento 15 TB O tamanho total de todos os seus arquivos de entrada CSV, JSON, Avro, Parquet e ORC pode ser de até 15 TB.
Número máximo de URIs de origem na configuração do job 10.000 URIs Uma configuração de job pode ter até 10.000 URIs de origem.
Número máximo de arquivos por job de carga 10.000.000 arquivos Um job de carregamento pode ter até 10 milhões de arquivos no total, incluindo todos os arquivos correspondentes a todos os URIs curinga.
Número máximo de arquivos no bucket de origem do Cloud Storage Aproximadamente 60.000.000 arquivos Um job de carregamento pode ler em um bucket do Cloud Storage que contenha até aproximadamente 60.000.000 arquivos.
Limite de tempo de execução do job de carregamento 6 horas Um job de carregamento falhará se for executado por mais de seis horas.
Avro: tamanho máximo dos blocos de dados do arquivo 16 MB O limite de tamanho para blocos de dados de arquivo Avro é de 16 MB.
CSV: tamanho máximo de células 100 MB As células CSV podem ter até 100 MB de tamanho.
CSV: tamanho máximo da linha 100 MB As linhas CSV podem ter até 100 MB.
CSV: tamanho máximo de arquivo - compactado 4 GB O limite de tamanho para um arquivo CSV compactado é de 4 GB.
CSV: tamanho máximo de arquivo, não compactado 5 TB O limite de tamanho para um arquivo CSV não compactado é de 5 TB.
JSON: tamanho máximo de linha 100 MB As linhas JSON podem ter até 100 MB de tamanho.
JSON: tamanho máximo de arquivo compactado 4 GB O limite de tamanho para um arquivo JSON compactado é de 4 GB.
JSON: tamanho máximo de arquivo, não compactado 5 TB O limite de tamanho para um arquivo JSON descompactado é de 5 TB.

Se você exceder os limites de jobs de carregamento regularmente devido a atualizações frequentes, considere usar dados de streaming no BigQuery.

Para informações sobre como ver o uso atual do job de carregamento, consulte Ver o uso atual da cota.

Considerações sobre a cota de job de carregamento do serviço de transferência de dados do BigQuery

Os jobs de carregamento criados por transferências do serviço de transferência de dados do BigQuery são incluídos nas cotas do BigQuery em jobs de carregamento. É importante pensar em quantas transferências ativar em cada projeto para evitar erros quotaExceeded provocados por transferências e outros jobs de carregamento.

É possível usar a seguinte equação para calcular quantos jobs de carregamento são necessários para as transferências:

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

Em que:

  • Number of transfers é o número de configurações de transferência que você quer ativar no projeto;
  • Number of tables é a quantidade de tabelas criadas por cada tipo específico de transferência; O número de tabelas varia de acordo com o tipo de transferência:

    • As transferências do Campaign Manager criam aproximadamente 25 tabelas.
    • As transferências do Google Ads criam aproximadamente 60 tabelas.
    • As transferências do Google Ad Manager criam aproximadamente 40 tabelas.
    • As transferências do Google Play criam aproximadamente 25 tabelas.
    • As transferências do Search Ads 360 criam aproximadamente 50 tabelas.
    • As transferências do YouTube criam aproximadamente 50 tabelas.
  • Schedule frequency descreve com que frequência a transferência é executada. Há programações de execução de transferência para cada tipo de transferência:

  • Refresh window é o número de dias a serem incluídos na transferência de dados. Se você inserir 1, não haverá preenchimento diário.

Jobs de cópia

Os limites a seguir se aplicam a jobs do BigQuery para copiar tabelas, incluindo jobs que criam cópias, clones ou snapshots de tabelas padrão, clones de tabelas ou snapshots de tabelas. Os limites se aplicam a jobs criados usando o console do Google Cloud, a ferramenta de linha de comando bq ou o método jobs.insert do tipo de cópia. Os jobs de cópia são contabilizados nesses limites, independentemente de sucesso ou falha.

Limite Padrão Observações
Jobs de cópia por tabela de destino/dia Consulte Operações de tabela por dia.
Jobs de cópia por dia 100.000 jobs É possível executar até 100.000 jobs de cópia por dia no projeto.
Jobs de cópia entre regiões por tabela de destino/dia 100 jobs Seu projeto pode executar até 100 jobs de cópia entre regiões para uma tabela de destino por dia.
Jobs de cópia entre regiões por dia 2.000 jobs É possível executar até 2.000 jobs de cópia entre regiões por dia.
Número de tabelas de origem para copiar 1.200 tabelas de origem É possível copiar de até 1.200 tabelas de origem por job de cópia.

Para informações sobre a visualização do uso atual do job de cópia, consulte Jobs de cópia: consultar uso atual da cota.

Veja a seguir os limites aplicados à cópia de conjuntos de dados:

Limite Padrão Observações
Número máximo de tabelas no conjunto de dados de origem 20.000 tabelas Um conjunto de dados de origem pode ter até 20.000 tabelas.
Número máximo de tabelas que podem ser copiadas por execução em um conjunto de dados de destino na mesma região 20.000 tabelas O projeto pode copiar 20.000 tabelas por execução em um conjunto de dados de destino que esteja na mesma região.
Número máximo de tabelas que podem ser copiadas por execução em um conjunto de dados de destino em uma região diferente 1.000 tabelas O projeto pode copiar 1.000 tabelas por execução para um conjunto de dados de destino que está em uma região diferente. Por exemplo, se você configurar uma cópia entre regiões de um conjunto de dados com 8.000 tabelas, o serviço de transferência de dados do BigQuery criará automaticamente oito execuções de maneira sequencial. A primeira execução copia 1.000 tabelas. Vinte e quatro horas depois, a segunda execução copia 1.000 tabelas. Esse processo continua até que todas as tabelas no conjunto de dados sejam copiadas, até o máximo de 20.000 tabelas por conjunto de dados.

Reservas

As cotas a seguir se aplicam às reservas:

Cota Padrão Observações
Número total de slots na região da UE 5.000 slots O número máximo de slots do BigQuery que podem ser adquiridos na multirregião UE usando o console do Google Cloud.
Veja as cotas no console do Google Cloud
Número total de slots para a região dos EUA 10.000 slots O número máximo de slots do BigQuery que é possível comprar na multirregião EUA usando o console do Google Cloud.
Veja as cotas no console do Google Cloud
Número total de slots para a região us-east1 4.000 slots O número máximo de slots do BigQuery que é possível comprar na região listada usando o console do Google Cloud.
Veja as cotas no console do Google Cloud
Número total de slots para as seguintes regiões:
  • asia-south1
  • asia-southeast1
  • europe-west2
  • us-central1
  • us-west1
2.000 slots O número máximo de slots do BigQuery que é possível comprar em cada uma das regiões listadas usando o console do Google Cloud.
Veja as cotas no console do Google Cloud
Número total de slots para as seguintes regiões:
  • asia-east1
  • asia-northeast1
  • asia-northeast3
  • asia-southeast2
  • australia-southeast1
  • europe-north1
  • europe-west1
  • europe-west3
  • europe-west4
  • northamerica-northeast1
  • us-east4
  • southamerica-east1
1.000 slots O número máximo de slots do BigQuery que é possível comprar em cada uma das regiões listadas usando o Console do Google Cloud.
Veja as cotas no console do Google Cloud
Número total de slots para regiões do BigQuery Omni 100 slots O número máximo de slots do BigQuery que podem ser comprados nas regiões do BigQuery Omni com o console do Google Cloud.
Confira as cotas no console do Google Cloud
Número total de slots para todas as outras regiões. 500 slots O número máximo de slots do BigQuery que podem ser comprados em cada região usando o Console do Google Cloud.
Veja as cotas no console do Google Cloud

Os limites a seguir se aplicam a reservas:

Limite Valor Observações
Número de projetos de administração para reservas de slots 5 projetos por organização O número máximo de projetos em uma organização que podem conter uma reserva ou um compromisso ativo para slots para um determinado local/ região.
Número máximo de reservas da edição padrão 10 reservas por projeto O número máximo de reservas da edição padrão por projeto de administração em uma organização para um determinado local/região.
Número máximo de reservas da edição Enterprise ou Enterprise Plus 200 reservas por projeto O número máximo de reservas da edição Enterprise ou Enterprise Plus por projeto de administração em uma organização para um determinado local/região.

Conjuntos de dados

Os limites a seguir se aplicam aos conjuntos de dados do BigQuery.

Limite Padrão Observações
Número máximo de conjuntos de dados Ilimitado Não há limite no número de conjuntos de dados que um projeto pode ter.
Número de tabelas por conjunto de dados Ilimitado Ao usar uma chamada de API, o desempenho da enumeração fica lento quando você se aproxima de 50.000 tabelas em um conjunto de dados. O console do Google Cloud pode exibir até 50.000 tabelas para cada conjunto de dados.
Número de recursos autorizados na lista de controle de acesso de um conjunto de dados 2500 Recursos A lista de controle de acesso de um conjunto de dados pode ter até 2.500 recursos autorizados, incluindo visualizações autorizadas, conjuntos de dados autorizados e funções autorizadas. Se você exceder esse limite devido a um grande número de visualizações autorizadas, considere agrupar as visualizações em conjuntos de dados autorizados.
Número de operações de atualização de conjunto de dados por conjunto de dados a cada 10 segundos 5 operações Seu projeto pode realizar até cinco operações de atualização de conjunto de dados a cada 10 segundos. O limite de atualização do conjunto de dados inclui todas as operações de atualização de metadados realizadas por:
Comprimento máximo de uma descrição de conjunto de dados 16.384 caracteres Ao adicionar uma descrição a um conjunto de dados, o texto pode ter no máximo 16.384 caracteres.

Tabelas

Todas as tabelas

Os limites a seguir se aplicam a todas as tabelas do BigQuery.

Limite Padrão Observações
Tamanho máximo de um nome de coluna 300 caracteres O nome da coluna pode ter no máximo 300 caracteres.
Comprimento máximo de uma descrição de coluna 1.024 caracteres Ao adicionar uma descrição a uma coluna, o texto pode ter no máximo 1.024 caracteres.
Profundidade máxima de registros aninhados: 15 níveis Colunas do tipo RECORD podem conter tipos RECORD aninhados, também chamados de registros filhos. O limite máximo de profundidade aninhado é de 15 níveis. Esse limite não depende do fato que os registros sejam escalares ou baseados em matrizes (repetidos).

Tabelas padrão

Os limites a seguir se aplicam às tabelas padrão (integradas) do BigQuery:

Limite Padrão Observações
Modificações da tabela por dia 1.500 modificações

Seu projeto pode fazer até 1.500 modificações por tabela por dia, seja para anexar dados, atualizar dados ou truncar a tabela. Esse limite não pode ser alterado e inclui o total combinado de todas carregar jobs .copiar jobs e jobs de consulta que anexam ou substituem uma tabela de destino.

As instruções DML não são contabilizadas no número de modificações de tabela por dia.

Taxa máxima de operações de atualização de metadados de tabela por tabela 5 operações por 10 segundos Seu projeto pode fazer até cinco operações de atualização de metadados de tabela a cada 10 segundos por tabela. Esse limite se aplica a todas as operações de atualização de metadados da tabela, realizadas ao: Esse limite inclui o total combinado de todos os jobs de carregamento, jobs de cópia e jobs de consulta que anexam ou substituem uma tabela de destino ou que usam a instrução DML DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE para gravar dados em uma tabela. Observe que, embora as instruções DML sejam contabilizadas nesse limite, elas não estarão sujeitas a ele se ele for atingido. As operações DML têm limites de taxa dedicados.

Se você exceder esse limite, receberá uma mensagem de erro como Exceeded rate limits: too many table update operations for this table. Esse erro é transitório; tente novamente com uma espera exponencial.

Para identificar as operações que contam para esse limite, é possível inspecionar seus registros. Consulte Resolver erros de cota para saber como diagnosticar e resolver esse erro.

Número máximo de colunas por tabela 10.000 colunas Cada definição de tabela, resultado da consulta ou visualização pode ter até 10.000 colunas.

Tabelas externas

Os limites a seguir se aplicam a tabelas com dados armazenados no Cloud Storage em formato Parquet, ORC, Avro, CSV ou JSON.

Limite Padrão Observações
Número máximo de URIs de origem por tabela externa 10.000 URIs Cada tabela externa pode ter até 10.000 URIs de origem.
Número máximo de arquivos por tabela externa 10.000.000 arquivos Uma tabela externa pode ter até 10 milhões de arquivos, incluindo todos os arquivos correspondentes a todos os URIs curinga.
Tamanho máximo de dados armazenados no Cloud Storage por tabela externa 600 TB Uma tabela externa pode ter até 600 terabytes em todos os arquivos de entrada. Esse limite se aplica aos tamanhos dos arquivos, conforme armazenados no Cloud Storage. esse tamanho não é o mesmo usado na fórmula de preço de consulta. Para tabelas particionadas externamente, o limite é aplicado depois da remoção de partições.
Número máximo de arquivos no bucket de origem do Cloud Storage Aproximadamente 60.000.000 arquivos Uma tabela externa pode fazer referência a um bucket do Cloud Storage que contém até aproximadamente 60.000.000 arquivos. Para tabelas particionadas externamente, esse limite é aplicado antes da remoção de partição.

Tabelas particionadas

Os limites a seguir se aplicam às tabelas particionadas do BigQuery.

Os limites de partição se aplicam ao total combinado de todos os jobs de carregamento, jobs de cópia e jobs de consulta que anexam ou substituem uma partição de destino.

Um único job pode afetar várias partições. Por exemplo, jobs de consulta e jobs de carregamento podem gravar em várias partições.

O BigQuery usa o número de partições afetadas por um job ao determinar a quantidade da cota consumida pelo job. As inserções de streaming não afetam essa cota.

Para informações sobre estratégias para permanecer dentro dos limites de tabelas particionadas, consulte Solução de problemas de erros de cota.

Limite Padrão Observações
Número de partições por tabela particionada 4.000 partições Cada tabela particionada pode ter até 4.000 partições. Se você exceder esse limite, use o clustering além do particionamento ou em vez dele.
Número de partições modificadas por um único job 4.000 partições Cada operação de job (consulta ou carregamento) pode afetar até 4.000 partições. O BigQuery rejeita qualquer job de consulta ou de carregamento que tente modificar mais de 4.000 partições.
Número de modificações de partições por tabela particionada por tempo de processamento por dia 5.000 modificações.

Seu projeto pode fazer até 5.000 modificações de partição por dia, seja para anexar dados, atualizar dados ou truncar uma tabela particionada por tempo de ingestão.

As instruções DML não são contabilizadas no número de modificações de partição por dia.

Número de modificações de partições por tabela particionada por coluna por dia 30.000 modificações.

O projeto pode fazer até 30 mil modificações de partições por dia em uma tabela particionada por coluna.

As instruções DML não são contabilizadas no número de modificações de partição por dia.

Taxa máxima de operações de atualização de metadados de tabela por tabela particionada 50 modificações a cada 10 segundos Seu projeto pode criar até 50 modificações por tabela particionada a cada 10 segundos. Esse limite se aplica a todas as operações de atualização de metadados da tabela particionada, realizadas ao: Esse limite inclui o total combinado de todos os jobs de carregamento, jobs de cópia e jobs de consulta tqu anexam ou substituem uma tabela de destino ou que usam a instrução DML DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE para gravar dados em uma tabela.

Se você exceder esse limite, receberá uma mensagem de erro como Exceeded rate limits: too many partitioned table update operations for this table. Esse erro é transitório; tente novamente com uma espera exponencial.

Para identificar as operações que contam para esse limite, é possível inspecionar seus registros.

Número de intervalos possíveis para particionamento de intervalo 10.000 intervalos Uma tabela particionada por intervalo pode ter até 10.000 intervalos possíveis. Esse limite se aplica à especificação de partição durante a criação da tabela. Depois de criar a tabela, o limite também se aplica ao número real de partições.

Clones de tabelas

Os limites a seguir se aplicam aos clones da tabela do BigQuery:

Limite Padrão Observações
Número máximo de clones e snapshots em uma cadeia Três clones de tabela ou snapshots Os clones e snapshots combinados são limitados a uma profundidade de três. Ao clonar ou criar um snapshot de uma tabela base, é possível clonar ou criar um snapshot do resultado apenas mais duas vezes. A tentativa de clonar ou criar um snapshot do resultado uma terceira vez resulta em um erro. Por exemplo, é possível criar o clone A da tabela base, criar o snapshot B do clone A e o clone C do snapshot B. Para fazer mais cópias do clone ou do snapshot de terceiro nível, use uma operação de cópia.
Número máximo de clones e snapshots de uma tabela base Mil snapshots ou clones de tabelas Não é possível ter mais de 1.000 clones e snapshots combinados com uma determinada tabela base. Por exemplo, se você tiver 600 snapshots e 400 clones, atingirá o limite.

Snapshots da tabela

Os limites a seguir se aplicam aos instantâneos da tabela do BigQuery:

Limite Padrão Observações
Número máximo de jobs de snapshots da tabela simultâneos: 100 jobs O projeto pode executar até 100 jobs de snapshots de tabela simultâneos.
Número máximo de jobs de snapshots da tabela por dia: 50.000 jobs O projeto pode executar até 50.000 jobs de snapshots de tabela por dia.
Número máximo de jobs de snapshot de tabela por tabela por dia 50 jobs Seu projeto pode executar até 50 jobs de snapshot de tabela por tabela por dia.
Número máximo de atualizações de metadados por snapshot da tabela a cada 10 segundos: 5 atualizações O projeto pode atualizar os metadados de um snapshot de tabela até cinco vezes a cada 10 segundos.
Número máximo de clones e snapshots em uma cadeia Três clones de tabela ou snapshots Os clones e snapshots combinados são limitados a uma profundidade de três. Ao clonar ou criar um snapshot de uma tabela base, é possível clonar ou criar um snapshot do resultado apenas mais duas vezes. A tentativa de clonar ou criar um snapshot do resultado uma terceira vez resulta em um erro. Por exemplo, é possível criar o clone A da tabela base, criar o snapshot B do clone A e o clone C do snapshot B. Para fazer mais cópias do clone ou do snapshot de terceiro nível, use uma operação de cópia.
Número máximo de clones e snapshots de uma tabela base Mil snapshots ou clones de tabelas Não é possível ter mais de 1.000 clones e snapshots combinados com uma determinada tabela base. Por exemplo, se você tiver 600 snapshots e 400 clones, atingirá o limite.

Visualizações

As cotas e limites a seguir se aplicam às visualizações e às visualizações materializadas.

Visualizações lógicas

Os limites a seguir se aplicam às visualizações padrão do BigQuery.

Limite Padrão Observações
Número máximo de níveis de visualização aninhados: 16 tiers O BigQuery é compatível com até 16 níveis de visualizações aninhadas. Se houver mais de 16 níveis, será retornado um erro INVALID_INPUT.
Tamanho máximo de uma consulta do GoogleSQL usada para definir uma visualização 256 mil caracteres Uma única consulta do GoogleSQL que define uma visualização pode ter até 256 mil caracteres. Esse limite se aplica a uma única consulta e não inclui o comprimento das visualizações referenciadas na consulta.
Número máximo de visualizações autorizadas por conjunto de dados: Consulte Conjunto de dados.

Visualizações materializadas

Os limites a seguir se aplicam às visualizações materializadas do BigQuery:

Limite Padrão Observações
Referências da tabela base (mesmo conjunto de dados) 20 visualizações materializadas Cada tabela base pode ser referenciada por até 20 visualizações materializadas do mesmo conjunto de dados.
Referências da tabela base (mesmo projeto) 100 visualizações materializadas Cada tabela base pode ser referenciada por até 100 visualizações materializadas do mesmo projeto.
Referências da tabelas base (toda a organização) 500 visualizações materializadas Cada tabela base pode ser referenciada por até 500 visualizações materializadas de toda a organização.
Número máximo de visualizações autorizadas por conjunto de dados: Consulte Conjunto de dados.

Índices da Pesquisa

Os limites a seguir se aplicam aos índices de pesquisa do BigQuery:

Limite Padrão Observações
Número de instruções DDL CREATE INDEX por projeto, região e dia 500 operações O projeto pode emitir até 500 operações DDL CREATE INDEX por dia em uma região.
Número de instruções DDL de índice de pesquisa por tabela por dia 20 operações O projeto pode emitir até 20 operações DDL CREATE INDEX ou DROP INDEX por tabela por dia.
Tamanho total máximo dos dados da tabela por organização com permissão para a criação de índices de pesquisa que não são executados em uma reserva 100 TB em multirregiões; 20 TB em todas as outras regiões Você poderá criar um índice de pesquisa para uma tabela se o tamanho geral das tabelas com índices na sua organização estiver abaixo do limite da sua região: 100 TB para as multirregiões US e EU e 20 TB para todas as outras regiões. Se os jobs de gerenciamento de índices forem executados na sua reserva, esse limite não será aplicado.

Índices vetoriais

Os limites a seguir se aplicam aos índices vetoriais do BigQuery:

Limite Padrão Observações
Número mínimo de linhas da tabela base 5.000 linhas Uma tabela precisa ter pelo menos 5.000 linhas para criar um índice de vetor.
Número máximo de linhas da tabela base 1.000.000.000 linhas Uma tabela pode ter no máximo 1.000.000.000 de linhas para criar um índice de vetor.
Tamanho máximo da matriz na coluna indexada 1.000 elementos A coluna a ser indexada pode ter no máximo 1.000 elementos na matriz.
Tamanho mínimo da tabela para preenchimento do índice de vetor 10 MB Se você criar um índice de vetor em uma tabela com menos de 10 MB, ele não será preenchido. Da mesma forma, se você excluir dados de uma tabela indexada por vetor de maneira que o tamanho dela seja menor que 10 MB, o índice de vetor será desativado temporariamente. Isso acontece independente de você usar ou não sua própria reserva para os jobs de gerenciamento de índices. Quando o tamanho de uma tabela indexada por vetor excede novamente 10 MB, o índice é preenchido automaticamente.
Número de instruções DDL CREATE VECTOR INDEX por projeto, região e dia 500 operações Para cada projeto, é possível emitir até 500 operações CREATE VECTOR INDEX por dia para cada região.
Número de instruções DDL de índice do vetor por tabela por dia 10 operações É possível emitir até 10 operações CREATE VECTOR INDEX ou DROP VECTOR INDEX por tabela por dia.
Tamanho total máximo dos dados da tabela por organização com permissão para a criação de índices do vetor que não são executados em uma reserva 20 TB Será possível criar um índice de vetor para uma tabela se o tamanho total das tabelas com índices na sua organização for menor que 20 TB. Se os jobs de gerenciamento de índices forem executados na sua reserva, esse limite não será aplicado.

Rotinas

As cotas e os limites a seguir se aplicam a rotinas.

Funções definidas pelo usuário

Os limites a seguir se aplicam às funções definidas pelo usuário (UDFs, na sigla em inglês) temporárias e permanentes nas consultas do GoogleSQL.

Limite Padrão Observações
Saída máxima por linha 5 MB A quantidade máxima de dados que a UDF JavaScript pode gerar ao processar uma única linha é de aproximadamente 5 MB.
Máximo de consultas SQL legadas simultâneas com UDFs em JavaScript 6 consultas O projeto pode ter até seis consultas SQL legadas simultâneas que tenham UDFs em JavaScript. Esse limite inclui consultas interativas e em lote. Esse limite não se aplica a consultas do GoogleSQL.
Máximo de recursos de UDF em JavaScript por consulta 50 recursos Um job de consulta pode ter até 50 recursos de UDF em JavaScript, como blobs de código in-line ou arquivos externos.
Tamanho máximo do blob de código in-line 32 KB Um blob de código in-line em uma UDF pode ter até 32 KB.
Tamanho máximo de cada recurso de código externo 1 MB O tamanho máximo de cada recurso de código JavaScript é de 1 MB.

Os limites a seguir se aplicam a UDFs permanentes:

Limite Padrão Observações
Tamanho máximo de um nome de UDF 256 caracteres Um nome de UDF pode ter até 256 caracteres.
Número máximo de argumentos: 256 argumentos Uma UDF pode ter até 256 argumentos.
Tamanho máximo de um nome de argumento 128 caracteres Um nome de argumento de UDF pode ter até 128 caracteres.
Profundidade máxima de uma cadeia de referências da UDF 16 referências Uma cadeia de referência de UDF pode ter até 16 referências profundas.
Profundidade máxima de um argumento ou uma saída do tipo STRUCT. 15 níveis Um argumento ou saída de UDF do tipo STRUCT pode ter até 15 níveis de profundidade.
Número máximo de campos em argumentos de tipo STRUCT ou saída por UDF 1.024 campos Uma UDF pode ter até 1.024 campos em argumentos de tipo e saída STRUCT.
Número máximo de bibliotecas JavaScript em uma instrução CREATE FUNCTION 50 bibliotecas Uma instrução CREATE FUNCTION pode ter até 50 bibliotecas JavaScript.
Tamanho máximo dos caminhos da biblioteca JavaScript incluídos 5.000 de caracteres O caminho para uma biblioteca JavaScript incluída em uma UDF pode ter até 5.000 caracteres.
Taxa máxima de atualização por UDF a cada 10 segundos 5 atualizações O projeto pode atualizar uma UDF até cinco vezes a cada 10 segundos.
Número máximo de UDFs autorizadas por conjunto de dados: Consulte Conjunto de dados.

Funções remotas

Os limites a seguir se aplicam às funções remotas no BigQuery.

Limite Padrão Observações
Número máximo de consultas simultâneas que contêm funções remotas 10 consultas Você pode executar até 10 consultas simultâneas com funções remotas por projeto.
Tamanho máximo da entrada 5 MB O tamanho máximo total de todos os argumentos de entrada de uma única linha é de 5 MB.
Limite de tamanho da resposta HTTP (Cloud Functions de primeira geração) 10 MB O corpo da resposta HTTP do Cloud Functions de primeira geração é de até 10 MB. Exceder esse valor causa falhas de consulta.
Limite de tamanho da resposta HTTP (Cloud Functions de segunda geração ou Cloud Run) 15 MB O corpo da resposta HTTP da sua segunda geração do Cloud Functions ou do Cloud Run tem até 15 MB. Exceder esse valor causa falhas de consulta.
Limite de tempo de invocação de HTTP máximo (Cloud Functions de primeira geração) 9 minutos É possível definir seu próprio limite de tempo para a primeira geração do Cloud Functions para uma invocação HTTP individual, mas o limite máximo é de 9 minutos. Exceder o limite de tempo definido para a primeira geração do Cloud Functions pode causar falhas de invocação HTTP e falha de consulta após um número limitado de novas tentativas.
Limite de tempo de invocação de HTTP (Cloud Functions de segunda geração ou Cloud Run) 20 minutos O limite de tempo para uma invocação HTTP individual para sua segunda geração do Cloud Functions ou para o Cloud Run. Exceder esse valor pode causar falhas de invocação HTTP e falha de consulta após um número limitado de novas tentativas.

Funções de tabela

Os limites a seguir se aplicam às funções de tabela do BigQuery:

Limite Padrão Observações
Comprimento máximo de um nome de função de tabela 256 caracteres O nome de uma função de tabela pode ter até 256 caracteres.
Comprimento máximo de um nome de argumento 128 caracteres O nome de um argumento de função de tabela pode ter até 128 caracteres.
Número máximo de argumentos: 256 argumentos Uma função de tabela pode ter até 256 argumentos.
Profundidade máxima da cadeia de referência de uma função de tabela 16 referências Uma cadeia de referência da função de tabela pode ter até 16 referências.
Profundidade máxima de um argumento ou de uma saída do tipo STRUCT 15 níveis Um argumento STRUCT para uma função de tabela pode ter até 15 níveis de profundidade. Da mesma forma, um registro STRUCT na saída de uma função da tabela pode ter até 15 níveis de profundidade.
STRUCTNúmero máximo de campos em argumentos ou tabelas de retorno do tipo por função de tabela: 1.024 campos Um argumento STRUCT para uma função de tabela pode ter até 1.024 campos. Da mesma forma, um registro STRUCT na saída de uma função de tabela pode ter até 1.024 campos.
Número máximo de colunas na tabela de retorno 1.024 colunas Uma tabela retornada por uma função de tabela pode ter até 1.024 colunas.
Comprimento máximo de nomes de colunas da tabela de retorno: 128 caracteres Os nomes das colunas das tabelas retornadas podem ter até 128 caracteres.
Número máximo de atualizações por função de tabela a cada 10 segundos 5 atualizações Seu projeto pode atualizar uma função de tabela até cinco vezes a cada 10 segundos.

Procedimentos armazenados para o Apache Spark

Os limites a seguir se aplicam aos procedimentos armazenados do BigQuery para o Apache Spark:

Limite Padrão Observações
Número máximo de consultas simultâneas de procedimento armazenado 50 É possível executar até 50 consultas simultâneas de procedimento armazenado para cada projeto.
Número máximo de CPUs em uso 12.000 É possível usar até 12.000 CPUs para cada projeto. As consultas que já foram processadas não consomem esse limite.

É possível usar até 2.400 CPUs em cada local para cada projeto, exceto nos seguintes locais:

  • asia-south2
  • australia-southeast2
  • europe-central2
  • europe-west8
  • northamerica-northeast2
  • southamerica-west1

Nesses locais, é possível usar até 500 CPUs em cada local para cada projeto.

Se você executar consultas simultâneas em um local multirregional e em um único local de região que está na mesma área geográfica, suas consultas poderão consumir a mesma cota simultânea de CPU.

Tamanho total máximo dos discos permanentes padrão em uso 204,8 TB

É possível usar até 204,8 TB de discos permanentes padrão em cada local de cada projeto. As consultas que já foram processadas não consomem esse limite.

Se você executar consultas simultâneas em um local multirregional e em um único local de região que está na mesma área geográfica, suas consultas poderão consumir a mesma cota de disco permanente padrão.

Notebooks

Todas as cotas e limites do Dataform e as cotas e limites do Colab Enterprise se aplicam aos notebooks no BigQuery (prévia). Os seguintes limites também se aplicam:

Limite Padrão Observações
Tamanho máximo do notebook 20 MB

O tamanho de um notebook é o total do conteúdo, metadados e sobrecarga de codificação.

Para visualizar o tamanho do conteúdo do notebook, expanda o cabeçalho do notebook e clique em Visualizar e em Informações do notebook.

Número máximo de solicitações por segundo para o Dataform 100 Os notebooks são criados e gerenciados pelo Dataform. Qualquer ação que crie ou modifique um notebook é contabilizada nessa cota. Esta cota é compartilhada com consultas salvas. Por exemplo, se em 1 segundo você fizer 50 alterações nos notebooks e 50 alterações em consultas salvas em 1 segundo, a cota será atingida.

Consultas salvas

Todas as cotas e limites do Dataform se aplicam a consultas salvas (visualização). Os limites a seguir também se aplicam:

Limite Padrão Observações
Tamanho máximo da consulta salvo 10 MB
Número máximo de solicitações por segundo para o Dataform 100 As consultas salvas são criadas e gerenciadas pelo Dataform. Qualquer ação que crie ou modifique uma consulta salva é contabilizada nessa cota. Essa cota é compartilhada com notebooks. Por exemplo, se em 1 segundo você fizer 50 alterações nos notebooks e 50 alterações em consultas salvas em 1 segundo, a cota será atingida.

Linguagem de manipulação de dados

Os limites a seguir se aplicam a instruções da linguagem de manipulação de dados (DML) do BigQuery:

Limite Padrão Observações
Instruções DML por dia Ilimitado O número de instruções DML que seu projeto pode executar por dia é ilimitado.

As instruções DML não são contabilizadas no número de modificações de tabela por dia ou no número de modificações por tabela particionada por dia nas tabelas particionadas.

As instruções DML têm as seguintes limitações a serem observadas.
Instruções DML mutantes simultâneas por tabela Duas Instruções O BigQuery executa até duas instruções DML mutantes simultâneas (UPDATE, DELETE e MERGE) em cada tabela. As instruções DML mutantes adicionais de uma tabela são enfileiradas.
Instruções DML mutantes na fila por tabela 20 instruções Uma tabela pode ter até 20 instruções DML mutantes na fila que aguardam execução. Se você enviar instruções DML mutantes adicionais para a tabela, essas instruções falharão.
Tempo máximo na fila para a instrução DML 6 horas Uma instrução DML de prioridade interativa pode aguardar na fila por até seis horas. Se a instrução não for executada após seis horas, ela falhará.
Taxa máxima de instruções DML para cada tabela 25 extratos a cada 10 segundos Seu projeto pode executar até 25 instruções DML a cada 10 segundos para cada tabela. Tanto INSERT quanto instruções DML mutantes contribuem para esse limite.

Para mais informações sobre como modificar instruções DML, consulte Simultaneidade de DML INSERT e Simultaneidade de DML UPDATE, DELETE, MERGE.

Consultas de múltiplas instruções

Os limites a seguir se aplicam às consultas de várias instruções no BigQuery.

Limite Padrão Observações
Número máximo de consultas de múltiplas instruções simultâneas 1.000 consultas com várias instruções Seu projeto pode executar até 1.000 consultas com várias instruções simultâneas.
Limite de tempo cumulativo 24 horas O limite de tempo cumulativo para uma consulta de várias instruções é de 24 horas.
Limite de tempo do extrato 6 horas O limite de tempo para uma instrução individual em uma consulta de várias instruções é de seis horas.

CTEs recursivos em consultas

Os limites a seguir se aplicam às expressões de tabela comuns (CTEs) recorrentes no BigQuery.

Limite Padrão Observações
Limite de iteração 500 iterações O CTE recursivo pode executar esse número de iterações. Se esse limite for excedido, ocorrerá um erro. Para contornar os limites de iteração, consulte Resolver erros no limite de iteração.

Segurança no nível da linha

Os limites a seguir se aplicam às políticas de acesso no nível da linha do BigQuery:

Limite Padrão Observações
Número máximo de políticas de acesso de linha por tabela 400 políticas Uma tabela pode ter até 400 políticas de acesso de linha.
Número máximo de políticas de acesso de linha por consulta 6.000 políticas Uma consulta pode acessar até um total de 6.000 políticas de acesso de linha.
Número máximo de instruções DDL CREATE / DROP por política a cada 10 segundos 5 instruções O projeto pode fazer até cinco instruções CREATE ou DROP por recurso de política de acesso de linha a cada 10 segundos.
DROP ALL ROW ACCESS POLICIES instruções por tabela a cada 10 segundos 5 instruções Seu projeto pode fazer até cinco instruções DROP ALL ROW ACCESS POLICIES por tabela a cada 10 segundos.

Políticas de dados

Os seguintes limites se aplicam ao mascaramento de dados dinâmicos no nível da coluna:

Limite Padrão Observações
Número máximo de políticas de dados por tag de política. 8 políticas por tag de política Até oito políticas de dados por tag de política. Uma dessas políticas pode ser usada para controles de acesso no nível da coluna. As expressões de mascaramento duplicadas não são compatíveis.

BigQuery ML

Os limites a seguir se aplicam ao BigQuery ML.

Jobs de consulta

Todas as cotas e limites de job de consulta se aplicam a jobs de consulta do GoogleSQL que usam instruções e funções do BigQuery ML.

instruções CREATE MODEL

Os limites a seguir se aplicam a jobs do CREATE MODEL:

Limite Padrão Observações
Consultas de instrução CREATE MODEL a cada 48 horas para cada projeto 20.000 consultas de instruções Alguns modelos são treinados com os serviços da Vertex AI, que têm gerenciamento de recursos e cotas próprio.
Limite de tempo de execução 24 horas ou 72 horas CREATE MODEL o tempo limite padrão do job é de 24 horas, com exceção dos jobs de série temporal, AutoML e ajuste de hiperparâmetros, com um tempo limite de 72 horas.

Funções de serviço da Vertex AI e do Cloud AI

Os limites a seguir se aplicam a funções que usam modelos de linguagem grandes (LLMs) da Vertex AI e serviços do Cloud AI:

Função Solicitações por minuto Linhas por job Número de jobs em execução simultânea
ML.ANNOTATE_IMAGE 900 307,800 5
ML.TRANSLATE 3.000 1,026,000 5
ML.UNDERSTAND_TEXT 300 102,600 5
ML.GENERATE_TEXT 60 30.000 5
ML.GENERATE_EMBEDDING 600 500.000 1
ML.PROCESS_DOCUMENT 600 205.200 5
ML.TRANSCRIBE 60 1.000 5

Para mais informações sobre como solicitar mais cotas para essas APIs, consulte os seguintes documentos:

Para solicitar mais cota para as funções, ajuste a cota do serviço de IA do Cloud associado primeiro. Depois, envie um e-mail para bqml-feedback@google.com e inclua informações sobre a cota de serviço ajustada do Cloud AI.

Para ML.GENERATE_TEXT e ML.GENERATE_EMBEDDING, a cota de solicitação por minuto depende da cota do modelo base documentada em Solicitar cotas.

BI Engine

Os limites a seguir se aplicam ao BigQuery BI Engine.

Limite Padrão Observações
Tamanho máximo de reserva por projeto e por local (interface SQL) 250 GiB Aplicável ao usar o BI Engine com o BigQuery. Aplicável em todos os casos, exceto no Looker Studio sem integração nativa.

É possível solicitar um aumento da capacidade máxima de reserva dos seus projetos. Os aumentos de reserva estão disponíveis na maioria das regiões e podem levar de três dias a uma semana para serem processados.
Tamanho máximo de reserva por projeto e por local (Data Studio) 100 GB Aplica-se ao uso do BI Engine com o Looker Studio sem integração nativa. Esse limite não afeta o tamanho das tabelas consultadas, porque o BI Engine carrega na memória apenas as colunas usadas nas consultas, não a tabela inteira.
Tamanho máximo do modelo de dados por tabela (Data Studio) 10 GB Aplica-se ao uso do BI Engine com o Looker Studio sem integração nativa. Se você tiver uma reserva de 100 GB/projeto por local, o BI Engine limita a reserva por tabela a 10 GB. O restante da reserva disponível é usado para outras tabelas no projeto.
Máximo de partições por tabela (Looker Studio) 500 partições Aplica-se ao uso do BI Engine com o Looker Studio sem integração nativa. O BI Engine para Data Studio aceita no máximo 500 partições por tabela.
Máximo de linhas por consulta (Looker Studio) 150 milhões Aplica-se ao uso do BI Engine com o Looker Studio sem integração nativa. O BI Engine para Looker Studio aceita até 150 milhões de linhas de dados consultados, dependendo da complexidade da consulta.

Analytics Hub

Os seguintes limites se aplicam ao Hub do Analytics:

Limite Padrão Observações
Número máximo de trocas de dados por projeto 500 trocas É possível criar até 500 trocas de dados em um projeto.
Número máximo de listagens por troca de dados 1.000 listagens É possível criar até mil listagens em uma troca de dados.
Número máximo de conjuntos de dados vinculados por conjunto de dados compartilhado 1.000 conjuntos de dados vinculados Todos os assinantes do Analytics Hub podem ter no máximo 1.000 conjuntos de dados vinculados por conjunto de dados compartilhado.

Cotas e limites da API

Essas cotas e limites se aplicam às solicitações da API BigQuery.

API BigQuery

As cotas a seguir se aplicam às solicitações da API BigQuery (núcleo):

Cota Padrão Observações
Solicitações por dia Ilimitado Seu projeto pode fazer um número ilimitado de solicitações da API BigQuery por dia.
Veja a cota no console do Google Cloud
Máximo de tabledata.list bytes por minuto 7,5 GB em multirregiões 3,7 GB em todas as outras regiões Seu projeto pode retornar no máximo 7,5 GB de dados de linha da tabela por minuto via tabledata.list nas multirregiões us e eu e 3,7 GB de dados de linha da tabela por minuto em todas as outras regiões. Essa cota se aplica ao projeto que contém a tabela que está sendo lida. Outras APIs, incluindo jobs.getQueryResults e a busca de resultados de jobs.query e jobs.insert, também pode consumir essa cota.
Veja a cota no Console do Google Cloud

A API BigQuery Storage Read sustenta uma capacidade significativamente maior do que tabledata.list. Se você precisar de mais capacidade do que o permitido nessa cota, use a API BigQuery Storage Read.

Os limites a seguir se aplicam às solicitações da API BigQuery (núcleo):

Limite Padrão Observações
Número máximo de solicitações de API por segundo por usuário e por método 100 solicitações Um usuário pode fazer até 100 solicitações de API por segundo para um método de API. Se um usuário fizer mais de 100 solicitações por segundo para um método, poderá haver uma limitação. Esse limite não se aplica a inserções de streaming.
Número máximo de solicitações de API simultâneas por usuário 300 solicitações Se um usuário faz mais de 300 solicitações simultâneas, a limitação pode ocorrer. Esse limite não se aplica a inserções de streaming.
Tamanho máximo do cabeçalho da solicitação 16 KiB A solicitação da API BigQuery pode ser de até 16 KiB, incluindo o URL de solicitação e todos os cabeçalhos. Esse limite não se aplica ao corpo da solicitação, como em uma solicitação POST.
Máximo de solicitações jobs.get por segundo 1.000 solicitações Seu projeto pode fazer até 1.000 solicitações jobs.get por segundo.
Tamanho máximo da resposta jobs.query 20 MB Por padrão, não há contagem máxima de linhas para o número de linhas de dados a serem retornadas por jobs.query página de resultados. No entanto, é aplicado o limite de 20 MB no tamanho máximo da resposta. O número de linhas a serem retornadas pode ser alterado por meio do parâmetro maxResults.
Tamanho máximo da linha jobs.getQueryResults 20 MB O tamanho máximo da linha é aproximado, porque o limite é baseado na representação interna dos dados da linha. O limite é aplicado durante a transcodificação.
Máximo de solicitações projects.list por segundo 2 solicitações Seu projeto pode fazer até duas solicitações projects.list por segundo.
Número máximo de solicitações tabledata.list por segundo 1.000 solicitações Seu projeto pode fazer até 1.000 solicitações tabledata.list por segundo.
Máximo de linhas por resposta de tabledata.list 100.000 Linhas Uma chamada tabledata.list pode retornar até 100.000 linhas de tabela. Para mais informações, consulte Como fazer paginação de resultados usando a API.
Tamanho máximo da linha tabledata.list 100 MB O tamanho máximo da linha é aproximado, porque o limite é baseado na representação interna dos dados da linha. O limite é aplicado durante a transcodificação.
Máximo de solicitações tables.insert por segundo 10 solicitações Seu projeto pode fazer até 10 solicitações de tables.insert por segundo. O método tables.insert cria uma nova tabela vazia em um conjunto de dados. Esse limite inclui instruções SQL que criam tabelas, como CREATE TABLE, e consultas que gravam resultados em tabelas de destino.

API BigQuery Connection

As cotas a seguir se aplicam às chamadas da API BigQuery Connection:

Cota Padrão Observações
Solicitações de leitura por minuto 1.000 solicitações por minuto Seu projeto pode fazer até 1.000 solicitações por minuto aos métodos da API BigQuery Connection que leem dados de conexão.
Veja a cota no console do Google Cloud
Solicitações de gravação por minuto 100 solicitações por minuto Seu projeto pode fazer até 100 solicitações por minuto para os métodos da API BigQuery Connection que criam ou atualizam conexões.
Veja a cota no console do Google Cloud
Conexões da AWS por região 50 conexões por região. Seu projeto pode ter até 50 conexões da AWS por região da AWS.
Conexões do Azure por região 50 conexões por região. Seu projeto pode ter até 50 conexões do Azure por região do Azure.

API BigQuery Migration

Os seguintes limites se aplicam à API BigQuery Migration (visualização):

Limite Padrão Observações
Tamanho de arquivo individual para tradução em lote do SQL 10 MB Cada arquivo de origem e de metadados pode ter até 10 MB. Esse limite não se aplica ao arquivo ZIP de metadados produzido pela ferramenta de extração de linha de comando dwh-migration-dumper.
Tamanho total dos arquivos de origem para tradução em SQL em lote 1 GB O tamanho total de todos os arquivos de entrada enviados para o Cloud Storage pode ser de até 1 GB. Isso inclui todos os arquivos de origem e de metadados, caso você os inclua.
Inserir string de tamanho para tradução do SQL interativo 1 MB A string inserida para tradução do SQL interativo não pode exceder 1 MB.
Tamanho máximo do arquivo de configuração para tradução do SQL interativo 50 MB Os arquivos de metadados individuais (compactados) e de configuração YAML no Cloud Storage não podem exceder 50 MB. Se o tamanho do arquivo exceder 50 MB, o tradutor interativo pulará esse arquivo de configuração durante a tradução e gerará uma mensagem de erro. Um método para reduzir o tamanho do arquivo de metadados é usar as flags —database ou –schema para filtrar bancos de dados quando gerar os metadados.

As cotas a seguir se aplicam à API BigQuery Migration. Os valores padrão a seguir se aplicam na maioria dos casos. Os padrões do projeto podem ser diferentes:

Cota Padrão Observações

Solicitações da lista de serviços de EDWMigration por minuto

Solicitações da lista de serviços de EDWMigration por minuto por usuário

12.000 solicitações

2.500 solicitações

Seu projeto pode fazer até 12.000 solicitações de lista da API Migration por minuto.

Cada usuário pode fazer até 2.500 solicitações de lista da API Migration por minuto.

Veja as cotas no console do Google Cloud

Solicitações Get do serviço EDWMigration por minuto

Solicitações Get do serviço EDWMigration Service por usuário

25.000 solicitações

2.500 solicitações

Seu projeto pode fazer até 25.000 solicitações GET da API Migration por minuto.

Cada usuário pode fazer até 2.500 solicitações Get da API Migration por minuto.

Veja as cotas no console do Google Cloud

Outras solicitações do serviço de EDWMigration por minuto

Outras solicitações do serviço de EDWMigration por minuto por usuário

25 solicitações

5 solicitações

Seu projeto pode fazer até 25 outras solicitações da API Migration por minuto.

Cada usuário pode fazer até 5 outras solicitações da API Migration por minuto.

Veja as cotas no console do Google Cloud

Solicitações de tradução do SQL interativo por minuto

Solicitações de tradução do SQL interativo por minuto, por usuário

200 solicitações

50 solicitações

Seu projeto pode fazer até 200 solicitações de serviço de tradução do SQL por minuto.

Cada usuário pode fazer até 50 outras solicitações de serviço de tradução do SQL por minuto.

Veja as cotas no console do Google Cloud

API BigQuery Reservation

As cotas a seguir se aplicam às solicitações da API BigQuery Reservation:

Cota Padrão Observações
Solicitações por minuto por região 100 solicitações Seu projeto pode fazer um total de até 100 chamadas para os métodos da API BigQuery Reservation por minuto e por região.
Veja as cotas no console do Google Cloud
Número de chamadas SearchAllAssignments por minuto por região 100 solicitações O projeto pode fazer até 100 chamadas para o método SearchAllAssignments por minuto e por região.
Veja as cotas no console do Google Cloud
Solicitações para SearchAllAssignments por minuto, por região e por usuário 10 solicitações Cada usuário pode fazer até 10 chamadas ao método SearchAllAssignments por minuto e por região.
Veja as cotas no console do Google Cloud
Nos resultados da pesquisa do Console do Google Cloud, pesquise por por usuário.

API BigQuery Data Policy

Os limites a seguir se aplicam à API Data Policy (visualização):

Limite Padrão Observações
Número máximo de chamadas dataPolicy.list. 400 solicitações por minuto em cada projeto

600 solicitações por minuto em cada organização
Número máximo de chamadas dataPolicy.testIamPermissions. 400 solicitações por minuto em cada projeto

600 solicitações por minuto em cada organização
Número máximo de solicitações de leitura. 1.200 solicitações por minuto e projeto

1.800 solicitações por minuto por organização
Isso inclui chamadas para dataPolicy.get e dataPolicy.getIamPolicy.
Número máximo de solicitações de gravação. 600 solicitações por minuto em cada projeto

900 solicitações por minuto em cada organização

Isso inclui chamadas para:

API IAM

As cotas a seguir se aplicam quando você usa os recursos de gerenciamento de identidade e acesso no BigQuery para recuperar e definir as políticas do IAM, além de testar as permissões dele. As instruções de linguagem de controle de dados (DCL) são contabilizadas na cota SetIAMPolicy.

Cota Padrão Observações
IamPolicy solicitações por minuto por usuário 1.500 solicitações por minuto por usuário Cada usuário pode fazer até 1.500 solicitações por minuto por projeto.
Verifique a cota no console do Google Cloud
IamPolicy solicitações por minuto por projeto 3.000 solicitações por minuto por projeto Seu projeto pode fazer até 3.000 solicitações por minuto.
Verifique a cota no console do Google Cloud
Solicitações SetIAMPolicy de região única por minuto por projeto 1.000 solicitações por minuto por projeto O projeto de uma única região pode fazer até 1.000 solicitações por minuto.
Verifique a cota no console do Google Cloud
Solicitações SetIAMPolicy multirregionais por minuto e projeto 2.000 solicitações por minuto por projeto Seu projeto multirregional pode fazer até 2.000 solicitações por minuto.
Verifique a cota no console do Google Cloud
Solicitações SetIAMPolicy Omnirregião por minuto e projeto 200 solicitações por minuto por projeto Seu projeto Omnirregião pode fazer até 200 solicitações por minuto.
Verifique a cota no console do Google Cloud

API Storage Read

As cotas a seguir se aplicam às solicitações da API BigQuery Storage Read:

Cota Padrão Observações
Solicitações de leitura dos planos de dados por minuto por usuário 25.000 solicitações Cada usuário pode fazer até 25.000 chamadas ReadRows por minuto por projeto.
Veja a cota no console do Google Cloud
Solicitações de leitura do plano de controle por minuto por usuário 5.000 solicitações Cada usuário pode fazer até 5.000 chamadas de operação de metadados da Storage Read API por minuto por projeto. As chamadas de metadados incluem os métodos CreateReadSession e SplitReadStream.
Veja a cota no console do Google Cloud

Os limites a seguir se aplicam às solicitações da API BigQuery Storage Read:

Limite Padrão Observações
Tamanho máximo da linha/filtro 1 MB Ao usar a chamada CreateReadSession da API Storage Read, você é limitado a um comprimento máximo de 1 MB para cada linha ou filtro.
Tamanho máximo de dados serializados 128 MB Quando você usa a chamada ReadRows da API Storage Read, a representação serializada dos dados em uma mensagem ReadRowsResponse individual não pode ser maior que 128 MB.
Máximo de conexões simultâneas 2.000 em várias regiões; 400 em regiões É possível abrir no máximo 2.000 conexões ReadRows simultâneas por projeto nas multirregiões us e eu e 400 conexões ReadRows simultâneas em outras regiões. Em alguns casos, o limite de conexões simultâneas pode ser menor.

API Storage Write

As cotas a seguir se aplicam às solicitações da API Storage Write. As cotas a seguir podem ser aplicadas no nível da pasta. Essas cotas são agregadas e compartilhadas em todos os projetos filhos. Para ativar essa configuração, entre em contato com o Cloud Customer Care.

Se você planeja solicitar um limite de cota maior, inclua a mensagem de erro de cota na solicitação para acelerar o processamento.

Cota Padrão Observações
Conexões simultâneas 1.000 em uma região. 10.000 em uma multirregião

A cota de conexões simultâneas é baseada no projeto do cliente que inicia a solicitação da API Storage Write, não no projeto que contém o recurso do conjunto de dados do BigQuery. O projeto inicial é o projeto associado à chave de API ou à conta de serviço.

Seu projeto pode operar em 1.000 conexões simultâneas em uma região ou 10.000 conexões simultâneas nas multirregiões US e EU.

Ao usar o stream padrão em Java ou Go, recomendamos o uso da multiplexação da API Storage Write para gravar em várias tabelas de destino com conexões compartilhadas para reduzir o número geral de conexões necessárias.

Veja a cota no console do Google Cloud

É possível ver as cotas de uso e limitar as métricas dos seus projetos no Cloud Monitoring. Selecione o nome do limite de conexões simultâneas com base na sua região. As opções são ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU e ConcurrentWriteConnectionsPerProjectRegion para us, eu e outras regiões, respectivamente.

É altamente recomendável configurar alertas para monitorar o uso e os limites da sua cota. Além disso, se os seus padrões de tráfego apresentarem picos e/ou crescimento orgânico regular, talvez seja vantajoso aumentar o provisionamento da sua cota em 25 a 50% para lidar com demandas inesperadas.

Capacidade de processamento 3 GB por segundo de capacidade em multirregiões. 300 MB por segundo nas regiões É possível fazer streaming de até 3 GBps nas multirregiões us e eu. 300 MBps em outras regiões por projeto.
Veja a cota no console do Google Cloud

É possível ver as cotas de uso e limitar as métricas dos seus projetos no Cloud Monitoring. Selecione o nome do limite da capacidade de processamento com base na sua região. As opções são AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU e AppendBytesThroughputPerProjectRegion para us, eu e outras regiões, respectivamente. A cota de capacidade de processamento para gravação é medida com base no projeto em que reside o conjunto de dados de destino, não no projeto do cliente.

É altamente recomendável configurar alertas para monitorar o uso e os limites da sua cota. Além disso, se os seus padrões de tráfego apresentarem picos e/ou crescimento orgânico regular, talvez seja vantajoso aumentar o provisionamento da sua cota em 25 a 50% para lidar com demandas inesperadas.


Solicitações CreateWriteStream 10.000 streams a cada hora, por projeto e região É possível chamar CreateWriteStream até 10.000 vezes por hora, por projeto e por região. Considere usar o stream padrão se você não precisar da semântica exata uma vez. Essa cota é por hora, mas a métrica mostrada no console do Google Cloud é por minuto.
Bytes de stream pendentes 10 TB em multirregiões, 1 TB em regiões Para cada confirmação acionada, é possível confirmar até 10 TB nas multirregiões us e eu e 1 TB em outras regiões. Não há relatórios de cota nesta cota.

Os limites a seguir se aplicam às solicitações da API Storage Write:

Limite Padrão Observações
Confirmações em lote 10.000 streams por tabela É possível confirmar até 10.000 streams em cada chamada BatchCommitWriteStream.
Tamanho da solicitação AppendRows 10 MB O tamanho máximo da solicitação é de 10 MB.

Inserções de streaming

As cotas e limites a seguir se aplicam ao streaming de dados no BigQuery usando a API de streaming legada. Para mais informações sobre estratégias para não exceder esses limites, consulte Como solucionar erros de cota. Se você exceder essas cotas, receberá erros quotaExceeded.

Limite Padrão Observações
Máximo de bytes por segundo por projeto nas multirregiões us e eu: 1 GB por segundo

É possível fazer streaming de até 1 GB por segundo no seu projeto. Essa cota é cumulativa dentro de uma determinada multirregião. Ou seja, a soma de bytes por segundo transmitidas para todas as tabelas em um determinado projeto dentro de uma multirregião está limitada a 1 GB.

Exceder esse limite causa quotaExceeded erro.

Se necessário, é possível solicitar um aumento de cota entrando em contato com o Cloud Customer Care. Todo aumento deve ser solicitado o quanto antes, no mínimo duas semanas antes de precisar dele. O aumento de cota demora ser disponibilizado, principalmente se o aumento for significativo.

Máximo de bytes por segundo em cada projeto em todos os outros locais 300 MB por segundo

Seu projeto pode transmitir até 300 MB por segundo em todos os locais, exceto nas multirregiões us e eu. Esse limite é cumulativo dentro de uma determinada região. Ou seja, a soma dos bytes por segundo transmitidos para todas as tabelas em um determinado projeto dentro de uma região é limitada a 300 MB.

Exceder esse limite causa quotaExceeded erro.

Se necessário, é possível solicitar um aumento de cota entrando em contato com o Cloud Customer Care. Todo aumento deve ser solicitado o quanto antes, no mínimo duas semanas antes de precisar dele. O aumento de cota demora ser disponibilizado, principalmente se o aumento for significativo.

Tamanho máximo da linha 10 MB Exceder esse valor causa o erro invalid.
Limite de tamanho da solicitação HTTP 10 MB

Exceder esse valor causa o erro invalid.

Observação: a solicitação é transformada internamente de HTTP/JSON para uma estrutura de dados interna. Essa estrutura de dados tem o próprio limite de tamanho. É difícil prever o tamanho da estrutura de dados interna resultante, mas se você mantiver as solicitações HTTP em 10 MB ou menos, a chance de atingir o limite interno será baixa.

máximo de linhas por solicitação 50.000 linhas É recomendado o máximo de 500 linhas. Nas operações em lote, o desempenho e a capacidade podem aumentar, mas a latência por solicitação pode ser prejudicada. Com poucas linhas por solicitação, a ingestão pode ficar ineficiente por causa do excesso de recursos utilizados no processamento de cada solicitação. Com muitas filas, o rendimento da saída pode diminuir. Teste dados representativos (esquema e tamanhos dos dados) para determinar o tamanho ideal do lote para os seus dados.
Comprimento do campo insertId: 128 caracteres Exceder esse valor causa o erro invalid.

Para cotas de streaming adicionais, consulte Solicitar um aumento de cota.