Background

I am intending to use the Azure SQL database to house a number of flat tables that will be used to populate graphs on a website. The graphs will be interactive so there will be a number of calls back to the SQL database to refresh or change the data in the graphs. 

Problem Statement

Is the Azure SQL database appropriate for housing medium datasets (50 million rows) that may have 20 calls a minute from something like Fusion Charts passing through a customer id as the only 'where clause' to return data back to the graphs? 

The reason I ask is I have a concern that the Azure SQL database will not be able to cope with that level of calls to it and as a result give the end user a bad experience with processing delays.

:o dont know why you get that perception of "azure database will not be able to cope with that level of calls"

azure is highly scalable, 

Don't be fooled by the "Azure is highly scalable" remark.  Yes, it's scalable, but so is on-premise.  The trick is working out what you need from the platform and what level of development and design will be required.

A single SQL Azure database has a maximum size limit of 150GB.  Having said that, I wouldn't use a single database if the bulk of that space is taken up by a single table.  How much data are we talking here?  50m narrow records with a highly selective key will perform fairly well, but if your records are wide, and you're returning a lot of records from each call, then it changes things.

Think of a SQL Azure database as running on a poorly resourced PC with a single or dual core.  Your performance won't be great for a single database, so you need to design the solution to use lots of them to allow parallel processing.  For example, you could shard your data across multiple databases based on customer id, to spread the workload.

20 calls a minute is not a huge workload though, so it really depends on how much data is being processed.

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

agree with Mike on this, especially on the "poorly resourced PC" analogy :)

Each service/offering on the Azure platform have different "scaling" abilities.

some services offers you both horizontal and vertical scaling.

for Azure SQL, sharding/federations horizontal scaling is all you can scale. you can't ask for more processing power or more memory.

also even using sharding/federations is not a guarantee. a poorly designed sharding/federation strategy may result to most queries actually going to the same shard/member. you may also end up with another resource hungry tenant/neighbor on the same server as your databases.

 

• Proposed as answer by vishalishere Wednesday, June 26, 2013 4:52 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

I think i agree with what June says, it depends a lot on your strategy, but advantage of a sql azure db is that you can scale out on demand as soon as you like with minimal effort..

• Edited by vishalishere Tuesday, June 18, 2013 9:03 PM

On-demand scaling out on Azure SQL database is possible, in fact with the right level of code investment and design you can achieve reactive and proactive elasticity.  With that said, it requires a custom sharding solution and isn't simply out of the box functionality.  Read this blog to learn more http://blogs.msdn.com/b/windowsazure/archive/2013/09/05/dal-sharding-of-rdbms.aspx

I wanted to add that as of recent Azure SQL Database can be scaled-up when introducing the Premium SKU to the discussion http://blogs.technet.com/b/dataplatforminsider/archive/2013/07/09/a-closer-look-at-the-premium-offer-for-windows-azure-sql-database.aspx

Hi,

I suggest that you make some tests, but going with SQL Database in first place it's not a risky option, if the performace it's not enought you always can move the database to a Virtual Machine with dedicated resources (and much more expensive).

You may also be abble to split your database into multiple shards by using SQL Database Federations (SQL Azure Federations)