Over or Under Provisioned

Lots of people move to the cloud; it’s common. In fact, it’s very common to hear customers who are being asked to migrate their workloads to a cloud vendor for a variety of reasons. You might not agree, but often there is some reason to move to the cloud. Sometimes it’s even moving from one cloud to another, just because one of the big three (AWS, Azure, GCP) seems more attractive this year than the one from last year.

When you move, do you size your system for the peak? 80% of the peak? Perhaps there is another goal for which you design. Do you worry about ever being under-provisioned and letting customers have a slower system? Or do you ensure you never hit the peak, which increases costs?

Auto-scaling can help, but it doesn’t seem to have worked as well for database systems as it does for serverless functions or other types of workloads. Compute is much easier to scale than stateful database systems that need CPUs and RAM ready on a particular system instantly. In fact, the “serverless” Azure SQL database is attractive to me more for it’s ability to scale the CPUs and RAM more than the on/off capability.

I was in a discussion recently with a number of data professionals who tend to over-provision a bit, mostly because their companies are willing to. It saves them headaches and phone calls (more angry texts these days), but it also means developers aren’t incentivized to optimize any queries. Unless there is a way to determine that the aggregate of all queries could lower the size of the resource provisioned, no one wants to fix any poorly running code.

That was interesting to me, as I’d think we’d want to optimize code as we pay every month, but the reality is that we pay every month for a level of resources. Coming in under that level is all that’s important. If we use 99% of those resources or 25%, we pay the same amount. It’s like saying we want to watch a movie every night because we pay for Netflix/Apple TV/etc. We’ve spent the money, so whether we watch 1 a week or 5 a week, there’s no point in optimizing our time to get value out of the subscription.

In the PaaS world, that might change, but often we’re still purchasing a tier of resources, not paying for each query. Until we need to raise that tier, no one worries about efficiency. If we can’t prove a lower tier would work with better code, no one cares.

It’s a little sad, but perhaps some future version of monitoring that can spin up a digital twin, optimize some code, and model a lower tier will take hold among all the performance tuners and monitoring vendors. Maybe with a few Claude code tokens, one of you will solve that problem.

For now, I still think it’s worth trying to optimize code, especially if an AI can give you suggestions and prove things run quicker in a test environment. If the cost of code is getting lower, then why not extend those savings to SQL code?

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 2 Comments

UNION vs UNIONALL: #SQLNewBlogger

While writing another post I realized my UNION query didn’t work as one might initiall expect, so I decided a short post was worth writing. This is based on a previous post on QUOTENME().

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Missing a Row

When I ran this code, I got only a single row. There’s a UNION here, so why? One would expect two rows from these queries.

2026-05_0287

Let’s change to UNION ALL. Now we see this:

2026-05_0288

You can likely spot the reason, but it’s because both rows in the result are the same. In this cse, UNION is designed to remove duplicates. In the docs, it explicitly says

  • UNION ALL – Includes duplicates
  • UNION Excludes duplicates

We can see this in this examples I’ve got this code that gives me two virtual tables of numbers, some of which are duplicate:

WITH myTally(n)
AS
(SELECT n 
 FROM (VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10)) a(n)
)
, myTally2(n)
AS
(SELECT n 
 FROM (VALUES (1), (20), (3), (40), (5), (60), (7), (08), (9), (100)) b(n)
)
SELECT n
FROM myTally
UNION 
SELECT n
 FROM myTally2

When I run the query, with UNION, I see these results, 14 rows:

2026-05_0289

If I change to UNION ALL, 20 results.

2026-05_0290

Use UNION when you want unique things. UNION ALL if you need to see ALL The Rows.

SQL New Blogger

This post was about 8 minutes spent after I finished the other post. It is a quick expansion on something I saw in another post, it has a separate focus, and it shows I’ve realized something and built on previous work.

You can showcase these skills.

Posted in Blog | Tagged , , | 1 Comment

Republish: Fixing Imposter Syndrome

It’s the last day of vacation. My wife and I stayed in Seattle an extra night so we could unwind and then catch up with a friend this morning before we head back home.

While I am having a wonderful Filipino breakfast at Ludi’s, you get to re-read Fixing Imposter Syndrome.

If you get to Seattle and find the Biscuit Bitch too busy, walk down a block to Ludi’s and try their offerings. It’s wonderful. Garlicy, but I love the Long-silog.

Posted in Editorial | Tagged | Leave a comment

Join Me in San Diego to Learn about AI and Software Development

You might have seen this graphic on the side of my blog. It’s my discount code for VS Live in San Diego this September.

I got accepted to talk about LLMs on your local machine or data center, which is something I think will be more and more important in the future. Already the EU is less thrilled with US tech giants, and I suspect many other companies will rethink allowing their data to flow to non self-hosted LLMs.

I’m also talking about the Data API Builder, which makes software development much easier for software engineers, and includes an MCP server. I’m excited to showcase how this has grown over the last few years and think it’s a cool technology.

Register today, use my code, save your company some money, and join me in Sunny San Diego. The Padres aren’t in town, but we can still enjoy some time in San Diego.

Posted in Blog | Tagged | Leave a comment