Cotas e limites

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

O Google Cloud usa cotas para garantir a imparcialidade e reduzir picos no uso e na disponibilidade de recursos. Uma cota restringe quanto de um recurso do Google Cloud o projeto do Google Cloud pode usar. As cotas se aplicam a vários tipos de recursos, incluindo hardware, software e componentes de rede. Por exemplo, as cotas podem restringir o número de chamadas de API para um serviço, o número de balanceadores de carga usados simultaneamente pelo projeto ou o número de projetos que podem ser criados. As cotas protegem a comunidade de usuários do Google Cloud, impedindo a sobrecarga de serviços. As cotas também ajudam você a gerenciar seus próprios recursos do Google Cloud.

O sistema de cotas do Cloud faz o seguinte:

• Monitora o consumo de produtos e serviços do Google Cloud.
• Restringe o consumo desses recursos.
• Fornece um meio de solicitar mudanças no valor da cota

Na maioria dos casos, quando você tenta consumir mais de um recurso do que a cota permite, o sistema bloqueia o acesso ao recurso e a tarefa que você está tentando executar falha.

As cotas geralmente se aplicam ao projeto do nível Google Cloud. O uso de um recurso em um projeto não afeta a cota disponível em outro. Em um projeto do Google Cloud, as cotas são compartilhadas entre todos os aplicativos e endereços IP.

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 Service Usage 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 criando uma cota substituir, consulte Criar substituição de cota.

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 caracteres da consulta SQL	1.024 characters	Uma consulta SQL pode ter até 1.024 caracteres. Esse limite inclui comentários e caracteres de espaço em branco. Se sua consulta for mais longa, você vai receber o seguinte erro: The query is too large. Para permanecer dentro deste limite, substitua matrizes ou listas grandes por parâmetros de consulta e dividindo uma consulta longa em várias consultas na sessão.
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 por projeto 20.000 slots por organização	Com o preço sob demanda, seu projeto pode ter até 2.000 slots simultâneos. Também há um limite de 20.000 slots simultâneos no nível da organização. O BigQuery tenta alocar slots de maneira justa entre projetos de uma organização quando a demanda total é maior que 20.000 slots. 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 TiB	Você pode exportar até 50 TiB(Tebibytes) de dados por dia de um projeto sem custos 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 TiB (Tebibytes) de dados por dia, siga um destes procedimentos: Crie uma reserva de slot e especifique PIPELINE como o tipo de atribuição. Vamos cobrar usando os preços com base na capacidade. Use a instrução SQL EXPORT DATA. A cobrança será feita usando preços sob demanda ou com base na capacidade, dependendo de como seu projeto estiver configurado. Use a API Storage Read. Cobraremos usando o preço por leituras de streaming. O prazo de validade é de pelo menos 6 horas após a criação da sessão.
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: Crie uma reserva de slot e especifique PIPELINE como o tipo de atribuição ou use uma atribuição PIPELINE atual. Vamos cobrar usando os preços com base na capacidade. Use a instrução SQL EXPORT DATA. A cobrança será feita usando preços sob demanda ou com base na capacidade, dependendo de como seu projeto estiver configurado. Use a API Storage Read. Cobraremos usando o preço por leituras de streaming. O prazo de validade é de pelo menos 6 horas após a criação da sessão.
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 é reabastecido com uma cota máxima de 100.000 jobs de carregamento a cada 24 horas. Os jobs de carregamento com falha são contabilizados nesse limite. Em alguns casos, é possível executar mais de 100.000 jobs de carregamento em 24 horas se a cota de um dia anterior não for totalmente usada.
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:

  • Campaign Manager
  • Google Ads
  • Google Ad Manager
  • Google Merchant Center (Beta)
  • Google Play
  • Search Ads 360 (Beta)
  • Canal do YouTube
  • Proprietário do conteúdo no YouTube

• 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 que especifica o copy na configuração do job. 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.
Número máximo de slots em uma reserva associada a um atribuição de reserva com um tipo de job CONTINUOUS.	500 slots	Quando você quiser criar uma atribuição de reserva que tenha um CONTINUOUS a reserva associada não poderá ter mais de 500 slots.

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: Console do Google Cloud a ferramenta de linha de comando bq; Bibliotecas de cliente do BigQuery Os seguintes métodos de API: datasets.insert datasets.patch datasets.update datasets.delete datasets.undelete As seguintes instruções DDL: CREATE SCHEMA ALTER SCHEMA DROP SCHEMA UNDROP SCHEMA
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.

Observação: as cotas e os limites estão associados aos nomes das tabelas. Portanto, quando você trunca a tabela ou descarta a tabela e a recria, a cota não é redefinida porque o nome da tabela não foi alterado.

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. Os dados de streaming não são contabilizados 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: Console do Google Cloud a ferramenta de linha de comando bq; Bibliotecas de cliente do BigQuery Os seguintes métodos de API: tables.insert tables.patch tables.update Instruções DDL em tabelas 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.

Observação: esses limites não se aplicam a tabelas externas particionadas pelo Hive.

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	10.000 partições	Cada tabela particionada pode ter até 10.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. Os dados de streaming não são contabilizados 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: Console do Google Cloud a ferramenta de linha de comando bq; Bibliotecas de cliente do BigQuery Os seguintes métodos de API: tables.insert tables.patch tables.update Instruções DDL em tabelas 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 3. 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, o snapshot B do clone A e o clone C do snapshot B. Para fazer outras cópias do clone ou snapshot de terceiro nível, use uma operação de cópia.
Número máximo de clones e snapshots para uma tabela base	Mil snapshots ou clones de tabelas	Não é possível ter mais de 1.000 clones e snapshots combinados de uma determinada tabela base. Por exemplo, se você tiver 600 snapshots e 400 clones, o limite será atingido.

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 3. 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, o snapshot B do clone A e o clone C do snapshot B. Para fazer outras cópias do clone ou snapshot de terceiro nível, use uma operação de cópia.
Número máximo de clones e snapshots para uma tabela base	Mil snapshots ou clones de tabelas	Não é possível ter mais de 1.000 clones e snapshots combinados de uma determinada tabela base. Por exemplo, se você tiver 600 snapshots e 400 clones, o limite será atingido.

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. É possível criar visualizações até esse limite, mas as consultas são limitadas a 15 níveis. Se o limite for excedido, o BigQuery retornará 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 para o tipo de índice IVF 200.000.000 para o tipo de índice TREE_AH	Uma tabela pode ter no máximo 1.000.000.000 de linhas para criar um índice de vetor IVF e 200.000.000 para criar um índice de vetor TREE_AH.
Tamanho máximo da matriz na coluna indexada	1.600 elementos	A coluna a ser indexada pode ter no máximo 1.600 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	6 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 6 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.

Observação: as UDFs e as tabelas que elas fazem referência contam para o limite no número de recursos referenciados em uma consulta.

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 função do Cloud (1a geração) pode causar falhas na invocação de HTTP e na consulta.
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 na invocação de HTTP e na consulta.
Número máximo de tentativas de repetição de invocação HTTP	20	O número máximo de novas tentativas para uma invocação HTTP individual à sua Função do Cloud (1a ou 2a geração) ou o Cloud Run. Exceder esse valor pode causar falhas na invocação de HTTP e na consulta.

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. 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 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. 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 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.
INSERT instruções DML simultâneas por tabela por dia	1.500 instruções	As primeiras 1.500 instruções INSERT são executados imediatamente após o envio. Depois que esse limite é atingido, a simultaneidade de instruções INSERT que gravam em uma tabela é limitada a 10. Outras instruções INSERT são adicionadas a uma fila PENDING. Até 100 instruções INSERT podem ser colocadas em fila em uma tabela a qualquer momento. Quando uma instrução INSERT é concluída, a próxima instrução INSERT é removida da fila e executada. Se você precisar executar instruções INSERT DML com mais frequência, considere fazer streaming de dados para sua tabela usando a API Storage Write.
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.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo gemini-1.5-pro	60	21.600	5
ML.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo gemini-1.5-flash	200	72.000	5
ML.GENERATE_TEXT ao usar um modelo remoto em vez de gemini-1.0-pro-vision na região us-central1	100	20.000	1
ML.GENERATE_TEXT ao usar um modelo remoto sobre o modelo gemini-1.0-pro-vision em regiões diferentes de us-central1	10	3.600	1
ML.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo gemini-1.0-pro na região us-central1	300	108.000	5
ML.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo gemini-1.0-pro em regiões diferentes de us-central1	10	3.600	5
ML.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo text-bison	1.600	576.000	5
ML.GENERATE_TEXT ao usar um modelo remoto em vez de um modelo text-bison-32	300	108.000	5
ML.GENERATE_EMBEDDING quando usado com modelos remotos em vez de modelos multimodalembedding da Vertex AI nas regiões únicas europeias compatíveis	120	25.000	5
ML.GENERATE_EMBEDDING quando usado com modelos remotos em vez de modelos multimodalembedding da Vertex AI em regiões diferentes das regiões únicas da Europa compatíveis	600	25.000	5
ML.GENERATE_EMBEDDING quando usado com modelos remotos em vez de modelos text-embedding da Vertex AI e text-multilingual-embedding na região us-central1	1.500	2.700.000	1
ML.GENERATE_EMBEDDING quando usado com modelos remotos em vez de modelos text-embedding da Vertex AI e text-multilingual-embedding em regiões diferentes de us-central1	100	180.000	1
ML.PROCESS_DOCUMENT	600	216.000	5
ML.TRANSCRIBE	200	72.000	5
ML.ANNOTATE_IMAGE	1.800	648.000	5
ML.TRANSLATE	6.000	2.160.000	5
ML.UNDERSTAND_TEXT	600	21.600	5

Para mais informações sobre a cota de LLMs da Vertex AI e as APIs de serviço do Cloud AI, consulte os seguintes documentos:

• IA generativa nos limites de cota da Vertex AI
• Cota e limites da API Cloud Translation
• Cota e limites da API Vision
• Cota e limites da API Natural Language
• Cota e limites da Document AI
• Cota e limites da Speech-to-Text

A cota de linhas por job representa o maior número teórico de linhas que o sistema pode processar em um período de seis horas O número real de linhas processadas depende de muitos outros fatores, incluindo o tamanho da entrada e as condições da rede. Por exemplo, ML.TRANSCRIBE pode processar mais áudios curtos do que longos.

Para solicitar mais cota para as funções do BigQuery ML, primeiro ajuste a cota do serviço associado do LLM ou do Cloud AI da Vertex AI. Depois, envie um e-mail para [e-mail] com informações sobre a cota de serviço ajustada do LLM ou do Cloud AI. Para mais informações sobre como solicitar mais cota para esses serviços, consulte Solicitar uma cota maior.

Definições de cota

A lista a seguir descreve as cotas que se aplicam às funções de serviço da Vertex AI e do Cloud AI:

• As funções que chamam um modelo de fundação da Vertex AI usam uma cota da Vertex AI, que é de consultas por minuto (QPM). Nesse contexto, as consultas são chamadas de solicitação, da função para a API do modelo da Vertex AI. A cota do QPM se aplica a um modelo base e a todas as versões, identificadores e versões ajustadas desse modelo. Para mais informações sobre as cotas do modelo de fundação da Vertex AI, consulte Cotas por região e modelo.
• As funções que chamam um serviço de IA do Cloud usam as cotas de solicitação do serviço de destino. Verifique a referência de cota do serviço de IA do Cloud fornecido para mais detalhes.

• O BigQuery ML usa três cotas:

  • Solicitações por minuto. Essa cota é o limite do número de chamadas de solicitação por minuto que as funções podem fazer para a API do modelo da Vertex AI ou do serviço do Cloud AI. Esse limite se aplica a cada projeto.

    Para funções que chamam um modelo de fundação da Vertex AI, o número de chamadas de solicitação por minuto varia de acordo com o endpoint, a versão e a região do modelo da Vertex AI. Essa cota é conceitualmente igual à cota do QPM usada pela Vertex AI, mas pode ter um valor menor do que a cota do QPM de um modelo correspondente.

  • Linhas por job. Essa cota é o limite do número de linhas permitidas para cada job de consulta.

  • Número de jobs em execução simultânea. Essa cota é o limite por projeto do número de consultas SQL que podem ser executadas ao mesmo tempo para uma determinada função.

Os exemplos a seguir mostram como interpretar limitações de cota em situações típicas:

• Tenho uma cota de 1.000 QPM na Vertex AI, então uma consulta com 100.000 linhas leva cerca de 100 minutos. Por que o job está em execução por mais tempo?

  Os ambientes de execução do job podem variar até mesmo para os mesmos dados de entrada. Na Vertex AI, as chamadas de procedimento remoto (RPCs) têm prioridades diferentes para evitar a drenagem da cota. Quando não há cota suficiente, as RPCs com prioridades mais baixas aguardam e podem falhar se demorarem muito para processá-las.

• Como interpretar as linhas por cota de job?

  No BigQuery, uma consulta pode ser executada por até seis horas. O máximo de linhas permitido é uma função desse cronograma e da sua cota do QPM da Vertex AI, para garantir que o BigQuery possa concluir o processamento de consultas em seis horas. Como normalmente uma consulta não pode utilizar toda a cota, esse é um número menor do que a cota QPM multiplicada por 6.

• O que acontece se eu executar um job de inferência em lote em uma tabela com mais linhas do que as linhas por cota de job, por exemplo, 10.000.000?

  O BigQuery só processa o número de linhas especificado pelas linhas por cota de job. Você só é cobrado pelas chamadas de API bem-sucedidas desse número, e não pelas 10.000.000 linhas da tabela. Para o restante das linhas, o BigQuery responde à solicitação com um erro A retryable error occurred: the maximum size quota per query has reached, que é retornado na coluna status do resultado. Use esse conjunto de scripts SQL ou este pacote do Dataform para iterar as chamadas de inferência até que todas as linhas sejam processadas.

• Tenho muito mais linhas para processar do que as linhas por cota de trabalho. Dividir minhas linhas em várias consultas e executá-las simultaneamente ajudará?

  Não, porque essas consultas consomem as mesmas solicitações por cota de minuto do BigQuery ML e cota QPM da Vertex AI. Se houver várias consultas que permanecem dentro das linhas por cota de job e número de cotas de jobs em execução simultânea, o processamento cumulativo esgota a cota de solicitações por minuto.

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 do BigQuery Omni criadas por minuto	10 conexões criadas por minuto	Seu projeto pode criar até 10 conexões do BigQuery Omni total na AWS e no Azure por minuto.
Usos de conexão do BigQuery Omni	100 usos de conexão por minuto	Seu projeto pode usar uma conexão do BigQuery Omni até 100 vezes por minuto. Isso se aplica a operações que usam sua conexão para acessar sua conta da AWS, como consultar uma tabela.

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 dataPolicies.list.	400 solicitações por minuto em cada projeto 600 solicitações por minuto em cada organização
Número máximo de chamadas dataPolicies.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 dataPolicies.get e dataPolicies.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: dataPolicies.create dataPolicies.delete dataPolicies.setIamPolicy dataPolicies.patch

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.

Observação: se você encontrar restrições de solicitação do IAM, recomendamos que avalie se o projeto pode usar Herança de permissão do IAM para aliviar a restrição.

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.
Uso máximo de memória por stream	1,5 GB	A memória máxima por stream é aproximada porque o limite é baseado na representação interna dos dados da linha. Os streams que utilizam mais de 1,5 GB de memória para uma única linha podem falhar. Para mais informações, consulte Resolver problemas de recursos excedidos.

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.

Observação: os projetos que ativaram a aplicação de cota no nível da pasta só podem verificar o uso e o limite da cota no nível da pasta na página de cotas do console do Google Cloud. O uso e o limite da cota no nível do projeto não serão exibidos. Nesse caso, as métricas de monitoramento no nível do projeto ainda são uma boa fonte para o uso no nível do projeto.

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. Se você estiver usando o conector do Beam com semântica do menos uma vez, defina UseStorageApiConnectionPool como TRUE para ativar a multiplexação. 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	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.