Microsoft Azure SQL Database Reviews

We use it also for database management, as a database engine.

We use it for different projects - mainly when we have lots of data and the customer can't afford to pay the license for SQL Server, which is not cheap. That's the main reason we use MySQL or Postgres or other databases. 

The management and the remote access in SQL Azure are seamless.

The solution is extremely scalable.

We've found the stability to be quite good.

It's the type of product that doesn't need much technical support assistance as it works seamlessly.

Some data types are not available on SQL Azure while it's available on SQL Server. It's a little bit limited in terms of functionality. The difference is not huge. You can go back and forth between them. We used to do this all the time. However, it is something to note.

Maybe they need to add the data types that exist in SQL Server, not in SQL Azure. That would make it better.

The pricing can be high in certain countries as Microsoft doesn't adjust for regional pricing. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. The performance is good.

The product is on the cloud. It's very scalable for that reason. If a company needs to expand it, it can do so.

Most of the time no one needs support on SQL products or services. That said, the support in Azure is amazing. We never encountered an issue that they didn't solve. This speaks to the quality of Azure.

We also use SQL Server. The main difference is SQL Server is a full-featured database engine, whereas MySQL is based on what we call a file-based database, which is similar to flat files as a database engine.

The recommendation of which to use is based on the use case. It depends on what use case the customer will need. If they don't have the capacity to manage their own server, I would recommend Azure, as it's managed. You don't have to worry about the management and administration.

The pricing is prevalent for everything Microsoft. The thing is, they don't allow different pricing for different regions. Some countries are price sensitive.

I'm an end-user.

I'd rate the solution at a nine out of ten.

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.

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.

We use it as a backend product. We are using the Managed Instance and the SQL Database.

The backup features are the most valuable.

Its compatibility with existing applications can be improved. Its compatibility is currently a little bit imbalanced.

I have been using this solution for about two years.

It is pretty good. It seems very stable.

It has good scalability. We have about a thousand users.

Technical support was very good. I would rate them a ten out of ten.

The initial setup is pretty easy. The deployment took about a day.

It is a good product for any new development or organization.

I would rate SQL Azure a nine out of ten. It is working fine right now, and I am pretty happy with this solution.

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.

We're slowly progressing through the delivery of our production system or landing zone in the cloud. Nothing is in production yet.

Its cost benefit is most valuable because you are charged per data unit instead of licensing. You can easily migrate your on-premise SQL to the cloud with a managed instance. That's what it is designed to do. It is easy to take your on-premise or older SQL instance and move it to the cloud. It makes it easy to get off your on-premise SQL and start utilizing the cost benefit of the cloud.

I'm not really a SQL DBA, so I can't go into the depths of the areas that need to be improved. They can maybe make it a bit easier to educate people on how to develop SQL Server in Azure. They can provide some free seminars and webinars and more training in general for easier migration. I know there is some stuff on Microsoft learning, but it would be helpful and useful to have more up-to-date content.

We've been dabbling with it for the last couple of years. 

Based on our experience, it is very stable and very reliable.

It has got Microsoft's backbone on it. It is very scalable. At this stage, we don't have many users because we're still busy migrating over to Azure cloud. In the next year, we'll probably have close to a million customers because that's what we've got on our books.

I have interacted with them. They are very good for out-of-the-book solutions, but when we get to integrations with non-Microsoft applications, it can be a little bit more tricky. You also have to involve the vendor of that specific product to deal with problems related to integration, but, in general, Microsoft's support is pretty good. I've never found it to be poor in any way.

For the number of customers we have, we probably only need three or four people, which is not a lot. If you look at it that way, it is actually quite cost-effective.

It is beneficial in terms of cost because you are charged per data unit instead of licensing.

I would absolutely recommend this solution to others. If they are going for Azure, they probably don't have a choice. I would advise others to get used to all the options and ideas of SQL PaaS, SQL managed instances, and SQL on VMs. They should get their head around which one is best for their company. They should make sure that it fits their company's vision of where they want to go with their databases because it may or may not be the best solution for everybody. That's why there are a couple of options, so just make sure to select the right one.

I would rate SQL Azure an eight out of ten. It is best in many ways. There is nothing better than this from Microsoft from the database aspect.

We primarily use the solution for its Data Lake and Data Warehouse, in both cases for our customers.

The solution is easily integrated into other SQL solutions. It's flexible in that sense.

The solution is a fairly mature product. It provides good stability.

The initial setup isn't too difficult.

There is very good documentation. It's unbelievable, the amount of documentation on offer through Microsoft's site.

The security features are quite good.

In terms of management, you can't really pause things. It doesn't allow for that kind of capability.

From a security perspective, although their features are decent, they can always be improved upon, updated, and refined to help protect clients better.

I would love it if that had dynamic data masking and features of that nature.

I've been using the solution for two years at least at this point.

The stability of the solution is pretty good. It's a mature product, so you don't get bugs or glitches, and they update it regularly. It doesn't crash. It's reliable.

The solution can scale well. That's not a problem at all. If a company needs to scale, they can do so easily.

Microsoft's technical support is great. We're satisfied with their service. They have a pretty extensive online database and an online community that is quite helpful. It's all very helpful.

If you need to reach them in person, you need to have a licensing agreement in place. If you purchase that, you can get more personalized assistance.

We previously used SQL on-premises servers. It's very easy to migrate over to the cloud if you have that setup. It's basically one-to-one.

The initial setup isn't complex. It's pretty straightforward. However, it does take a long time to provision and manage everything. It can take a couple of hours typically to deploy the solution.

You do have to pay for technical support. If you have it in your licensing agreement, you will gain access to a team you can call if you run into issues.

I'm not sure of the exact licensing costs. From a cloud perspective, a client would be charged based on consumption, so the pricing would depend on elements such as how many users or how many queries (and how complex), et cetera. 

I do know that it's competitive pricing, however. Most solutions of this caliber are around the same price. They compete with each other.

We're Microsoft partners.

The solution is constantly being updated. We're on whatever the latest version/update is at any given time.

We're a consultancy, so we work with a variety of clients and adjust solutions based on their needs.

I'd advise new users to take advantage of the documentation on offer from Microsoft. It will really help them understand the solution.

Overall, I'd rate the solution nine out of ten.

We use SQL Azure for the SAP application, an accounting software that facilitates transactions between different departments. The financial trends we run on SAP are supported by SQL, which is the back end of that application.

The reason we moved to the cloud was for the convenience of not having any physical hardware to maintain. As a technical person, this has reduced the amount of maintenance I need to do, allowing me to focus more on backups since the Azure infrastructure takes care of itself. Additionally, this is cost-effective for the organization since we are not spending much time on servicing infrastructure. Furthermore, it is convenient because we only pay for the time we use the solution, and are not billed for the time we are not using it.

Microsoft could improve its documentation and support. Without the necessary knowledge and expertise, it can be difficult to navigate the platform and find a technical person to guide us through. There is not currently enough documentation available to make it easy to use. If I had not been certified in Azure, I would have faced a lot of difficulties.

I would like reports attached to my phone if there's an error that occurs within SQL Azure or if there are updates that need to run, I would like to receive notifications.

I have been using the solution for two years.

The solution is stable. We only had one outage last year and it didn't even last for 30 minutes.

The solution is scalable.

The technical support has always been good, but recently I had two encounters, last year when I spoke to a consultant from Africa these people provided support, but it almost sounded as if they didn't have enough knowledge. They didn't have enough technical knowledge of my problem to call me back after they had consulted. The support didn't feel like it was Microsoft support contacting me.

Neutral

The initial setup is straightforward and only took one day.

When looking at the long-term expenses associated with running software on an on-premises server, the costs are almost equivalent but when we include insurance for devices, onsite fees for servers, and other related costs, we may find that this is a cost-effective solution.

I give the solution a ten out of ten. I don't see anything wrong with SQL Azure. I believe it's actually an advantage because previously we had to install SQL solutions on a physical computer. The good thing is that has been translated onto the cloud and that makes it a very good feature. SQL Azure itself, is a robust application that does a lot and integrates with a lot of applications. The reason I like SQL Azure better is that it's easily accessible and the setup is almost exactly the same as we do on the physical machines, but the good thing is there's no machine to maintain the grid.

We selected SQL Azure because it was recommended to us by the safety provider of our accounting software.

I recommend the solution to others.