thanks for taking the time to share your findings and writing the in-depth articles about Windows Azure SQL DB performance. I’m a software architect on a team that builds a product that runs on-premise as well as on Windows Azure, and our team made similar findings (with similar despair).

We’re relying on bulk copy (the managed SqlBulkCopy API) to move larger amounts of data, although Sql Azure DB has it’s fair share of issues (such as the inability to target temporary tables with the SqlBulkCopy API), I think we’re getting a decent performance with this approach.

One thing I’d like to bring to the discussion is that I don’t think Windows Azure SQL DB is marketed as a direct competitor to SQL Server; not from a performance perspective at least.

Our software originated as an on-premise architecture and we’ve made a significant investment in rewriting parts of the architecture to cater for the transient faults, latencies and other snags that occur in a cloud-based (i.e. shared-resource) environment. We’re definitely sure there’s a lot more work ahead of us, but embracing the cloud or not is not as simple as running a few benchmarks.

If you don’t fancy the PaaS architecture of Windows Azure SQL DB, you’re free to use IaaS and host your own full-blown SQL Server(s) on dedicated servers, basically allowing you to get close to the same performance as your on-premise SQL Server; again, provided your workload fits the largest amount of memory available in the IaaS offerings.

We’re moving towards a more asynchronous-based messaging architecture, with less OLTP and more data going to queues, topics and table storage.

What are your thoughts on the matureness of Windows Azure services (e.g. queues, topics, and table store) as of january, 2013?