How to choose the right Relational Database Service you should use in Windows Azure

Now with Windows Azure SQL Database as well as SQL Server inside a Windows Azure Virtual Machine an important question comes up, and that is, Which Relational Database Service should I use for my solution in Windows Azure?

In order to help answering this question I did a flowchart that should help. (this is a simplification of the process but should answer most of the questions)


What are the features that aren’t supported in SQL Database you might be asking. Here’s a list:

  • SQL Server Utility
  • SQL Server PowerShell Provider. PowerShell scripts can be run on an on-premise computer, however, and connect to Windows Azure SQL Database using supported objects (such as System Management Objects or Data-tier Applications Framework).
  • Master Data Services
  • Change Data Capture
  • Data Auditing
  • Data Compression
  • Extension of spatial types and methods through Common Language Runtime (CLR)
  • External Key Management / Extensible Key Management
  • Integrated Full-Text Search
  • Large User-Defined Aggregates (UDAs)
  • Large User-Defined Types (UDTs)
  • Performance Data Collection (Data Collector)
  • Policy-Based Management
  • Resource Governor
  • SQL Server Replication
  • Transparent Data Encryption
  • Common Language Runtime (CLR) and CLR User-Defined Types
  • Database Mirroring
  • Service Broker
  • Table Partitioning
  • Typed XML and XML indexing is not supported. The XML data type is supported by Windows Azure SQL Database.
  • Backup and Restore
  • Replication
  • Extended Stored Procedures
  • SQL Server Agent/Jobs

More about this Windows Azure SQL Database:

More about SQL Server inside a Windows Azure Virtual Machine:

Hope this helps you to make the right choice.

3 thoughts on “How to choose the right Relational Database Service you should use in Windows Azure

  1. Fernando, those are two very important questions to do but the answer might not be SQL Database only since ‘high availability’ can also be achieved with SQL Server in a VM as we do today with SQL Server On-Premises, it just takes you more time and effort. as for the ‘horizontal partitioning’ you’re right, for now only in SQL Databases, but there are other ways for you to do partitioning.

    I was trying to make this for the highest number of questions possible. Of course I missed some but I think it will already help a lot.

  2. I agree, both can be achieved with SQL Server and it might even be the best choice; I just happen to think that Azure’s greatest strength is to offer such things as a managed service. I would go for SQL Database for green field applications and only go to the trouble of setting up a highly available SQL Server cluster if the application required features that only SQL Server can deliver. As always, there are no easy, generic answers.

Leave a Reply

Your email address will not be published. Required fields are marked *