Cómo definir límites de coste en Synapse SQL Serverless

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

Una sola consulta mal escrita en Synapse SQL Serverless puede recorrer terabytes del Data Lake e inflar la factura a final de mes. Definir límites de coste en Synapse SQL Serverless es un trabajo de dos minutos que evita sorpresas: cuando el volumen de datos procesados supera el techo definido, el servicio deja de ejecutar consultas. Sigue los pasos siguientes para medir, limitar y reducir ese consumo.

Requisitos previos

Un workspace de Azure Synapse Analytics con el SQL pool serverless (Built-in) disponible.
Permisos de administrador en el workspace, o pertenecer al rol sysadmin en el endpoint serverless.
Un cliente SQL: Synapse Studio, Azure Data Studio o SQL Server Management Studio.
Opcional: algunos ficheros CSV o Parquet en el Data Lake para probar las consultas.

Paso 1: Entender qué se factura

En SQL serverless no pagas por servidores ni por horas encendidas: pagas por el volumen de datos procesados por cada consulta, medido en TB. "Datos procesados" incluye los datos leídos del storage, los datos transferidos entre nodos y los datos devueltos al cliente. Una consulta que lee un CSV entero de 50 GB cuesta mucho más que la misma consulta sobre Parquet con filtro de partición, aunque el resultado final sea una sola fila.

Por eso el control de costes aquí no consiste en "apagar el servicio" (no tiene estado encendido/apagado), sino en limitar cuántos datos pueden procesarse por día, semana o mes.

Paso 2: Medir los datos procesados

Antes de definir un límite, mira cuánto estás consumiendo ya. La DMV sys.dm_external_data_processed muestra los datos procesados en los períodos diario, semanal y mensual en curso:

SELECT type, data_processed_mb
FROM sys.dm_external_data_processed;

Ejecútalo en el endpoint serverless (la base de datos master vale). El resultado te devuelve tres filas — daily, weekly y monthly — con los MB ya procesados. Es la base para elegir un límite realista: si tu consumo diario normal ronda los 200 GB, un límite de 1 TB/día da margen sin dejar pasar un accidente.

Paso 3: Definir el límite con sp_set_data_processed_limit

El límite se define con T-SQL, en la base de datos master del endpoint serverless:

USE master;
GO

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

El parámetro @type acepta N'daily', N'weekly' o N'monthly', y puedes definir los tres a la vez: el más restrictivo es el que frena primero. Un patrón prudente para un equipo pequeño:

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;

Atención: cuando se alcanza el límite, las consultas siguientes dejan de ejecutarse hasta el inicio del período siguiente. Es un freno de seguridad, no una alerta: define el valor con margen para no tumbar informes en producción.

Paso 4: Hacer lo mismo desde Synapse Studio

Si prefieres interfaz gráfica: en Synapse Studio abre el hub Manage, elige SQL pools, pasa el ratón sobre el pool Built-in y haz clic en los tres puntos. La opción Cost Control abre un panel donde defines los mismos límites diario, semanal y mensual. Ahí también confirmas visualmente los valores vigentes.

Paso 5: Reducir los datos procesados (el ahorro de verdad)

El límite te protege; la optimización es lo que baja realmente la factura. Tres hábitos con impacto inmediato:

Usa Parquet en lugar de CSV. Al ser columnar y comprimido, serverless lee solo las columnas necesarias.
Nunca hagas SELECT * sobre el Data Lake. Indica las columnas que necesitas: cada columna de más son datos procesados de más.
Filtra por partición con filepath(). Si los ficheros están organizados por año/mes, serverless salta las carpetas 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';

En tablas históricas, solo este último cambio suele recortar el volumen leído en un orden de magnitud.

Verificar el resultado

Vuelve a ejecutar la consulta del Paso 2 y fíjate en data_processed_mb: tras aplicar el filtro por partición, el crecimiento por consulta debería ser mucho menor. Para probar el límite sin romper nada, define temporalmente un valor muy bajo (por ejemplo @limit_tb = 1 en monthly en un workspace de desarrollo), lanza una consulta pesada y confirma el mensaje de error que indica que se ha superado el límite. Después vuelve a poner el valor definitivo. En Synapse Studio, el panel Cost Control debe mostrar exactamente los límites que definiste.

Conclusión

Con dos comandos ya tienes un freno de costes en Synapse Serverless y, con el filtro por filepath(), consultas que procesan una fracción de los datos. El siguiente paso natural es crear vistas sobre el Data Lake que ya incluyan las columnas y los filtros correctos, para que quien consulta no tenga que acordarse. ¿Has mirado cuántos MB procesa por ejecución tu consulta más usada? El número suele ser una sorpresa.