Microsoft Azure SQL Database Reviews

Our primary use case for SQL Azure is to operate our database.

The features I like most is that it offers a lot of securitt verification and backup from our side as well as from within SQL Azure.

Security can sometimes be a problem when it affects our business needs. It needs to integrate more security without stopping the service or our business. In some cases we have a lot of restriction on people who needs to use the database for whatever reason. We need more performance but in the same way we need more security - from the application and also in the Internet. The problem is therefore in the internet. 

The stability is good at the moment. We are more dependable on the stability from the internet from our service provider. The solution is responsible for 99% of the stability, but most of our problems are due to our local internet provider.

The scalability is good. We have 100 users and one can upgrade the system by performance and by the size of the storage. You can move between different types of storage using block or docket. You can use any way you choose without losing data. So the scalability it is very good. We plan to increase our usage.

We are planning to redo the assessment about whether more people should be involved in the technical support. 

The initial setup was very complex. It is hard to explain, but the problem is when you have more than one service. We have only one service but the solution has multiple capabilities. 

The deployment team installed the solution on one machine at a time, so it took very long. I chose a big database and within less than nine minutes I was able to collect data. So that was much faster.

We used a vendor team and they have one or two guys who are responsible for the maintenance. 

When it comes to implementation, my advice would be to integrate between Microsoft platforms. I will rate it an eight out of ten as I would love to see faster integration.

There is significant abstraction from beginner to intermediate database administration responsibilities. In this way, I can focus on my business objectives, as opposed to heavy upfront cost of ownership when compared to on-premises or IaaS alternatives.

It provides faster turnaround time to getting solutions customer facing.

It could have closer parity to on-premises capabilities. Introduce a graph database engine component.

I have been using Azure since its inception.

Historically, SQL Azure has tended to choke at databases larger than 50GB, and in some cases, as small as 20GB. Granted, this starts becoming a function of database design.

Caveat: It's been a while since I last attempted to put larger sets of data into a single SQL Azure database. Now, if you don't use resilient connection tolerance practices (or technologies), then it may feel unstable. Here again, it becomes a function of design.

In other words, if you simply choose to use on-premises traditional designs and principles when interacting with SQL Azure, then there is a higher probability of it "feeling" unstable.

I've seen and experienced some amazing service and then I've endured appalling interactions, too.

This becomes a function of your SQL engine skill, the diligence and appropriateness of your design, the support tier you purchased, and some luck if you connected with a support engineer who not only spoke your language, but also carried an attitude of chasing down a solution.

The setup is super straightforward. I don't really find that question useful, or at least as useful as, "What is it like incrementally adjusting the design of the database?"

This is where Microsoft's eco-system further outshines the alternatives. Again, this is a much longer discussion, but it's folly to choose a platform, and even a technology, without considering the lifecycle of changes.

In an agile world, you have to ask how you are going to get that data tier to respond efficiently and within business requirements and tolerances.

It's an elastic service, at least in its simplest definition, and a proactive one with some reactive capability. Therefore, there is value in monitoring usage and adjusting proactively to gain optimal savings.

Alternatives tended to be IaaS offerings hammered or butchered to be PaaS. So, frankly, the answer is that I don't know of other PaaS alternatives.

SQL Azure is a good option for maintaining structured data, especially for smaller databases (0 - 25GB).

My solutions today leverage a plethora of structured and unstructured data. Therefore, having this service in close proximity to the resource groups I use for the other services is beneficial.

It does tend to constrain me to the Azure platform, as I've yet to find a vendor who can give me the RDBMS PaaS offering. Constrain makes it sound like “suck up some pain”. However, I have yet to find the Azure platform limiting.

Here is some context or insight. I was previously on the product team that heavily influenced the direction and feature set of SQL Server, both box (on-premises) and cloud. My focus and specialty is related to scaling the RDBMS tier to support high-demand applications.

To that end, SQL Azure was very useful for a certain set of business problems. At the time, I certainly would not have recommended anything larger than 50GB residing in a SQL Azure database.

I also felt strongly that a significant value proposition of cloud-based RDBMS solutions lay in the as yet untapped elastic-scale possibilities.

To that end, I developed a framework for customers to leverage, which found its way (in a crippled form) into what is today's SQL Azure elastic feature. What I'm trying to say is that true elastic-scale and distributed scale of SQL Azure is hobbled. That frustrates me.

The value proposition of using SQL Azure for mobile and web app solutions is also significant, and it remains as strong as ever. This is especially the case for solutions that enjoy the benefits of structured data.

The on-going improvements of SQL Azure reaching parity with an on-premises feature set is making SQL Azure a viable option for many applications that previously couldn't even begin to look at cloud-based, non-IaaS, therefore PaaS, offerings.

In my current role, I consider SQL Azure the leader for cloud-based RDBMS solutions, far ahead of any other cloud-based RBMS offering. Where I have structured data, SQL Azure is my de facto storage tier.

• Availability and scalability
• Ability to understand the application and not necessarily the structure of your database
• Natural replication of the SaaS service provides efficient availability
• You can choose the geographical replication: Simply open a map and tag the new location of a replication
• Scale tab: You can change the plan of the service in terms of DTUs, point of restore, and auditing

We have configured this solution into a worldwide application based on Microsoft SQL with SQL Azure and with SQL Azure elastic pool.

Maybe the portal should have a more detailed and granular way to query data. You can use API for this purpose.

Azure is working on the query engine in order to give you the ability to analyze a query for performance with insight to improve the load or the time of a query.

I have used SQL Azure for one year along with the other Azure services.

I had no issues during our work.

It is very flexible. In the case of a heavy load period, you don’t see any difference in terms of performance. The advantage with a SaaS service is the normal scalability.

If you don't have Premium support, you need to wait for 24 hours to receive support.

Other databases like PostgreSQL and SQL Server were evaluated. We decided to switch because our .NET application works well with Microsoft solutions.

The configuration was straightforward.

You need to be careful about the size of your database or pool in order to fit it exactly within your budget.

We did not evaluate any other options.

The best use of this product is the combination with other SaaS services. Evaluate communication on premise if you need to.

We use a relational database management system and 90% of the projects I've worked with have used SQL Server. We are partners with SQL Azure. 

The main valuable feature is the auto scaling. In addition, the security features they've implemented on cloud make it a little easier compared to on-prem SQL, they're great. It enables added scalability, and costing can be tweaked and made more reliable, flexible and cost effective.

I think SQL could be improved in terms of ease of use for developers when it comes to performance. For example, enabling suggestions or auto-tune performances, providing results which are higher level recommendations. I know there are tools that performance analyze, but I personally find it to be overly complicated. If they look at performance assistance, add-ons or plugins that might help the developer, focus can be on business logic rather than performance. This is an ongoing issue for me and I'd like to see developers given the flexibility to change those recommendations, it would simplify things. 

I've been using this solution for 20 years. 

SQL's stability is dependent on where it's hosted. 

If you're going into a cluster with multiple width or multiple SQL Servers, deployment becomes a little more tricky. In general, though, the initial setup is relatively easy. 

I recommend this solution and I rate it an eight out of 10. 

We don't have to manage it much. It is managed by Microsoft, which makes it easy for us because there is no admin overhead for managing the servers. 

It is also easily scalable. During peak hours, it can scale higher.

We have a very small database running on SQL Azure. We have not been able to load bigger systems on it. It is still not something that is feasible. All our heavy-duty systems are on SAP, and it should have more compatibility with other vendors such as SAP. 

Its price can definitely be lower. It is pretty pricey.

We've been using SQL Azure for about three years.

It is stable.

It is easily scalable. We have five people who are working with this solution.

Their technical support is very good for SQL Azure. Basically, based on my experience, we usually don't have any problem with support for Microsoft products. If we are seeking support for something like Linux or something that is not exactly a Microsoft product, it is a little disappointing.

Its price can definitely be lower. It is pretty pricey.

I would rate SQL Azure a seven out of ten. It works like any other SQL database, and it is pretty good.

We use it for a few databases that are deployed for our own purposes. 

SQL is a simpler database. We use it more than other databases. 

I have been using SQL Azure for three to four months. 

We haven't had any issues with performance. 

There are only three users who use it. Once we are more comfortable we will give it to more users. My technology team uses it. 

Microsoft technical support is good. 

Pricing is reasonable for a big enterprise. The price is a little higher. It should have a 20% discount. 

I would rate SQL Azure an eight out of ten. 

We like the collaborative nature of the solution. It's the most valuable aspect of the solution.

The stability of the solution is very good.

The availability of resources could be improved.

The solution needs to offer online training to help improve the capacity of teams to manage the SQL.

The pricing is very high.

I've been using the solution for two years so far.

We haven't had any issues with the stability of the solution. There aren't bugs or glitches. It doesn't crash or freeze. It's reliable for us.

We haven't had any issues with the solution, therefore, we haven't required any technical support. I can't speak to the quality of technical support as I've never dealt with them.

In the beginning, we decided to use a specialist to configure all the systems for us and the solution is almost perfect.

The price is very high, especially when you compare it to other solutions. There aren't extra costs, however. All fees are included in the licensing package.

We're simply customers. We don't have any professional relationship with Azure.

I would recommend the solution. It's great.

I'd rate the solution nine out of ten. I'd give it perfect marks if the pricing was more reasonable and if they offered better learning tools to guide our staff.

• Memory-optimized tables
• Elastic scale
• Azure portal management tools

Some customers' applications require very large tables (large number of records). Here are examples of how this solution helped them:

• Performance of memory-optimized tables in SQL Azure exceeds that of an on premise SQL Server
• Microsoft adds new features, including bug fixing, to SQL Azure every fortnight on the average.
• Performance benchmark: There is a benchmark suite that is relevant, Azure SQL Database Benchmark (ASDB). This benchmark includes metrics in plans for the three-service tiers, Basic, Standard and Premium. (In-Memory OLTP support is only available in Premium tier plans.)

The main reason for the business case of using SQL Azure for a few large tables for our customer was as follows:

• Most of the tables in the data model (DM) for the application are small enough to have required performance in a Standard Edition of an on premise SQL Server instance. Only four tables are large enough and have peaks of concurrent transactions per minute that are large enough to require in-memory OLTP support.
• We needed to compare TCO for an Enterprise on premise SQL Server instance for the entire DM (that would be mainly under-utilized) versus TCO of a Standard on-premises for most of the DM + TCO of SQL Database with in-memory OLTP support for these four tables. (TCO for this scenario includes an estimate of changes in the design of the application.)
• This TCO comparison was calculated for a period of two years. That is the time between a given version of on premise SQL Server and the next version.
• The end result was a lower TCO for the second scenario. The first scenario implies paying an Enterprise instance up-front at the start of the two year period.
• In the second scenario, the application would have two data repositories. Transactional control for the app is the reason why I mentioned the limitation of the SQL database. It only supports distributed transactions between instances of SQL Azure. That was a technical problem to solve. This was one of the main reasons for the changes in the app in the second scenario.
• We had to make some changes to the app to separate transactions and their contexts for the two repositories.
• In this case, it would be an improvement if Microsoft were to provide support of distributed transactions between SQL Azure instances. We would also like to see support for other kinds of services for Microsoft and other vendors who support standard distributed transactions.

SQL Azure only supports distributed transactions with other instances of SQL Azure. This has been an obstacle for us.

I have been using this product for almost four years.

You can deploy your solution to a SQL Azure database directly from SQL Server Management Studio (the same tool used to manage solutions for On Premises SQL Server editions), so, the transition from SQL Server On Prem deployment to SQL Azure deploy presents no issues.

There have been no issues with stability.

There have been no issues with scalability. This is a strong feature of the product.

Microsoft has very good customer service, both free and paid customer service (by free customer service I mean customer service on free cloud solutions like Outlook.com)

Microsoft has very good technical support for this service and product, as usual. Regarding SQL Azure, the amount of free online resources for developers is huge and relevant.

For some customers' applications, we switched from memory optimized tables with on premise instances to SQL Azure instances. The switch happened under the same SQL Server umbrella.

It takes some time to get accustomed to the Azure portal and to navigate through its tools and options. You can also connect directly from the SQL Server Management Studio. It is fairly easy to configure the proper parameters for connection. Once you are connected, it is transparent for any experienced SQL Server DBA or SQL developer.

Even if you are an experienced SQL Server DBA, there is some learning to do to be able to develop, deploy and manage SQL Azure solutions. At Microsoft Virtual Academy there is a set of free courses to learn all this.

You can use a free SQL Azure account to do some of the required practice while learning (bear in mind that the free account for all Azure tools, including SQL Azure, requires that you provide credit card information), but you will also need to license a SQL Azure plan for actual deployment and use of the solution: Basic plans, Standard Plans, Premium Plans.

You can choose a plan according to the amount of resources used by your solution (storage required, number of transactions, etc.), such that the hourly rate of the chosen plan is tied to the range of resources used.

The main setup cost that we have experienced is basically time required to do the training, and payment of a plan during the development and testing of the solution.

I did not evaluate anything else. I started using SQL Azure through teaching some MOC courses that included it, in early 2013. I had the chance to get to really know the product and the service.

For any potential customer who is considering migrating an app to SQL Azure, my advice is:

• Spend enough time analyzing if SQL Azure offers you a viable business case for the said app. It may or may not offer this to you!
• It is very important that you have a thorough understanding of the performance details and issues of the current app from a standpoint of the database engine. This is mainly with DMVs and DMFs, if you are using an on premise SQL Server.