SQL Server Reviews

It is used for everything under the sun. We're currently using it for a health pass for a medic aid information management system. It is also used by companies in banking and retail.

We are using SQL Server 2014 on Windows Server 2012 platform, and we also have SQL Server 2016 on Windows Server 2016 platform. I have primarily worked on the hardware, but I am now also working in the Amazon AWS cloud.

The entire solution that we're deploying is built on Microsoft SQL Server as a database engine. Our solution is completely engineered for that, and if we attempt to deploy it in any other database engine, it is going to be a huge nightmare.

Microsoft SQL Server is one of the better database administration software packages out there. It runs primarily on Windows Server platforms, but it can also run on Linux platforms.

Primarily, the data replication and the backup areas can be improved. It should have data replication capabilities and uptime capabilities.  The native SQL Server Backups take more time than do the backup processes from LiteSpeed, and the backup compression is a little less.  

I have been using SQL Server since version 6.5, which came out about 30 years ago.

It is very stable.

It is very scalable. You can run the database engine on the C drive, or you can run it on a large cloud array or a disk array. Currently, we just have developers and testers accessing it.

Technical support from Microsoft is very good.

If you know how to set it up, it is easy, but you have to learn that over time. For a new user, it is detailed. You need to have the right things in place at the right time before you actually install the software.

To create an instance, it takes about an hour overall. This includes deploying the basic system, applying the latest service pack, and then applying the latest cumulative update.

It was an in-house job. In terms of maintenance, the number of staff members required would depend on the implementation. It requires coordination amongst teams. It is a team effort. The database administrator creates and runs the jobs that create the backup file. You need to have somebody for copying the backup files to offline storage. You also need to have system administrators for setting up the hardware.

I would advise others to just be familiar with Windows concepts.

I would rate SQL Server a nine out of ten. If you're familiar with Windows concepts, it just works.

SQL Server is easy to use. As a Microsoft product, it has an intuitive and user-friendly interface.

The product performance can become slow when the data reaches sizes like a terabyte.

The product is stable. 

Our organization has a maximum of 100 SQL Server users. The scalability needs improvement.

We have used other solutions such as PostgreSQL, MySQL, and Oracle. 

SQL Server is often chosen for Windows platforms due to its compatibility. For other development environments, like PHP or Java, we might select MySQL or PostgreSQL, respectively.

The setup process is straightforward. It involves running the setup file, configuring general settings, setting up a user account, and creating a database. After that, you can create tables within the database and start using it.

The product's price is reasonable. It requires a one-time license purchase, unlike Azure SQL, which operates on a subscription basis.

SQL Server's performance is good enough for medium-sized applications. The security features are adequate and effective.

I rate it a seven out of ten. 

We use it for both development and administration purposes.  

It's serving our data solution needs okay. 

I like that it's the Always On Availability Groups setup. It ensures our servers are always running.

We need it to support Linux for better troubleshooting flexibility.

I have been using this product for five years. We currently use the older versions, SQL Server 2019 and 2017.

We will soon migrate to the 2022 version. 

It works perfectly. No issues there. 

So, it is a stable product. 

There are around 300 to 500 end users using it. 

We use it for our on-premises solutions, virtual servers and SSAS, SSRS packages. Also, our applications are .NET based, so it made sense to use it. 

The initial setup is very easy. It is easy to understand. 

It is an expensive product. 

I would recommend using it , but it's best if you already know how it works.

Overall, I would rate the solution a six out of ten. 

This client, specifically, is using it for Dynamics NAV. I don't know what they're calling it today. Microsoft changes the names all the time, 365 NAV Dynamics. This is ridiculous. We're using it for that, and we have more of a niche CRM database called Tour de Force. It's owned by a company called White Cup. They own a bunch of companies, and it sits on Microsoft SQL, as well.

One of the things I most like about SQL Server is the log shipping piece.

I have another client who uses GP, and they use Power BI to take the data out of the back end. I'm doing an IT assessment there, so I'm not really involved in that specifically, other than the fact this person has too many rights.

I have an auditing background, and I spent 25 years doing IT auditing as well. I understand I'm not a programmer, but I've been involved with enough of them. The log shipping really is one of the greatest features. It is not the only database you can do it in, but that was one of the better features of it because I am a backup nut. We use Veeam Backup and Replication to a local mass storage, but then we fully replicate everything in Veeam to another site with the exact same server set up at our other location. But I wasn't satisfied with that from a disaster recovery point of view. My IT company was, but I was not. I said, "I want to do SQL log shipping. I want to do an SQL backup and SQL log shipping and move it to Azure in the cloud," which is what we do every day. We have an hour by hour backup, in addition to our multiple nightly backups and our replication to our other site, and we've had to use it and it worked. This is a great feature.

Somebody who knows it would easily say, "No problem," because we set up our log shipping in about three hours. We sometimes have challenges with it in terms of timing, of getting it out, backing it up, and sending it to the cloud. There are always the glitches, but I get a daily report on what's going on. Around 30 backup jobs are running at all times, because it is a big company. It's a 200 person company.

In the next releases, I would only like more enhanced backups and more restore points. Data backup and cyber protection are the number one things everybody should be thinking about now. They may not be, but they should be. We're going to go to the Azure environment because that really is a duplicate of the on-premise environment, just somewhere else.

I would say that I have been directly involved in the ERP world for as long as I can remember, but SQL really didn't appear on my radar until the mid-90s. I know that early GP was out there. I believe it was on an earlier version of SQL. I use it heavily now because I'm the CIO. I'm a consultant, but I'm a CIO of a client for almost nine years, where we have two major databases sitting on SQL.

So I have always been involved in a Microsoft environment.

We are always deploying the latest version. I have multiple clients with SQL and Oracle. But my big client is always up to date.

Whether it is deployed on the cloud or on premises depends on the client. My big client is on-premise and we have a two year plan to move to the cloud.

In terms of scalability, I haven't seen any problems with it. We have 120 users. Every once in a while we get a record lock in our data. It's very rare though. Once every six months somebody hits the same record and same night. It's very rare. You go out for a minute, come back in, and it's over.

I don't have any Fortune 5,000, Fortune 2000, or Fortune 1000 companies. According to the governmental definition, they're small, they're SMB, but my big client is 200 million. To me, that's a lot of money-

But in the eyes of the government, they're still a medium company. I have clients with 1,000 people, but they're only a $50 million company. Those are not for profits. They're paying people 10 bucks an hour. It's very hard to categorize that if you're looking at it from a business perspective versus a technical perspective. I have a client with 1,000 people with 82 sites. So that's a technical challenge, but they don't have the same kind of money as the other people do.

It's a different way to categorize it.

Calling Microsoft is like calling Verizon. I wouldn't do that. I have a middleman that I work with. It's easier because they have more clout than do. I know that.

This client, the big client I've been talking about, had some ancient DOS system from the 70s when I got there in 2012. They had no data dictionary note. I think it was running on an early version of Unix on a Compaq machine. When I got there, it was 15 years old. The thing was still running until six months ago. You can't believe it. This thing wouldn't die. I tried to make it die multiple times, but we converted from that system onto Dynamics NAV.

It's a two year undertaking. The SQL was stable all the time, never had a problem with it.

In terms of the initial setup, you probably need to know what you're doing. I haven't seen any real laypeople get into the tables. I know it's possible to learn. Things like Power BI have made it easier, but if you don't know what the tables are you have to be a very methodical person to be able to do that stuff. We use a company called ArcherPoint for dynamics. They're one of the largest dynamics dealers in the country, and they have their stuff together. This woman I use there knows her stuff. She knows SQL very well, and my IT company also has a senior guy who they often talk to, and it always seems pretty straightforward, whatever they do. It's never a big install.

Usually a few hours and it's over.

This client has money, so I never hear any complaints. It seems reasonable to me. I think the biggest problem that Microsoft had back in the early 2000s was that the pricing of SQL was a nightmare. You could call five Microsoft people at Microsoft, and you'd get five different prices. Microsoft has a problem. Well, they have lots of problems. They characterize themselves as perfect.

From 40 years ago, I already knew well in advance of the clients that there is a security hole. I'm looking at Business Central, and somebody who has a global super admin of the tenant can get into the client's accounting system if they have full rights to their 365 email system. That's a big security gap. Their IT company shouldn't be in their financial system. Why would that be? I came up with the idea after talking to five different Microsoft people to just buy another tenant that they don't have access to and they said, "Oh, that works."

SQL Server is a good mainstream application that has been around for quite some time, and I like when things are around for a while. I don't like to be the first kid on the block. I remember when Power BI first came out. I waited a year and a half to use it.

The big thing for NAV was to get reports. We still use it, but we mostly abandoned it. It's really not working as well as I would've liked. And that reads SQL tables. While that was great, you had to trust the person who wrote it, that it would include all the data you needed. There's a big trust. We often found lots of problems with it, so we decided to just program all these reports inside the application. That worked really well. The thing I don't like is, I know a lot of people don't know about the backend security of SQL. They think others cannot get into their system and I tell them they can, they have the SA password. People are shocked. That's a hole that they should plug.

They should plug that and make that more apparent to people. When I did auditing, most clients had SQL based applications, and we'd always say, "Who's got the SA password," and they'd say, "What are you talking about?" Then we would tell them, and there is all this SQL injection stuff that used to happen. I haven't heard of any hacking through the back end in a while. Because you're talking about cybersecurity being so important now, people can hack in and get into the back end, although 99% of cyber is ransomware through email.

The risk is probably still low, but I try to close up all the gaps if I can. Clients don't know about this stuff. They don't even know enough to ask. I find a lot of IT people don't even think about stuff like that.

I'll ask a client if they back up their data and how often. If they talk to their IT guy? If they say, "Once a night," I ask, "Okay, what if it was the middle of the day and you go down? You lose all your data." I ask if they have ever heard of SQL log shipping. They start stuttering because they don't know how to set it up.

It would be great if Microsoft was more up-front about how to do that stuff. It's a great feature.

On a scale of one to ten, I would probably give SQL Server a nine. I don't give anybody a perfect score, certainly not in the technology world. Oracle is out there. NetSuite is just giving it away. You have a lot of other applications not running on SQL, like Intacct, who are creating proprietary, non-Microsoft things to come against what Microsoft is offering like interoperability with different applications. They are really pushing a different environment. I think Microsoft is going to win, but Sage is not a small company.

We have all these big titans fighting each other.

We provide support services to clients. We find that some of our clients are running the latest system while others are still on Windows 2016, others are moving to 2019. Some other clients take time to upgrade. If I interact with five clients, I'll basically be in five different environments.

Our use case for the SQL Server is for transaction processing. We store all the transactions that occur. For example, if you now purchase something from the point of sale, all the information about the good you are purchasing gets stored on the SQL Server. 

When you perform a transaction that information is stored at the bank that owns the point of sale and perhaps even your bank, where your money is will be stored in a SQL Server.

All the people in all of the organizations, which are involved in the process use SQL Server.

If your transaction goes through my server, I store part of the transaction there, and if I have to route that transaction to Visa or Mastercard, they have their own SQL Server, and they also store the transaction up until you get receive your goods at the particular merchant. Almost everyone in that transaction stores the information on their respective Microsoft SQL server.

The most valuable feature would most likely be querying. We query a lot, we use a lot of stored procedures. As for other features, such as replication and all other more fancy features we don't use them the most. I do not know, but perhaps the DBAs would be the best people who know of the features that they use, but as far as how I use it, it's just for querying and running stored procedures. We use the bare minimum features.

We do not know all the features of SQL Server.

If SQL Server could perhaps run on Linux, that would be good. Most of us prefer Linux and I've used a lot of Linux. I understand that SQL Server is quite powerful, but I'm not sure if the functionality is there, but if it could be used in an open-source type of environment, it would be very good.

I have been using SQL Server for approximately 10 years.

SQL Server is stable and is a high-performance database. We do hundreds of transactions per second, it's fairly robust, it does not struggle. Mostly, if your hardware is strong enough and you've set it up properly, then you can actually perform a lot of transactions per second on a SQL Serving installation.

The scalability of SQL Server is relatively easy. if you are in a Microsoft environment, then I think that it relatively it should not be that difficult. However, I haven't been on a project whereby we have had to scale.

SQL Server is suitable for all companies in my experience, ranging from small to large enterprises businesses.

I have not dealt much with technical support, because most of the time when we have issues, we go online. If it's a Microsoft issue, then we go and read up what that issue is. If there's an error, then there are places on the Microsoft support system where we are able to enter in the error code and it is able to tell you why you have that problem. As far as dealing or interacting with people or technical support from Microsoft, I have not done that.

I use MySQL and when comparing the solutions I have found the SQL Server is much more professional, and it's quite big and robust. MySQL is a community of people who are contributing to a project and you have to hack them in order for it to work. But it is quite good as well.

The installation is straightforward and not complex. However, it depends on some of the features that you may want to use. I think it is simply because you only need to tick whatever functionalities you want to use and the ones that you don't need to use, you don't select them.

Most of the time we are doing the implementation from scratch. If it's a big bank, then they would normally have dedicated people who deal with SQL. However, it depends on the customer.

There is some maintenance that is required, such as updates and tuning. We need to find ways of filling up the data so that it doesn't get stale but normally with regular updates, you should be fine.

I cannot comment on the price because I find that the organization already has a license when I arrived. I have not had a sneak peek at the price. When you join an organization, they tell you we are using the 2018 version and that someone purchased it. I don't know who purchased it, I'm not privy to that kind of information.

My advice to companies that are wanting to implement the solution is they have to make sure that they've have a proper skillset. When you have the proper skillset or people who are certified it would make for a better investment into the product. When you are certified, then you know the system in and out and you should be able to have the best implementation for the type of business you have.

I rate SQL Server an eight 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 developed a product that is using five or six databases supported on SQL Server. 

It is a very user-friendly solution. It is easy to manage the databases and troubleshoot any issue. It is a perfect solution for the volume or transactions that we need to manage.

The way to make cursors and manage raw data in rows can be improved. Currently, the way to construct or build these cursors is very hard, and you can waste memory. You need a highly skilled person to make it more efficient.

It can also have support for Cubes, which is the organization of data in different dimensions by using MDX languages.

I have been using this solution for ten years.

It is very stable. I would rate it an eight out of ten in terms of stability.

It is scalable. You can get scalability by using the link servers, or you can create another instance in another server and make a link with that server. It is very quick.

We have around 50 users of this solution.

I have not interacted with them.

Its initial setup is easy. It takes a week. One of the things that you need to pay attention to is the collection.

It is a nice product. You can use it as you want. If you don't know how to use it, you will waste it. Oracle is more powerful than this, but it is great for our needs.

I would rate SQL Server an eight out of ten.

We are a company that produces stock market analytics data and we are working on creating an alerting system for our customers. We use Microsoft SQL Server in our development and I have a lot of experience with it.

In my development role, I store about two gigabytes of data every month.

One of the big advantages of this product is its performance, where it works well when the data is not complex.

If you have a lot of data and you want to perform computations on it, you will have problems and the performance will be degraded.

There are problems when you are dealing with Big Data and it doesn't scale very well. For example, in Hadoop, you can partition your data very well, but in SQL Server, you can't do that. If it could handle horizontal scaling then that would be an improvement.

We experience latency at times when there is a lot of data being processed. In Iran, there is a specific time when all of the markets are open, and a lot of people are using the data to make decisions. Performing actions at that specific time gives us a lot of problems because of limitations in SQL Server. The problem seems to be caused by writing a lot of data to the table at the same time.

Improving the intelligence for managing the SQL server would be very good.

I have been using SQL Server for the past four years, and my company has been using it for approximately seven.

I have seen that this is a very stable product.

We had trouble scaling the solution to handle larger volumes of data. We have been able to scale out by adding CPU power and RAM, but other than by increasing the physical solution, we have not been able to do it very well. For example, we have not been able to do what we have done using Hadoop.

I used Oracle in the past, approximately four years ago. That was stable, but the performance in SQL is very much better nowadays.

The initial setup is very easy.

Our in-house team deployed it by researching how to perform the setup and configuration. As a developer, I just let them know what I need from the product. For example, for my role, I have a lot of writes and I want them to optimize for that situation.

If there are some simple features that I just want to enable, then I can do that myself.

I would rate this solution an eight out of ten.