Some say that DBaaS (database as a service) -- aka cloud database -- is not suitable for Business Intelligence (BI), analytics (OLAP) or archiving.

Is this true? More generally, when DBaaS is the most effective technical choice?


It's effective technical choice when there's a lot of traffic, constant heavy usage.

The examples you listed make use of the database primarily as of storage facility, with search/processing being a far extra. Cloud is primarily about speed and CPU power, and this comes for a cost. There are far less expensive (and more reliable) archiving solutions that don't provide the kind of speed but surpass cloud in all other respects. BI, analytics etc are too not something you perform 5000 times a second 24 hours a day 7 days a week. It will be cheaper to build a dedicated server, then wait a couple seconds for each query to finish, than pay cloud maintenance for that purpose.

If you provide web applications - software-as-service over the net, for lots of clients, cloud is most welcome and gives most benefits, as it adapts to traffic that is fluctuating but always high. If the load is low, or zero most of the time, there are more cost-effective solutions.

Also if the data is very confidential, it's unwise to place it on 3rd party machines shared with random other companies, supervised by people out of your control...


One reason I use SQL Azure for my startup over a full install of SQL is that cloud databases typically let me focus on my application rather than focusing on keeping SQL Server up/updated/tuned/scaled/clustered/and every other admin work that would take me away from things.

Although we may need to do local SQL Server in the future depending on how much users trust other companies hosting their data, from a developer's standpoint it does a lot of things for me:

  • Gives me more time to focus on the app.
  • Saves money over a full SQL instance (thousands of dollars vs $10/mo per GB) until I decide I need full SQL.
  • Gives me all the features I expect like backups/indexing.
  • I can run my own analytics on the DB. It's my database, so I can do what I want. It may not be out of the box in most cases, so if you want to just run SSRS/SSAS then you can always pay the extra several grand for the full version. :-/
  • As SF. says, it's auto-scalable and redundant, so you're (highly likely) not going to lose data because the server crashes. If a server does die, you're back up in seconds if it takes that long.
  • Is your application hosted in Azure too? If not I would be interested in hearing if you think having the database hosted so far from the application gives your app a noticeable performance hit (I've been interested in using the cloud for db but not app hosting). – KallDrexx Jul 11 '11 at 14:57
  • Yes, my app is hosted in Azure, so everything is really close. Though, really, the Azure datacenters are pretty far apart (west coast, east coast, central, asia, etc). You can actually set where you want your hosted services to be, so you could actually get pretty close (within a region of the country) to your app, wherever you host it. I don't think the would be too awfully much as long as you have a solid connection. Azure is pretty dang fast in my experience, but I've not tried an Azure DB with a local app and perf tested it beyond a sample when I was learning. Seemed fast, though. – Ryan Hayes Jul 11 '11 at 16:14

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.