SQL Server Reviews

We are using SQL Server to build and store our whole company's data in our data warehouse.

SQL Server is very good, it can be used as a transactional database and used to support the data warehouse. Additionally, the ANSI-compliant satisfies our database properties.

I have been using SQL Server for approximately eight years.

I do not think SQL Server is suited for a typical database warehouse environment. However, people do use SQL Server for data warehouse environments but the best use case is for very small databases. If somebody wants to store more than 10 TB of data querying then the performance really degrades. The performance should be improved in the future to allow more scalability.

The scalability issue could be why many are moving to solutions, such as Teradata or other high-end on-premise solutions. Additionally, cloud solutions offer better scalability options.

The technical support from Microsoft is very good.

If you are looking for a small setup and do not want an open-source solution or invest too much money in your database then SQL Server is a very good choice.

I have evaluated other solutions, such as Teradata.

I rate SQL Server an eight out of ten.

While I don't like SQL Server so much, the selection was for clients so we needed to utilize it. Of course, one thing is that as great with this and other Microsoft products is that it's quite well documented and there are also light versions available. If you need to do something, you can also try it somehow on your own computer and so on. 

If I'm helping a client to define what they need to have or what they need to do in a public sector procurement process quite often we cannot fix the database as it would be limiting the competition. That's why we never rule out the SQL Server; it should be included as an option at this level.

The solution is stable. 

I haven't had issues with sizing or scaling.

If it would be more powerful it would be pretty nice. The performance is not always the best. 

Whenever we were setting up the databases, there were some character problems that did not exist on some of the other solutions. However, the exact issues are hard to recall and list. I prefer Linux solutions. That said, when we began the previous project, Microsoft SQL Server was not available for Linux platforms yet.

Nowadays, it's my understanding that there are different versions. I haven't been checking if the current versions are supporting Transact-SQL and stuff like that. I remember that when we had the first Linux-based SQL Servers were introduced, they were, of course, a bit limited from the feature point of view. Whenever it is Unix or Linux or whatever platform, it's easier to manage them and to handle them whenever you are doing remote work. 

I'm not so big fan of the Microsoft platforms as a server. However, whenever it's needed then it's needed. If you are a consultant, you need to adjust your whole mindset to whatever it's needed.

I've used the solution, approximately, for several years. However, there have been gaps. There are different phases, however, I could count something like seven years where I was in an architect position in any project where this server was utilized. 

For the needs we had for the client it was sufficient. Whatever we needed to have - whether more server or more virtual server, the performance for the platform wasn't as good as I would like. I'm not entirely satisfied.

I haven't been utilizing the scale capabilities. I don't have a clear impression on that, however, for our purposes, we've never had an issue.

I've never dealt with technical support. The databases were handled by the service provider or service operator of our clients. We have a public sector client and they have their partner who is handling or is responsible for the platforms. Therefore, if we had a problem with the platform, the right bureaucratic way to go about getting a resolution is that we contact the service provider they have. They probably contact Microsoft. The process is bureaucratic.

I'm also familiar with other servers such as Oracle. While we must do as the client wants or needs, if I could choose, I would probably utilize databases like Oracle or open-source databases more often. It depends on the cases. That said, quite often I'm in a position where I cannot suggest the technology, so I use what the client requests.

We didn't pay anything for it as it was provided for our client by the provider. I cannot say about the enterprise licenses or anything. When we began the work and we needed it for our own machines, I prefer the solutions which are available, of course, as open-source or are free. And Microsoft had this express version of their database which we can utilize as well. In that sense, it is okay, however, of course, in general, I don't know.

I've been working for a client as a consultant so I'm helping them with deployments. With one client, we're using on-premises deployments. Our client has their own service provider or service operator so they have their own IT partner who is handling their databases. If I have understood it correctly, the databases were on-premises for our client, however, it's a bit complicated when you are having and dealing with large-scale public sector actors in Finland. There are plenty of kinds of players involved.

Whether or not I would recommend the solution depends. If you are utilizing some solutions where you need the Microsoft platform-based database, it's completely okay. And if you have, for example, the solutions where you have utilized Transact-SQL or whatever, it's okay. However, if you have this kind of situation where you can make your own choices freely, you have options. And if you're utilizing Java or C, et cetera, quite often the path or logic would go towards some of the databases on the Microsoft side.

There is no clear answer. Quite often when you begin to think about your solution or you think about what you are building, the database is the first thing you decide on. There are other factors too, such as a business case or if you're just building from scratch and so on and so on. I wouldn't like to say that I never would recommend it, however, if you are building everything from the scratch and you can make all the decisions, likely it is not the first option you have or I'd suggest. 

I'd rate the solution at an eight out of ten.

The solution is very fast. 

The data is reliable and I can normalize the database and normalize the data so that I can collect whatever information I need. If I collect the data correctly, then I can share whatever report I want.

Normally, when the data is in the database, it will always be a long-term information holder, instead of putting it in Excel or something like a spreadsheet or something like that. 

For me, the initial setup is very easy as I have years of experience with the product.

I could use some more guidelines about making the correct queries to understand the structure better. I'd like to have a better idea and to understand how to make a nice query, which is good for the system and good for the hardware.

Sometimes you have to have different data in different tables and you want to merge them into something together. I'd like to be able to do this in a different way. 

Sometimes I need to have more optimization. I want to understand how can I optimize this or that? Especially now, when we're working with a lot of camera information, where we are using a lot of cameras for photogrammetry, we need to take this data and put it into the SQL Server and we would like to be more flexible with the data.

With so much data, things can get slow, which is why I would like to be able to understand how to better optimize queries. 

Those who are not familiar with the solution can find the initial setup intimidating and difficult. 

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

I don't have so much experience with scaling. It's my understanding that that task is a specialist job.

I have dealt with technical support in the past. I'm happy with them. They have been helpful.

I'm not only working with SQL Server. When I need the database, I will always do it in SQL Server or Maria Database or something like that.

For me, the initial implementation is easy, however, I know a lot of people can't set it up and believe everything is hard. It's difficult if you didn't know how to do it. You have to know, in the beginning, how to define what hardware you need and how many disks, for example. You need to understand if it should be a cluster disk or not. Long ago, it used to be hard disk access only. Things have changed. 

The solution does come at a cost.

I'm a customer and an end-user.

This solution is one of my favorites and I would rate it at a nine out of ten. I'm very pleased with its capabilities. 

Microsoft has a freeware option that might be called something like SQL Server Express. I'd advise new users to try to put that one up. It's easy to implement. If you need more data, then buy the correct server. The SQL Server is expensive, however, when you see how nice data is installed and how easy you can get access to it, it may be worth it. If new users need help, they can always go to YouTube to find answers for the freeware.

SQL Server has a steep learning curve, however, it's worth it to learn about it and understand it. 

We are using the latest version.

We can use the solution for the same application. On the database side we have Microsoft SQL and on the operating system side we have 2019.

I want to see one improvement and this involves the replication between the DC and DR. We have limited options at the moment and it does not lend sufficient support for the number of databases. This means we have a huge number of databases, topping approximately 2,000. For the moment, this particular replication is not supported by SQL. 

The support number of databases needs to be increased, as well as the database number of databases that it supports. That support cannot be found when it comes to the replication between the DC and DR. 

I have been using SQL Server for ten years. 

The solution is sufficiently stable. 

The solution is scalable. 

When it comes to the speed, knowledge and customer-friendliness of the technical support, we feel these to be good. 

We did not use other solutions prior to SQL Server. 

The initial setup is easy, flawless. 

It lasts a single day. 

We handed the implementation on our own. 

This involved a technical team of 15 people. 

There is a need to pay for the license for SQL Server. We have an enterprise license, which we consider to be fine. 

We have 10,000 customers. 

I would recommend the solution to others. 

SQL Server is good and I rate it as a nine out of ten. 

I love the developer version. Microsoft tells you about all the cool things they provided for everybody. You can develop and do anything with it. It's really good to learn. Oracle will not give you that much freedom, and Microsoft really kills it. 

You don't do anything with it but develop, learn, break, and push it to its limits. If there are problems, you show Microsoft or ask them, "what's going on here?" There is good community support for the developer edition, and that's what I really appreciate. You can teach people about it without limitations. You can have small databases created. You can keep it for a year and then work on it. It's a good thing for learners and developers.

The price could be better. It costs a lot, and competing databases like Postgres are free.

I have been using SQL Server for about ten years.

There are problems in all systems, and I don't see any difference between open source and proprietary solutions. SQL Server, Postgres, and Oracle are all vulnerable. There are no known issues per se, but any system can be broken. There is nothing special about this database.

SQL Servers and other databases are all scalable. I just don't see any problem with scalability.

Whenever we have issues, we talk directly with Microsoft. They are responsive, and they help.

I'm more into open source solutions, and I love Postgres. I've worked as a database administrator as well. But I really hate all the tools used to manage performance or backup or just any of those disaster, recovery, and availability solutions. I hate them. They really impose a lot of overhead in a demonstration and aren't really flexible. When you're in the cloud, you don't have to worry about most of those things. 

Some of them still exist, but the cloud providers do provide them and you stick to that. You enhance them or add some more features, but really the most hated feature is, making sure that your database really can recover from many kinds of disasters. Resiliency, the most important part and when that is really managed by the cloud online, the overhead costs  are removed. The rest is really easy. Performance is okay, and there are indicated spots for data because I work with financial data and a lot of it is our important critical data. So, the cloud is really the best thing that happened to us.

When it comes to the initial setup, most of them can be automated. For example, most setup settings for progressions, management, disaster and recovery, failover, and failback. Most of those things can be automated and provisioned into one kind of pipeline. Connecting that data to an application and even provisioning from the code repository through Jenkins. Those things are really easy to automate.

It costs a lot.

I would advise potential users to use SQL Server with Microsoft Azure. I don't recommend managing it locally.

On a scale from one to ten, I would give SQL Server a seven.

Usually, we use a lot of the vendor software, like ManageEngine, and stuff like that. They use Postgres, however, I prefer to use Microsoft's SQL server. We have a couple of servers and we integrate that information into it. I can run reporting and analysis off of that.

There's a lot of great features. I like T-SQL, which is wonderful. The backups are excellent. There's a lot of things that are much easier to manage. All of the features and functions within the SQL language itself, the store procedures, I really, really enjoy. The security has been excellent.

The initial setup is very straightforward. 

The stability is very good.

We find it easy to scale if we need to.

I would like to see better integration between their link server and other platforms, such as IBM, due to the fact that, a lot of times, you want to set up a linked server so you can be on SQL and pull data off of another server using that link server. Sometimes they don't play well together. There just needs to be better integration for those types of situations.

I've been using the solution for about eight or nine years at this point. 

The stability is great. There are no bugs or glitches. it doesn't crash or freeze. It's very reliable. The performance is great. 

Scaling is easy if you need to do it. You simply set up a cluster and you can just grow it up.

In our organization, all the end-users are pretty much integrated into it and using it. As far as developers, there are two developers and me that are using it.

We haven't used tech support as we used to have a business partner that wanted us to talk to them instead. Therefore, I can't speak to how helpful or responsive they would be if you need assistance. 

Here at the company, they used Postgres, and what I didn't care about it was that it was okay, but it didn't integrate with a lot of the other applications. I felt Microsoft did a better job of that.

The setup is pretty straightforward. The only thing that sometimes gets weird is if you have somebody that's needing an ODBC driver from another type of application back to the SQL server. It's usually that other application trying to figure out what it needs to connect to SQL. It's not really SQL's fault.

We are customers and end-users.

We are using both the latest version and a previous version of the solution. I don't have the exact version numbers on hand. 

I would advise new users first to get help implementing it unless you know the solution well, as there's so much that it can do. A lot of times you can actually make a little mistake. Say if you're going to go in a certain direction, if you get some advice, you may be much happier going in another direction completely.

In general, I would rate the solution at a nine out of ten. I've been quite satisfied with its capabilities. It's an excellent product that still has room for growth.

We use a tool called Tosca for automation and all the automation artifacts we are saving are on the SQL Server.

The solution is easy to use and provides similar features to other competitors.

SQL Server could improve by increase the performance, it cannot handle large amounts of data. I did not find any additional features compared to others solutions.

I have been using this solution for a few years.

The solution is stable.

We have not scaled the solution extensively, but I do not foresee any problems.

We have been using Hadoop and Spark.

The installation and configuration are straightforward.

We have a team of three people doing the backend maintenance and application support for this solution.

We did not encounter any issues that we would need support. 

I would recommend this solution to others for small operations. For bigger applications with large amounts of data and a lot of users, I would not recommend it.

I rate SQL Server a six out of ten.

We primarily use the solution mainly for databases on all types of applications.

SQL is the all around leading Database server

The solution is very stable. 

The scalability of the product is great.

We'd like the deployment process to be better in the future. 

The licensing is pretty expensive.

I've been using the solution for 20 years at this point. It's been two decades. We've used it for a while now.

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

The product scales well. If you need to expand it, you can do so.

We have 900 to 1,000 people using it currently.

I'm more on the architecture side and therefore do not directly deal with technical support. I cannot speak to how helpful or responsive they are.

We also use Oracle. We've used it for over a decade already.

The deployment could be easier.

While the deployment only takes about 15 minutes, you have to follow up with a lot of configuration.

We handled the implementation ourselves. We did not enlist the assistance of any integrators or consultants. It was all handled in-house.

We're paying too much for licensing at this time. They need to work on the pricing. They could be cheaper, however, it's also difficult to run the licenses in the right way.

We pay licensing fees on a yearly basis. 

We're a customer and an end-user. We don't have a business relationship with SQL. 

While everything is currently on-premises, we're making moves to shift to the cloud. 

We're using the 2019 and 2016 versions of the product.

I'd rate the solution at an eight out of ten. In general, we've been quite happy with its capabilities.