Microsoft Azure SQL Database Reviews

We usually work on a valuation basis. When a customer wants to get on to our cloud, we suggest SQL Azure to them.

The preset configuration switches we can select on SQL Azure should be made more liberal to work on. The licensing cost for the solution is very expensive and should be improved.

I have been using SQL Azure for eight years.

SQL Azure is a stable solution.

SQL Azure is a scalable solution. Around 30 to 40 customers are using the solution.

Their customer support is not ok at all because sometimes the tickets we raise don't get authorized.

The initial setup for the solution is easy. It takes around 10 to 15 minutes to set up the solution. The deployment of the solution is straightforward.

The ROI depends on the customer and the scenario.

SQL Azure's licensing cost is expensive.

SQL Azure is a cloud-based solution. We usually require one or two people to deploy and maintain the solution. I would recommend SQL Azure for other people who don’t want to manage their environment. The worst thing about Microsoft is that it has a very bad license agreement that nobody understands.

Overall, I rate SQL Azure an eight out of ten.

The primary use case is to pass services for applications of some customers, where they have maybe the front end in dot net and another language, and SQL service in Azure.

The administration console in Azure, all in one is the most valuable feature. Monitoring the transactions in Azure and the elasticity when we need to grow the databases for our customers.

I think that the cost management in SQL is not clear because we may use some tax to identify products, but in some cases identifying the transactions in SQL is not easy for some financial cost centers. Perhaps if in Azure cost management we have the opportunity to monitor the SQL cost in more detail, it will be helpful.

I have been using the solution for around four years.

I give the solution a nine out of ten.

In some cases, our customers need to move forward with their SQL projects and when they try to budget in the Azure pricing calculator some costs appear that in the production environment are very different. This becomes problematic for customers when they use SQL Pass services.

We are an IT company, so I'm an architect for that company using Azure solutions. Many users in many companies use SQL. I estimate maybe around 1,000 final users and technical staff from each company are using SQL Azure.

We decided to implement some forms for different purposes. We needed to implement it on-premises, so we did this on Azure to support the data from the forms implemented on a SQL server, and on Azure on several databases. It's very easy. 

The solution is quite straightforward to set up.

It can scale. 

The solution is stable and reliable. 

I want the pricing to be improved. They should try to lower it for their customers. 

I've used the solution for one year.

The stability is good. There are no bugs or glitches, and it doesn't crash or freeze. 

The solution can scale. I can't say how much as I don't have a comparable use case on the cloud and on-premises. 

We have about five people using the solution right now. For now, we do not have plans to increase usage.

The support is good. They have a good document library. If there is a problem, we can figure it out. 

The initial setup is very straightforward. It's not complex at all. For us, it did not take more than one or two hours. It was quick to deploy. 

We only need one person on hand for deployment and maintenance. They are a developer. 

We did not use a consultant for the implementation process. We have a lot of experience in Azure and a lot of systems in Azure as well. 

We have a yearly licensing fee we need to pay. It's not a cheap solution. 

I'd recommend the solution to other users. 

Based on the experience I've had, I would rate it seven out of ten. 

We use SQL Azure for what we call an inspection round. Inspection rounds are mainly used by an inspector in the field to check the compliance of the equipment, like if a given machine doesn't have enough instrumentation. 

In any kind of plant, there is an inventory of assets. Most companies have an inspector who goes to the field to check the condition and record some indicators. The results of the inspection are recorded in our software. All the data from the inspection round is stored in our database in Azure. That is what we use the Azure database for.

We created a custom PaaS. It's not a pre-built device in the cloud. Azure components like SQL Azure and a web server are combined to create this solution. Our SQL performs better in that space than a readymade device.

The most valuable aspect of SQL Azure is the SQL language itself. It's open and everybody can use it at my company. Also, we thought in the beginning that the response time would be inadequate, but it's actually decent. It's much better than expected. Then again, I'm not a programmer, but that's what I hear from our development team. 

There are some characteristics called "joins," like "inner join," "full join," "left join," "right join," etc. It's a little confusing for some coders. I think that could be simplified. 

I'm in the analytic space, so I would introduce a higher level of coding using artificial intelligence. SQL is quite close to English. They could add a voice interface where you speak into it, and the machine writes the code for you. My weakness in coding requires something automated, so I can be more proactive. 

They should also simplify the security in Azure. We are using the cloud as a platform, so there is no physical infrastructure. We're using Azure components like databases and servers to create an application. Integrating those components in terms of permissions and security is challenging for us. Maybe there is a lack of knowledge on our side, but it's not straightforward. 

The data modeling is not good for me. There are better tools than SQL Azure when you need to create the abstract part of the database design. It's weak. It's not user-friendly, and the notation is specific to Microsoft. I believe we use a third-party tool for data modeling because it's easier to use. Communicating with that tool is easier than SQL Azure. The model is nicer.

I have been using SQL Azure for about five or six years. We started using the solution for one of our clients, a mining company, more than five years ago. They were the first customers to use our solution.

We don't have any issues with stability. The primary issues in the cloud are privileges, security, and integration between applications. That is a total mess for us. When we need to get the application servers access to the Azure database. 

SQL Azure is scalable.

I only contacted Azure support once, and it was decent. We asked some questions, and they replied. I cannot it say was great or awful. They met our expectations. 

Setting up SQL Azure is easy. Even I can do it. 

We pay around $1,200 per year for one customer based on what they currently use. It's mainly processing and storage. SQL Azure is a bit more expensive than other solutions. There are free databases, but they don't have the scalability of the Azure cloud. It might not be affordable for some companies, but it's highly scalable.

I rate SQL Azure eight out of 10. I would recommend it to others depending on their needs. It might be beyond the budget of some companies.

Generally, what I like about Azure as a cloud is the analytics you can apply on top of that data. Azure provides a number of high-performing solutions for data science and analytics. The main issue is that you need to build the architecture to create a product that provides value for your customers.

It's about imagination and creativity, and most of the tools are there. In my case, ease of use matters because I lack the knowledge to explore more, but our development team could do that easily. 

It is basically hosting the backend of our application that we write as a software development company. We're moving our educational timetabling software, which was historically an on-premise installation, to a cloud-based service offering for customers.

It is pretty much version-less in the sense that we are using whatever is presented to us and available. We are purely using the cloud-based services from Azure hosted in the cloud, which obviously and technically is version-less to some degree. We are using SQL Azure, app services, Application Gateway, key vaults, and storage solutions within Azure. It is relatively simple but sufficient for our needs at the moment.

We predominantly don't use the GUI interface. We are using Terraform as our infrastructure and code provider to manage and maintain all of the Azure components that we are using. They're offering all the integration and providing it through the APIs.

We have come from hosting on-premise for customers, or they've done it themselves with SQL. We've now taken a cloud offering for the equivalent services of standard database management and the inbuilt backup and restore offerings. The scalability is probably the biggest feature that we are benefiting from by being in the cloud.

We haven't had any major issues that have prevented us from doing stuff fundamentally. For its implementation, sometimes, it is complicated to understand what your needs are. It would be good to have a few use cases that provide different cloud variations that match on-premise installations and show how they can be moved to the cloud a bit better.

Its pricing is complicated and can be improved. We need a better offering. Making it cheaper is always a good thing for us.

I have been using this solution for two years.

We haven't had any issues. It has been up and available and working when we needed it to. We haven't had any outages that we're aware of.

There are not many users at the moment because we're still in pre-production. We're sort of in beta testing at the moment.

It probably has 50 users currently. It is not a very large tool. We are planning to expand its usage as we build out our actual software ourselves, which we're still working on. We'll be making that available to customers, and we'll be offering that as a global opportunity for customers.

I have not been in touch with their technical support.

We were just using Microsoft on-premise SQL, and we've migrated to Azure in the cloud. It basically is like for like, as far as we're concerned.

It depends on which area you're coming from. If you're using the GUI, it's relatively simple. Understanding what your needs are sometimes is a bit more complicated. Understanding the availability of things like Elastic pools took us a little bit of time to get our heads around but, otherwise, it is pretty simple. They could provide some use cases for this.

It is hard to provide the deployment duration because it wasn't just Azure on its own that we were having to deal with. We were taking our on-premise product and converting it. Preparing the infrastructure and doing it via the likes of Terraform took us probably about three months overall, but that was more about getting up to speed on the tools to do it, as opposed to individual components such as SQL.

The pricing is actually complicated, and that is probably one downside of it. In some respects, although we can plan for the costs on a month-by-month basis, we are finding it hard to project our costings for it. 

Fundamentally, Microsoft is offering two pricing models, and it is challenging to understand the differences between the two. We're basically on the DTU model at the moment. That may change in the future as the size grows, but it is one of those things that we'll end up monitoring as we progress. 

At the moment, to get a reasonable response, generally, the price is a little high for us, but it is one of those things for which we know that we can do improvements on our code. So, it is not just the service that's the problem; it is some of the things that we need to do as well.

I would recommend it depending upon the use case. If you need an on-premise service, then you would choose the on-premise SQL, and if you need a cloud-based one, then I'd suggest SQL on the cloud. The scalability of SQL in the cloud is far simpler than the scalability of SQL on-premise. This is one benefit that the cloud edition has over the on-premise version that people could consider.

I would rate SQL Azure an eight out of 10.

• Azure SQL database
• Office 365 mail server

We are a solutions provider and we have implemented this solution for many organizations. With these customers, we have managed to reduce a lot of infrastructure budgets and to provide an eco-friendly setup. Organizations can reduce, by a lot, electricity consumption and simplify their cooling plant setup.

It needs to improve the security features, because people still aren't confident enough to use a public cloud.

I've used it for one year alongside Office 365 and Windows VM.

There wasn't much except some issues faced when migrating into the cloud.

Not much.

No issues encountered.

It's very good.

They have very good support and lots of online training as well as having seminars and customer support available. I have joined many sessions through the Microsoft Virtual Academy.

We didn't use a previous solution.

It's not complex and, in actual fact, it's easy. Ready made set-ups are available any time.

The pricing is good, but there is still a gap if you are going to manage a large setup and a big growth of an organization. If that's the case, then pricing will be big challenge especially the pricing forecast and your analysis of growth and IT budget.

I have done some studies of SalesForce AWS among others .

It's a nice, very advanced technology based project that is very secure and cost effective cut edge technology. There are lots of cost and technical resources that can be cut while implementing this solution, to manage cost budget IT infrastructure for any organization.

It is simply our relational database.

It has cut our costs. That's the big thing.

Cost savings are the most valuable. The DR/high availability is also valuable. The failover group with the built-in DR/high availability features is probably one of the easiest things.

Its automation can be improved. SQL Server Agent was a very big part of the on-prem tools. While moving from on-prem to the cloud, redoing some of such tools was very cumbersome in Azure. There was a whole new set of technologies and methodologies. It should have easier automation-type features to be able to implement such tools. It should have almost a SQL agent type of substance built into that.

I have been using this solution for five years.

It is very stable. It has been in our production environment for three and a half years, and we have had only one significant outage.

Its scalability is pretty high. Its ability to scale is very good. We're actually in the process of migrating on-prem to Azure, and its scalability is very easy.

In terms of the number of users, there are probably a hundred technical people who are leveraging the technologies. They are developers, administrators, and the BI group.

The setup was pretty straightforward. The networking aspect was non-intuitive, and it was probably the biggest stumbling block when we initially set it up.

We have our DevOps processes that we follow in our deployment, so we establish those initially, and there was a significant amount of testing done prior to putting it into production. On a scale of one to five, it was probably a three in terms of time and effort to get it all implemented.

For its maintenance, there are probably five or six of us, but one person can also maintain it if required. 

I don't have specific numbers, but we were able to cut down the size of our data center by 80%.

I have an annual spend number, and it is in the hundred thousand dollar range. There are no additional costs to the standard licensing fees.

Even though you have to look at the cost numbers of what you're going to be charged on a monthly basis, what you have to also remember is that your application may need a lot of rewriting and things like that. You get charged not just for the monthly costs but also for the transactions that occur. If your access to the data layer is not so efficient, your costs will go up because you're pulling far more data than you potentially need. These are hidden costs that nobody ever considers. If your application is not written very efficiently, you may actually increase your costs over on-prem versus cloud.

We are a Microsoft shop. The biggest thing that we probably looked at was AWS. We also looked at some of the Oracle cloud solutions, but we went with Azure only because it just integrates with all of our stuff, and it cuts our costs.

I would rate SQL Azure an eight out of ten.

What I like the most is the processes and the easiness of deployments.

What I don't like is the personalization of an instance is difficult to deploy. Sometimes it's hard if you want to make a cluster of SQLs on Azure; it's not a good approach, but sometimes it worked out for me.

If I have to do something very specific to the instance, sometimes I am not allowed to leave those types of configurations because they need it to be broader. They are not at the level that I need to make the configurations that I want.

The configuration is the only area to be improved. Everything else is what it is and what we expected. The configuration is the area that is most cumbersome.

I have been using SQL Azure for two years.

I have the latest version. I always update to the latest version.

It's a very stable solution.

SQL Azure is perfectly scalable.

We have a team of 20 to 25 developers who are using this solution for development. 

Also, we have thousands of clients for the databases that are using it.

Technical support is fast, it's reliable, and they are knowledgeable.

If your problem is in the knowledge base then support is very good. If it's not in the knowledge base, then it's central and not on the Microsoft roadmap.

The initial setup is more complex than it is straightforward.

The easiest deployment requires an hour. If you have a one-by-one project that consists of migration and replication, it can take several weeks.

Using SQL Azure really depends on the settings that you want to deploy, or the amount of money that you want to spend. If you are deploying and thinking that something will grow so that you can align your income to pay per use, then it's pretty good. 

If you are considering something where your payments or your income is not related to pay-per-use, you may consider using it on-premises during the beginning. It really depends on your settings.

Overall, this solution is pretty good.

There are still some areas that have to develop, but I would rate SQL Azure an eight out of ten.