How far can you take SimpleDB, OpenID and Cloud?

I think the benefits of using OpenID are pretty well known. Benefits of using SimpleDB to store custom details include:

• The flexible schema allows certain types of dynamic user data to be directly supported in ways that can be cumbersome with an RDBMS. For example, custom profile fields or an arbitrarily long list if values ​​such as email addresses. The data can be stored directly without the need to use another table to join.
• You don't have any settings or configuration options to tweak, so it's simple. You are mainly outsourcing server maintenance and database maintenance tasks. Which you also do, to a lesser extent if you stay with the hosted SQLServer solution. And I don't know about the SQLServer shared host, but I had bad experience with MySQL shared hosting in terms of a sequence of performance and availability issues.
• One more SimpleDB claim: Better availability with all automatic data replication across datacenters and across all servers in your cluster, capable of handling both read and write independently. If your entire data center goes dark or your router literally melts, your application might still frown. Possibly degraded service but fully functional if you plan well. And when problems are fixed, the data is automatically synced in the background.
• Good performance. It's not as fast as a locally hosted SQLServer instance with no load, but out of the box it is fast enough for user data (and more) and scales well.
• If you run an ASP.NET application on an Amazon EC2 Windows server, you get fast, free data transfers between your server and SimpleDB. Typical reverse ping times are between 2ms and 7ms.
• The free tier covers 1 GB of bandwidth, 1 GB of storage, and 25 hours of usage per month per month. Depending on the app, you can go pretty far for free.

The disadvantages include:

• There is no relationship or constraint or schema, so you need to denormalize to some degree. The constraints you want to test must be enforced in code, and the joins you want to do will require repeating queries to simulate. Connections with subsequent queries and primary keys are not as bad as they sound as SimpleDB has a robust query API and is optimized for concurrent queries. In most cases even complex joins can be modeled (equivalent time) in 2 rounds in SimpleDB.
• You have no settings and settings to configure.
• You must be able to deal with the possible consistency. You can always apply atomic updates and item-level deletes, but updates may not show up in read requests for a full second during normal operations (in my experience, not a guarantee). And, of course, much more time on failures. "handling" should usually happen at the session level. If a user updates their profile (using your app) and no one else can see this change for a couple of seconds, that's fine, but if her view reverts to its previous state for a few seconds, it'll be bad. There are some easy ways to deal with this, but you need to think about and deal with these issues.
• You are at the mercy of the Amazon. Nothing bad can happen, and it's not necessarily worse than being at the mercy of the SQLServer hosting company. But this can cause concern for some people. Worse than the case of SQLServer: The SimpleDB application will not work anywhere if you part company with Amazon (except for a local M / DB instance).