SQL: Different Thinking is Needed for New Azure SQL DB Features

A few days ago, I wrote about the new Standard Developer Edition of SQL Server 2025 and what good news it was. I noted that the need for it had reduced since SQL Server 2016 SP1 but it was still helpful.

While the product group management did a good job with SQL Server 2016 SP1, others in the product group don’t seem to have remembered those lessons. The team keeps releasing features that only work on particular SKUs of Azure SQL Database.

Lack of cloudiness

That’s not helpful for development, and certainly not very cloudy.

For example, Change Data Capture (CDC) needs S3 or above if you use a DTU-based server. Same applied to the new Change Event Streams (CES). I don’t like this. I 100% understand that you might need that level of performance to use the feature in production. But you don’t need that level of performance to build code, or to test it with a handful of rows.

Development usage vs production usage

The thinking about development needs to be different to the thinking about production usage.

I mentioned that limiting the features this way isn’t cloudy. For example, I often take databases and scale them down to lower SKUs while I’m not using them. (You can’t pause one of these databases but if you aren’t using DTU based databses, you might consider serverless options). But you can’t scale down a database that has these features as part of the code. It refuses to do it.

Supporting developers

The outcome of this, is that unless developers can keep the databases at the S3 level or above, they might simply ignore those features. And that’s even more likely with the current trend of having large numbers of databases deployed, often at least one per developer. That would be a real waste of effort for the team building these features.

Limiting the ability to write code to only larger SKUs is old big central database thinking, not current cloudy thinking.

Once again, we need to get to a point where the same code can be built on the different SKUs. Don’t stop developers building the code. Whether or not it will perform on those SKUs in production, is an entirely different matter.

2025-06-19