Como definir limites de custo no Synapse SQL Serverless

João Barros 13 de July de 2026 5 min de leitura

Uma única consulta mal escrita no Synapse SQL Serverless pode varrer terabytes do Data Lake e inflacionar a fatura ao fim do mês. Definir limites de custo no Synapse SQL Serverless é um trabalho de dois minutos que evita surpresas: quando o volume de dados processados ultrapassa o tecto definido, o serviço deixa de executar consultas. Segue os passos abaixo para medir, limitar e reduzir esse consumo.

Pré-requisitos

Uma workspace do Azure Synapse Analytics com o SQL pool serverless (Built-in) disponível.
Permissões de administrador na workspace, ou pertencer à role sysadmin no endpoint serverless.
Um cliente SQL: Synapse Studio, Azure Data Studio ou SQL Server Management Studio.
Opcional: alguns ficheiros CSV ou Parquet no Data Lake para testar as consultas.

Passo 1: Perceber o que é cobrado

No SQL serverless não pagas por servidores nem por horas ligadas: pagas pelo volume de dados processados por cada consulta, medido em TB. "Dados processados" inclui os dados lidos do storage, os dados transferidos entre nós e os dados devolvidos ao cliente. Uma consulta que lê um CSV de 50 GB inteiro custa muito mais do que a mesma consulta sobre Parquet com filtro de partição — mesmo que o resultado final seja uma linha.

É por isso que o controlo de custos aqui não se faz "desligando o serviço" (ele não tem estado ligado/desligado), mas sim limitando quantos dados podem ser processados por dia, semana ou mês.

Passo 2: Medir os dados processados

Antes de definir um limite, vê quanto é que já estás a consumir. A DMV sys.dm_external_data_processed mostra os dados processados nos períodos corrente diário, semanal e mensal:

SELECT type, data_processed_mb
FROM sys.dm_external_data_processed;

Executa isto no endpoint serverless (base de dados master serve). O resultado dá-te três linhas — daily, weekly e monthly — com os MB já processados. É a base para escolher um limite realista: se o teu consumo diário normal ronda os 200 GB, um limite de 1 TB/dia dá folga sem deixar passar um acidente.

Passo 3: Definir o limite com sp_set_data_processed_limit

O limite define-se por T-SQL, na base de dados master do endpoint serverless:

USE master;
GO

EXEC sp_set_data_processed_limit
    @type = N'daily',
    @limit_tb = 1;
GO

O parâmetro @type aceita N'daily', N'weekly' ou N'monthly', e podes definir os três em simultâneo — o mais restritivo é o que trava primeiro. Um padrão prudente para uma equipa pequena:

EXEC sp_set_data_processed_limit @type = N'daily',   @limit_tb = 1;
EXEC sp_set_data_processed_limit @type = N'weekly',  @limit_tb = 5;
EXEC sp_set_data_processed_limit @type = N'monthly', @limit_tb = 15;

Atenção: quando o limite é atingido, as consultas seguintes deixam de ser executadas até ao início do período seguinte. Isto é uma travão de segurança, não um alerta — define o valor com margem para não parares relatórios em produção.

Passo 4: Fazer o mesmo pelo Synapse Studio

Se preferires interface gráfica: no Synapse Studio abre o hub Manage, escolhe SQL pools, passa o rato sobre o pool Built-in e clica nos três pontos. A opção Cost Control abre um painel onde defines os mesmos limites diário, semanal e mensal. É também aí que confirmas visualmente os valores atualmente em vigor.

Passo 5: Reduzir os dados processados (o verdadeiro poupança)

O limite protege-te; a otimização é que baixa mesmo a fatura. Três hábitos com impacto imediato:

Usa Parquet em vez de CSV. Sendo colunar e comprimido, o serverless lê apenas as colunas necessárias.
Nunca faças SELECT * sobre o Data Lake. Indica as colunas que precisas — cada coluna a mais são dados processados a mais.
Filtra por partição com filepath(). Se os ficheiros estão organizados por ano/mês, o serverless salta as pastas irrelevantes:

SELECT r.cliente_id, r.valor
FROM OPENROWSET(
        BULK 'https://minhastorage.dfs.core.windows.net/lake/vendas/ano=*/mes=*/*.parquet',
        FORMAT = 'PARQUET'
     ) AS r
WHERE r.filepath(1) = '2026'
  AND r.filepath(2) = '07';

Só esta última alteração costuma cortar o volume lido numa ordem de grandeza em tabelas históricas.

Verificar o resultado

Volta a correr a consulta do Passo 2 e repara no valor de data_processed_mb: depois de aplicares o filtro por partição, o crescimento por consulta deve ser muito menor. Para testar o limite sem estragar nada, define temporariamente um valor muito baixo (por exemplo @limit_tb = 1 em monthly numa workspace de desenvolvimento), corre uma consulta pesada e confirma a mensagem de erro a indicar que o limite foi excedido. Depois volta a colocar o valor definitivo. No Synapse Studio, o painel Cost Control deve mostrar exatamente os limites que definiste.

Conclusão

Com dois comandos ficaste com um travão de custos no Synapse Serverless e, com o filtro por filepath(), com consultas que processam uma fração dos dados. O passo seguinte natural é criar vistas sobre o Data Lake que já incluam as colunas e os filtros certos, para que quem consulta não tenha de se lembrar disso. Já foste ver quantos MB a tua consulta mais usada processa por execução? O número costuma ser uma surpresa.