How can we improve Azure SQL Database?

Please reconsider the new DB pricing tiers

Please reconsider the new DB pricing tiers. We have been using a 10 GB Business DB for almost 4 years and have been very happy with its performance. Last week we moved to the new Tiers since Web/Business will be deprecated in the future. We tried S1, S2 etc eventually we had to move to P2 to get the same level of performance.

That was over a 3X price increase for something we've been using for almost 4 years.

395 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

One more update here.

A couple of folks reach out after my last post, and I’d encourage everyone else that’s concerned or adding comments to do the same here.

For this update I did want to highlight a couple of 3rd part comments on Elastic Database Pools and their experience upgrading from Web/Business

It would be good to understand your scenario in more details. While we understand that a small subset of customers may be asked to pay more for their resource consumption, this isn’t the common use case.

For those of you who are facing large increases in your monthly bill as a result of moving from Web/Business (where we charge on DB size) to Basic/Standard/Premium single or elastic DBs I am always willing to listen to the specifics.

We do think the new service tiers, with their new features and predictable performance, offer great price performance for SQL databases in the cloud. We specifically made these changes as a result of customer feedback (that performance needed to be predictable)

I’d be happy to engage offline with more details.

I would ask that you reach out to me rather than post here if you want a response.

Thanks Guy


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • jrstern commented  ·   ·  Flag as inappropriate

    I'm a long-time SQL Server user just trying out Azure now on a medium scale. While there are many things to like, I find the price/performance aspect is very unattractive. I think I understand what Microsoft's concerns are, but if they really want to maximize revenue and profits, I think they need a different concept of price/performance. Now, perhaps they do not yet *want* to maximize revenue and profits, because it's still sort of new to them, too. That would explain some of these pricing difficulties.

    The main point is that you should get bulk discounts, you should get (much) more for your money as you scale up. Right now, Microsoft does not do that. They charge linearly (or worse) for everything. That is in conflict with the way most things in the world are priced, and I would argue there are technical reasons why it is even a worse idea for computing services.

    It is very awkward when a simple function I can perform on my laptop in three seconds, takes twenty times that long on a P4 Azure database - and ends up blocking a production transaction and causing an exception.

    Guy, I'm planning to reach out to you directly in the next week on some of these issues. Thanks.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Finally I got the forced upgrade from web to v12. My database is 100Mb(!!!) only.

    I have a query which sometimes takes 10 seconds on web edition. The first tire when this query runs at all is S2 (10x price increase) and takes 90 seconds.

    As a bonus the auto migration removed my __RefactorLog table, and this screwed totally my ssdt publish(!)

    It seems that the only option to go back dedicated server or Amazon RDS.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I just maxed out a basic database with only three concurrent users. My app isn't inefficient. This is not acceptable! The cost is just too high for ordinary businesses to use Azure!

  • Pedro Uribe commented  ·   ·  Flag as inappropriate

    I'm already rewriting all of my EF queries (Linq-To-Entities) to plain SQL queries, so I can stop using Microsoft .NET and thus stop using Microsoft Azure.

    Basic tier and S0 tier are too slow.
    S1 tier is decent but way too expensive. 29 USD/month equals to 348 USD/year.

    All the other services have more reasonable prices: AWS, Heroku, etc.
    I rather invest in other technologies such as PHP Laravel or Node.JS than broke myself with the expensive Microsoft Azure S1 database plan.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I was really happy with my "Web database" plan in terms of price and performance.
    My database is less than 1 GB so the price was 9.99 USD/month before July.

    Now this plan doesn't exist and I was automatically assigned to the Basic database plan (5 USD/month). It SUCKS in terms of performance. It is horrible. In fact some of the queries timeout.

    I tried upgrading to S0 (15 USD/month) and it sucks too. It is much more slower than the "Web (retired)" plan.

    I finally upgraded to S1 (30 USD/month) and now it feels like the "Web (retired)" plan in terms of performance.... but, in terms of money, I ended up paying 3x times more than what I paid before.

    This is unacceptable.

    It is unacceptable that now I need to pay 30 USD/month ("S1 plan") to get the same performance that I had when I paid 10 USD/month ("Web retired plan")

  • [Deleted User] commented  ·   ·  Flag as inappropriate

    No wonder Azure profits are up... when your costs go up 10x for the same performance as before! Oh and add to that you now need to pay for standard geo-replication which used to be free. Shame on you Microsoft.

  • JP commented  ·   ·  Flag as inappropriate

    "Something is seriously wrong on the Azure SQL platform if you have to go premium to get basic performance."

  • Anonymous commented  ·   ·  Flag as inappropriate

    Guy Haycock marked this as completed to hide this idea from the front page.
    This is in the top 10 most voted idea, but hidden because "completed".

    I'm still on the web tier, but got email that the forced upgrade really starts in mid July.

    Today just panicked and started my free Amazon tour...

  • Anonymous commented  ·   ·  Flag as inappropriate

    Chiming in... I just upgraded our V2 databases to V12, mainly looking for the insight tools to try and tune in a hope to bring down DTU usage and thus use smaller/cheaper types (we're on a P2).

    Just moving from a P2 V2 to a P2 V12 nearly doubled our DTU usage!! So much for trying to save by tuning... Now I'm just hoping I can tune it enough to stay in a P2 without hitting it DTU limit and getting throttled. :(

    I've applied all the indexes it's asking for and it claims overall DTU reductions of %15, %5, %12, etc... But I have no idea where it gets those figures from because my actual DTU usage hasn't budged?

    I looked into pools... Unless I'm reading something very wrong, they seem to be MUCH more expensive for the same total DTUs? I'd need to group a lot of very sporadic databases together to even begin seeing any cost savings...while putting all my DBs at greater risk of noisy neighbor problems.

    While I love a lot of the features of SQL Azure, the cost is becoming prohibitive. This alone may push us off Azure entirely. :(

  • Will Anderson commented  ·   ·  Flag as inappropriate

    For everyone trying to move to Azure SQL and finding it cost prohibitive; here are a couple pointers.

    1) Indexes are the most important thing to get right with Azure SQL. During our initial performance test we were moving some DBs from a dedicated SSD box to P1 SQL DB and was maxing out the DTU usage. Thinking it was never going to happen, we put it down at first.

    When elastic databases came along we thought we would give it another go, this time with the added benefit of the performance and query insight tools. When we stress tested the database again we instantly saw a couple queries using a lot of DTU usage. At this point we added the indexes and just like that our usage when down to 10% from 100%, just by fixing / adding a couple indexes.

    So the first thing we learnt was that indexes are the most important thing to get right on Azure in terms of DTU usage. (of course they are important outside of Azure, but if you're coming from a dedicated SSD box they don't always show as a bottleneck / can be missed)

    2) After doing some initial tuning on your databases turn on the query store feature and let azure find and add indexes to your databases over time. Some of our databases have halved in DTU requirements over time as azure has added / remove indexes to increase performance and reduce DTU usage which is fantastic.

    3) Already touched on but use Elastic pools - we have three Pools set up:
    - Dev
    - Primary
    - Secondary

    We actively replicate our databases from Primary to Secondary database pools. We use Dev for testing.

    As an agency this set up has meant so much less hassle maintaining servers and means we can offer so much more to clients (replication to another geolocation - cool!). The sharing of resources is also perfect for us.

    Hope this helps someone.

  • Robert Brown commented  ·   ·  Flag as inappropriate

    It would be nice to see the Storage size decoupled from the DTUs. For example we have a relatively moderate DB size ~25GB, but we have a high CPU usage. We don't need anywhere near 500GB of storage but would like the speed that the Premium service allows

  • Anonymous commented  ·   ·  Flag as inappropriate

    We are in the same situation as most others here. We have a 10 Gig database that was working 'fine' at P6.
    After moving it to V12 we had to move it up to P11 to get the same performance. That means 800DTU equals 1750DTU on V12.

  • Chris Hewitt commented  ·   ·  Flag as inappropriate

    I have recently been working with a 130GB DB in BOTH SQL Azure (P2) and a SQL Server Azure VM (D12 V2 - 4 Cores, 28GB RAM, 2TB Premium/SSD).
    The pricing is similar (VM a bit cheaper).
    The VM performs ~10x faster.
    You don't get the same SLA of course (would need 2 VMs), but Azure VMs are pretty reliable.

    There is a business opportunity - set up a Saas version of SQL Server on Azure!

    Or at least club together to set up and administer a high-availability SQL platform.

  • Lajos Marton commented  ·   ·  Flag as inappropriate

    @Anonymus: "dealing with really bad and unpredictable performance" - you mean really bad and predictable performance :(

  • MM commented  ·   ·  Flag as inappropriate

    This is only kind of "completed" for larger customers (having a lot of DBs) and can therefor use Elastic Pools. For everyone else, it is simply not solved and means a dramatic increase of cost - or dealing with really bad and unpredictable performance.

  • Denis Pitcher commented  ·   ·  Flag as inappropriate

    I just wanted to send in a quick suggestion incase it helps anyone else. We managed to get blazing performance out of our database by implementing indexed views of our core relationships between our tables. *** only our keys and core lookup data, not all data ***

    We’re running a roughly 15GB database, millions of records, many joins. The Business plan worked great and initially the new tier system was terrible. We were going to have to upgrade to P1 or P2 for comparable performance. After implementing indexed views on our core relationships we managed to shift from regular timeouts to using about 30% capacity of an S2 level database.

    After researching the new tiers and reading up on the performance differences using resources like Chris Bailiss’ analysis ( I realised that the core difference between the old and new tiers was memory utilization. We have tables with millions of records that when joined caused entire tables to be loaded into memory. No matter how much I tweaked the indexes, I simply could not solve this problem. We have a raft of legacy code that also made it impossible to change our queries.

    This led me to realize that if I created a view of only our core relationships between tables and put an index on top of it, I could redirect our regular views to query against that. This meant a small performance hit on writes as of course the indexed view needed to be maintained, however since it only contained the relationships between primary keys, it wasn’t terribly significant. On the other hand, the performance boost we got was substantial because suddenly we were able to query a single table for all of our relationships and have the db use that as a reference for lookups.

    I'm doubtful this is a feasible strategy for everyone but I figured there’s no harm in mentioning it in case it could help someone with a similar situation.

  • Johan Claeson commented  ·   ·  Flag as inappropriate

    I can just agree with the other people here.. Something is seriously wrong on the Azure SQL platform if you have to go premium to get basic performance.

← Previous 1 3 4 5 6

Feedback and Knowledge Base