0

I've tried to Google looking for others with the same question for about an hour now and can't find anything close, so hoping someone here might be able to offer some insight!

I'm a many-hat admin with a small software company the provides SaaS service solutions to our clients, we use Azure SQL, with Elastic Pools to host around 100 individual customer databases currently that run quite happily on a Standard Tier 100 eDTU Elastic Pool. Utilisation through the day runs between 60-80% which for our application is quite a comfortable buffer in case one of the clients should go crazy with a report query or bulk data load.

We are about to bring another 100 or so clients currently hosted on legacy VMs running SQL classic over into Azure SQL as well.

My questions is: Do I place them in the current elastic pool and up the eDTU to 200, or do I create a new separate 100 eDTU elastic pool and place them there?

Database size and Min/Max DTU per database settings, and the marginal difference in costs aren't considerations. So given that all the relative resource limits effectively double between 100 and 200 eDTU (concurrent workers/connections/sessions etc), is it just a question of how they are logically grouped?

What considerations would go into this choice? Is there something I'm missing?

2 Answers 2

0

It seems that you are below the limits in both cases, so it seems pretty the same.

These are the limits:

enter image description here

As you can see, the only thing that really seems to matter in your case and that donsen't double when you switch from 100edtu to 200edtu, is the max concurrent sessions.

So, if you are far below this limit, I suggest you to choose basing on the easiest design. If you are reaching the session limit per pool, it's better to split it up in two 100 edtu pool.

Don't change winning team. :-)

1
  • Thanks for the insight, one thing I hadn't considered. Speaking to our Devs the way our application is structured we're never going to hit the Max concurrent connections. The Application code only ever makes 2 or 3 concurrent connections to a single DB at a time max. Also looking at the Metrics for the current pool, most of the time it doesn't even register 0.1% of the 'Sessions Percentage' metric from month to month. Good to confirm this isn't really a problem I need to consider! Mar 17, 2021 at 22:36
0

We are using elastic pools and as well as MBuschi´s comments the 2 biggest factors that drive our decision on whether to use a new pool are

  1. Storage - if you hit the max storage per pool limit stuff will stop working & this is bad

  2. Region - pick an Azure region that is close to your customers - they will get faster response time & thank you for it

Apart from that as granny used to say "don't keep all your eggs in one basket"

1
  • Thank you for your insight as well! Storage is of course important, DBs are typically quite small. We're sitting at 34% of the included 100GB storage for the 100 eDTU Pool at the moment, and that doubles if we choose to go to 200 eDTU. Drop in the bucket when the max is 500/750GB for the two pool sizes respectively. We do have a small handful of clients that have massive DBs, but those tend to have been contracted for their own logical set of everything, VMs, SQL server and elastic pools included. This particular server/pool is used for our 'run-of-the-mill' type clients. :) Mar 17, 2021 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.