…brew your own Business Intelligence

Azure Analysis Services: Choosing a Pricing Tier

April was a big month for the Azure Analysis Services community – as the product has finally been released for General Availability! Unfortunately, this also means bye bye to preview-pricing. Thankfully, there’s a new “tier” available to choose from when provisioning an Azure AS instance to help offset the price increase.

Before this week, there were only 2 pricing tiers: Developer (D1) & Standard (S0, S1, S2, & S4). Feature-wise, these 2 tiers were identical – the only difference being the amount of memory and query processing units (QPUs) available.

Now we have the new Basic tier with seemingly little difference from the Standard tier. A quick glance at the provisioning page shows the B1 and S0 as nearly identical from a resource perspective. However, the B1 option is over 50% cheaper… so what’s the catch?

image

The catch is that the Basic tier has feature-limitations making it more suited for… well… “basic”… models… ones that don’t require partitioning (for managing size and/or low data latency refreshes) or translations, or  perspectives, or direct query. In other words, Azure AS “Basic” is equivalent to the on-premise “Standard Edition” whereas Azure AS “Standard” (and “Developer”) is equivalent to the on-premise “Enterprise Edition”.

I think was a really good move by Microsoft in terms of offering a better option for the “Power BI Grow Up Story”… which I suspect is going to represent (initially) a very large percent of the production Azure AS adoption.

2 thoughts on “Azure Analysis Services: Choosing a Pricing Tier

  1. Dylan Morgan says:

    Great analogy! I think the missing component for the power bi grow up story would have to be an ‘import from power bi’ feature in Visual Studio, which has been vaporware up until now.

    Interestingly we made choices before the B tier was available that pushed us down the Standard tier, but that became a blessing in disguise, as we began a CDC based DW story that we think will create incredible value as the warehouse stacks up historical data. While we require the partitions for our refresh cycle, we are capable of time traveling through the data in a way the traditional kimball model never envisioned.

    1. Bill says:

      sounds like a cool project!

Leave a Reply