SQL Server Reviews

We do data warehousing, and our clients are mainly large commercial Insurance providers in the United States.

It's easy to use and fairly intuitive. I do development and data analysis, so we do a lot of work with SSIS and SQL Job Scheduler. Deploying new databases is very simple with things like BACPAC. You don't have to do all the scripting for the database, then all the tables, keys, etc. It takes all that out of your hands.

One thing I don't like about SQL Server is the way they've set up security with users and groups. It just doesn't seem that intuitive to me. Adding some more explanatory information might help some. Sometimes the documentation is a little thin, but the same could be said about a lot of products.

I've been using SQL Server on and off since it first came out in the 1990s. Most of the people I've worked for are SQL Server shops.

I can't really speak intelligently about that because I haven't been on any of the real big ones yet. 

The complexity of the initial setup really depends. Obviously, you're going to need to know a few things and there are different ways to do deployments. I like the BACPAC, which is one of the features that come with SQL Server. It's a nice feature to deploy. BACPAC really handles all of the configuration for you. If you use that, I don't think you really need to know too much. If we're talking about a small database that holds a few thousand records, it doesn't matter what you're doing. You can't make a mistake because it's just not big enough.  

We do a lot of Azure-based on-demand type systems where we host the system or we host it in Azure. We do the work for them. So we don't really do a lot of those installs.

We're going a lot heavier into Azure and we're going to be dealing with lots of volume because insurance data is pretty voluminous. I think some of our clients don't like the idea of having one gigantic VM system to run the database. That's one reason why they're switching to Snowflake. We had to do some SSRS stuff in the past, and I think they're moving over to Power BI mostly.

I'd probably rate SQL Server nine out of 10. I don't think I'd give anybody a 10, but I think nine's about the best I can do. In my experience, it's been reliable and easy to use.

We set up SQL Servers for developers who develop applications for data mining. Our clients are generally small or medium-sized businesses. There's also a SQL Server Express that many software vendors use to support their applications. That gets installed often—usually as part of the application installation. 

It is fairly easy to work with. I like the high-availability options, like mirroring for example, and the high-availability groups. It's quite an interesting feature that enables high availability for the SQL Server. I think it's important. So that's the feature that I'm particularly interested in and it works pretty well.

The Management Studio is a pretty heavy piece of software, and it's sometimes slow. I would recommend making an express version of the Management Studio, which is lighter and has fewer features but is a little faster.

"Using" is the wrong word. We mostly set it up for others. The last time we set up an SQL Server for a client was about a year ago.

We haven't had any experiences. The software hasn't been unstable or glitchy in our environment so far.

In terms of scalability, it would be closed to a high-availability group. So I would say it varies in scale. 

I would rate it nine out of 10. Nothing's perfect.

We use SQL Server as a relational database mostly for the application backend activities and integrations.

The SQL Server is low maintenance, it does not require advanced technical skills to maintain or use it as you might in other similar database solutions. You need some knowledge on how to access the solution and how to query it but it is fairly straightforward.

SQL Server could improve by enhancing the integration abilities, adding more inbuilt data security features, and simplifying the maintenance.

I have been using SQL Server for approximately 10 years.

SQL Server is stable.

The solution is scalable and flexible.

We have approximately 15 people using the solution in my organization.

The technical support from Microsoft is good but we have learned and received the most help from the online community.

The installation difficulty level depends on the use case and environment. For example, if you need to deploy it on multiple nodes or have large amounts of storage it could increase the difficulty level. 

We have a team of approximately five database administrators and application developers who handle the setup and maintenance of the solution.

There is a license required for the use of SQL Server and we are on an annual subscription.

I rate SQL Server a nine 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. 

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 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.