When should I use Sql Azure and when should I use table Storage?

This is an excellent question and one of the tougher and harder to reverse decisions that solution architects have to make when designing for Azure.

There are mutliple dimensions to consider:On the negative side, SQL Azure is relatively expensive for gigabyte of storage, does not scale super well and is limited to 150gigs/database,however, and this is very important, there are no transaction fees against SQL Azure and your developers already know how to code against it.

ATS is a different animal all together. Capable of mega-scalability, it is dirt cheap to store, but gets expensive to frequently access. It also requires significant amount of CPU power from your nodes to manipulate. It basically forces your compute nodes to become mini-db servers as the delegation of all relational activity is turned over to them.

So, in my opinion, frequently accessed data that does not need huge scalability and is not super large in size should be destined for SQL Azure, otherwise Azure Table Services.

Your specific example, transactional data from financial transactions is a perfect place for ATS, while meta information (account profiles, names, addresses, etc.) is perfect for SQL Azure.

Igor and Mark gave great answers. Let me add just a bit more...

With SQL Database (formerly named SQL Azure), you can now have databases up to 500GB. To go beyond that, you'd need to partition your data. Note: Originally I suggested shards with SQL Federations, but this feature has since been retired.

ATS does offer transactions at the partition level (entity group transactions). See this MSDN article for more information. This is not as robust as SQL Azure transactions, but it does allow for batch operations in a single transaction.

EDIT It's been over a year since this question was asked (and answered). One comparison point was on pricing. While SQL Azure is still more expensive than ATS, the cost of SQL Azure has dropped significantly in the past year. Databases now have tiered pricing, starting at $4.99 for 100MB, increasing to $225 for 150GB (a big drop from the $9.99 / GB pricing from last year. Full pricing details are here.

EDIT Aug 2014 Another year later, another update. While web/business tiers continue to exist, they are being sunsetted (and SQL Federations is no longer available). The new Basic, Standard, and Premium tiers are now available (see here for details).

Some of these answers don't seem complete, so I'll add my 2 cents.

Azure Table's Good points:

• Strong point is its ability to store lots of little data; Azure table is based on Azure Blob, but is geared towards smaller data
• Much cheaper than Azure SQL Server
• Anytime you know both the partition key and the row key, the data access is very fast.
• Entity transactions are possible if you place two different "schemas" in the same partition key.
• Where the total row size is LESS THAN 980K (SQL Row)
• Where each property is LESS THAN 64K (SQL Column)
• It can act as a poor man's SQL.

Azure table's bad points:

• SQL is the weak point. Don't expect to use this on any large SQL table or you will suffer performance issues.
• Limited SQL is available, don't expect joins of any type, besides what you implement in Linq
• Azure Table SQL doesn't scale as well as its ability to store an infinite amount of data
• Anytime you don't specify both a partition key and row key in a WHERE clause, expect a slow table scan to occur
• Expect table scan performance to degrade as you add more rows
• Don't expect Azue Table queries to be fast as you add more rows
• Bottom line, if you're using Azure Table to act like SQL don't add lots of data. If you have lots of data (gigabytes), just don't plan on getting high-performance SQL queries against it. You will be saving money if you don't need those regular SQL features.