locked
How does EntityFramework 4.1 code first affect SQL Database billing? RRS feed

  • Question

  • We are considering creating an Azure hosted web service to run our automated web ui tests against. However, each run of the test suite should start with freshly seeded data. We do this on our LM's using the EF DropCreateDatabaseAlways initializer during the test suite startup. 

    So to make this run in Azure, each test run would drop the test database, recreate, and reseed it with data. My question has to do with how this affects billing. Say we use a 1GB db at $9.99 per month. Is this prorated? So, if we use this drop / create db approach, would our usage still round off to about $9.99 per month? There wouldn't be a new $9.99 charge for each drop / create, right?

    Thursday, December 8, 2011 9:05 PM

Answers

  • You are charged for your daily usage for every database. If you use 1Gb database for 1 day you will pay $9.99/30 in a 30 day month. If you use 2 databases in one day you will pay twice the amount. You should use the same DB in order to pay only $9.99. 

    Thursday, December 8, 2011 9:54 PM

All replies

  • You are charged for your daily usage for every database. If you use 1Gb database for 1 day you will pay $9.99/30 in a 30 day month. If you use 2 databases in one day you will pay twice the amount. You should use the same DB in order to pay only $9.99. 

    Thursday, December 8, 2011 9:54 PM
  • It is sort of lame that the "default" approach that MS's preferred DB-layer EF uses (DropCreate initializers, hardly an unusual or novel approach) is semi "billing incompatible" by default with MS's preferred cloud platform (Azure). Its not a huge issue, but I ended up being surprised by an unexpected billing when I first started evaling Azure in August. Left a bad taste in my mouth.

    • Edited by Coad Toad Thursday, December 8, 2011 11:23 PM
    Thursday, December 8, 2011 11:22 PM
  • Don´t forget the bandwidth charges!
    Tuesday, December 13, 2011 2:40 PM
  • Thanks everyone for the info. I was hoping the answer would be that pricing is prorated hourly, rather than daily. 

    @Toad, you're definitely right about compatibility. Luckily they seem to be addressing this with code first migrations, which is now in Beta 1. Azure has helped us to barely put a dent in our technology services budget this far, which is why I'm considering using it more -- because we can afford to. 

    Might be nice if M$ had a policy whereby the database counts as 1 daily multiplier when there were 2 or 3 or more databases with the same name? I don't think you can have 2 dbs with the same name on 1 azure subscription, can you?

    Wednesday, December 14, 2011 5:38 PM