How to set cost limits in Synapse SQL Serverless

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

A single badly written query in Synapse SQL Serverless can scan terabytes of the Data Lake and inflate your bill at the end of the month. Setting cost limits in Synapse SQL Serverless is a two-minute job that prevents surprises: once the volume of data processed goes over the ceiling you defined, the service stops running queries. Follow the steps below to measure, cap and reduce that consumption.

Prerequisites

An Azure Synapse Analytics workspace with the serverless SQL pool (Built-in) available.
Administrator permissions on the workspace, or membership of the sysadmin role on the serverless endpoint.
A SQL client: Synapse Studio, Azure Data Studio or SQL Server Management Studio.
Optional: some CSV or Parquet files in the Data Lake to test the queries against.

Step 1: Understand what you are billed for

In serverless SQL you do not pay for servers or for hours of uptime: you pay for the volume of data processed by each query, measured in TB. "Data processed" includes data read from storage, data transferred between nodes and data returned to the client. A query that reads a whole 50 GB CSV costs far more than the same query over Parquet with a partition filter — even if the final result is a single row.

That is why cost control here is not about "turning the service off" (there is no on/off state), but about limiting how much data can be processed per day, week or month.

Step 2: Measure the data processed

Before setting a limit, look at what you are already consuming. The sys.dm_external_data_processed DMV shows the data processed in the current daily, weekly and monthly periods:

SELECT type, data_processed_mb
FROM sys.dm_external_data_processed;

Run this on the serverless endpoint (the master database is fine). The result gives you three rows — daily, weekly and monthly — with the MB already processed. This is the basis for choosing a realistic limit: if your normal daily consumption is around 200 GB, a 1 TB/day limit leaves room to breathe without letting an accident through.

Step 3: Set the limit with sp_set_data_processed_limit

The limit is defined in T-SQL, in the master database of the serverless endpoint:

USE master;
GO

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

The @type parameter accepts N'daily', N'weekly' or N'monthly', and you can set all three at the same time — the most restrictive one kicks in first. A sensible pattern for a small team:

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;

Careful: once the limit is reached, subsequent queries stop running until the next period starts. This is a safety brake, not an alert — set the value with enough margin so you do not take production reports down.

Step 4: Doing the same from Synapse Studio

If you prefer a graphical interface: in Synapse Studio open the Manage hub, choose SQL pools, hover over the Built-in pool and click the three dots. The Cost Control option opens a panel where you set the same daily, weekly and monthly limits. It is also where you visually confirm the values currently in force.

Step 5: Reduce the data processed (the real saving)

The limit protects you; optimisation is what actually lowers the bill. Three habits with immediate impact:

Use Parquet instead of CSV. Being columnar and compressed, serverless only reads the columns it needs.
Never run SELECT * against the Data Lake. List the columns you need — every extra column is extra data processed.
Filter by partition with filepath(). If files are organised by year/month, serverless skips the irrelevant folders:

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

On historical tables this last change alone usually cuts the volume read by an order of magnitude.

Verify the result

Run the Step 2 query again and look at data_processed_mb: after applying the partition filter, the growth per query should be much smaller. To test the limit without breaking anything, temporarily set a very low value (for example @limit_tb = 1 on monthly in a development workspace), run a heavy query and confirm the error message saying the limit was exceeded. Then put the definitive value back. In Synapse Studio, the Cost Control panel should show exactly the limits you set.

Conclusion

With two commands you now have a cost brake on Synapse Serverless and, with the filepath() filter, queries that process a fraction of the data. The natural next step is to create views over the Data Lake that already include the right columns and filters, so whoever queries them does not have to remember to do it. Have you checked how many MB your most used query processes per run? The number is usually a surprise.