SQL Server Reviews

We use SQL Server for storing all our company information, such as ERP, customer applications, and our wealth management systems. All of our data is stored in SQL Servers.

SQL Server is a very mature solution.

I have been using SQL Server for approximately 20 years.

SQL Server is a stable solution.

The scalability of SQL Server is good. It can scale up to thousands of times more data than I have. 

We have approximately 250 people using this solution in my organization.

I have not used the support from SQL Server.

The initial setup is simple it takes approximately 10 minutes. You only need to run the setup and you have SQL installed.

I have installed SQL databases and SQL Servers regularly. I did the implementation of this solution.

This solution requires one administrator for implementation and maintenance.

Some of the licensing are very expensive, such as the Enterprise license. 

The Express version is free. There are a lot of licensing options.

I would recommend this solution to others.

I rate SQL Server a nine out of ten.

I am an integrator of this solution and my customers use this for ETL and reporting.

This solution is user-friendly and easy to understand.

The stability of the solution should be improved in the next release. Sometimes it is great, sometimes it is troublesome. I would also like data conversion and the code pages to be a bit more straightforward.

I have been working with SQL Server for the past fifteen years.

Stability can be shaky.

This is a scalable solution.

I use to work with Informatica via the Oracle package and switched to SQL because it is cheaper and a bit better than the others.

This solution is pretty easy to deploy.

SQL Server has the best licensing price.

There is a lot to learn about this solution when first using it, as with any other tool.

I would rate this solution an eight out of ten.

We primarily use SQL Server as a database management system. 

This solution is deployed on-prem. 

One of the most valuable features of SQL Server is that it's easy to use. 

SQL Server could be improved with cheaper licensing because it's very expensive. 

We have been using SQL Server since 2016, so more than five years. 

This solution is stable. 

Before implementing SQL Server, we used Oracle. We switched to SQL Server because it had good integration. 

The installation is straightforward. I was able to handle deployment and maintenance by myself. 

We implemented this solution through an in-house team. 

For licensing, we pay yearly. The licensing is very expensive, and it should be cheaper. 

I rate SQL Server an eight out of ten. I would recommend it to others, as long is it meets their requirements. 

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.

We develop software for another company. We mainly develop on-premises solutions.

We use this solution with our accounting ERP software. Our product is called Orchida ERP and we have many clients in Egypt who are using this software. Its database is SQL Server.

We mainly work in ERP. 

We currently have a small project in SharePoint for Microsoft, but 80% of our work is with Orchida ERP

We have our software with SQL server for 20 years. Our software will not work without SQL Server. 

We provide consultancy in installing this solution for our clients.

It is easy to maintain, and it's easy to set up.

It is also easy to develop. Overall, it's easy.

It can work with many different sizes of data, anywhere from 10 to 50 gigs of data.

The performance of SQL Server is perfect. It does not need to be enhanced.

If you work with more than 50 gigs of data, it will run slower than Oracle.

Security is an area that can be improved. It could be more secure; more security is needed.

We have some clients who have been exposed to the SQL injection virus. 

We would like SQL to be able to manage this problem or to come up with an alerting system to alert the user that the server has been exposed. This has become more of an issue because of the Corona Virus and people are working from home.

Some have been infected by the SQL injection Virus and will lose their data.

I have been using  SQL Server for 20 years.

Most of our clients work with version 14 and version 19, which is the latest.

It's a stable solution.

SQL Server is scalable. Our clients are medium-sized companies, not large. They don't have professional IT.

We have 20 people in our organization who are using this solution, but we have many clients who are using it. We sell our consultancy service to more than 200 clients every year.

If we have any issues, we search Google and the internet to resolve them.

Our company has not used Microsoft Support. 

We have tried many versions of Oracle, including Oracle 11, Oracle 12, and the latest version, which is easy to maintain and similar to Microsoft.

Some of our clients are also using Express SQL. It is not good, but also not bad. If you have small amounts of data then it will meet the requirements.

The installation is straightforward. It is easy, you continuously click the next button until you are done.

It takes 20 to 25 minutes to install. There are no issues with the installation, it is very basic.

We did not use an integrator, we have an in-house team to install and implement this solution.

Some of our clients purchase the license and others do not; they use Express SQL Server.

One of our clients is using an SQL Server on Linux. We don't use it but it is a very interesting product. It's a good trend, the Linux environment has become a market share that is growing in Egypt.

I would recommend this solution to others who are interested in using it.

We can't compare this solution with other databases, as we do not have enough experience with other similar tools. 

Overall, SQL Server is good. I would rate SQL Server an eight out of ten.

Typically, the SQL Server is used in many, many ways. We primarily use SQL Server when there is a data requirement for our projects.

Typically there are uses around where you are creating a database. I've yet to store the data in our RPA server. We need MS Excel through Microsoft.

Any sort of  RPA process where you require data through housing data or using a database, you need an SQL Server.

The solution is extremely stable. The performance is reliable.

The scalability of the solution is very good.

Technical support is pretty good. they are prompt in their responses.

You do need to have technical knowledge in order to install the solution. It's not something a layperson can do.

The scalability can always be improved.

I've been using this solution for a number of years now. It's been a while. I have some experience with it. 

The stability of the product is very good. It's reliable. There are no bugs or glitches. It does not crash or freeze. It doesn't give us any trouble.

The solution is very capable of scaling. A company should have no trouble expanding the solution as needed.

You can always add on to the server or make compartments into it.

We have a team of about 200 or more people using the solution.

We do plan to continue using the solution.

We've dealt with technical support in the past. We found that their responses have been prompt. Given their engagement to typical organizations, they do decent work. I would say that we are mostly satisfied with the level of support on offer.

We did not use any other databases prior to SQL. We only use SQL.

The initial setup does take some time. It depends upon how you are establishing the server in your environment and depends upon the firewall of your organization. It is a lengthy process, however, it is not that grueling. Depending upon the firewall of your organization, it does take time. That influences the time.

I can handle the installation myself. I did not need the help of a consultant or integrator. However, whoever installs it must be somebody who has the technical knowledge. Not everybody can do it.

We have an organizational license.

We are customers and end-users. We do not have a business relationship with SQL.

We are using the latest version of the solution. I cannot recall the exact version number.

I would recommend the solution to other users, companies, and organizations.

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

I handle the banking software. We have another software called City Life, a life insurance package. We develop those packages - the banking package and the life insurance package. We have almost 70 - 80% of the market share in our country. I also use and love Delphi. We develop in that language. The backend is SQL Server at this moment and we are researching how we can move from SQL Server to some other open source solutions.

The only problem with this product is that it doesn't have an open source version.

Our customers are willing to pay less. For SQL server they have to buy it, they have to purchase the license. So, if we can get some free open source, like Firebird, InterBase, Firebase, or something like MySQL and also PostgreSQL, whichever one is suitable for us, we'd like to pick one.

Additionally, in some cases it is quite difficult, like the lack of ease of the replication and other issues. They have to improve on that. They do not have features like "always on," which is complicated.

One feature which we don't like is that they are providing CLR, and CLR can only be written in dot net, C sharp. But actually it should be open for all languages to write CLR so that we can hide our code. The next thing is that the tangent PSQ is encryptable but it is decryptable, as well. From the developer's point of view, all procedures are exposed.

I have been using SQL Server for a long time, since version 6.5.

We are still using it, but everybody is going towards open source, that's why we would like to go for open source as well. 

SQL Server is quite stable. And now we are using the Lattice 2017 version. But the most important thing is that the license cost is quite expensive.

We solve issues on our own. If we need something we Google it and find it. There is a good communication base and a community where we can get responses, replies, and some blog posts.

I'm looking at Firebird. My concentration is Firebird. I understood and researched that Firebird is the best one because it is quite robust, it has already matured, and the developer's community is quite high and stable. I'm just researching whether it can handle the huge amount of database as it did in Microsoft SQL server.

On a scale of one to ten, I would give SQL Server an eight out of 10.

We have a few use cases. They range from temporary storage to long-term storage to backup systems. We're using the full versatile suite for the product currently. It's not just a stand-alone system.

I don't have access to that level of knowledge. We just basically work with it on a small scale capacity in our department. That type of information and statistics are held by our IT administrators.

The solution is very easy to use for me. SQL is the most user-friendly system for databasing aside from Postgres. 

Due to the financial costs of Postgres, the SQL system is a good alternative as the product can be utilized free of charge. 

It's a good learning environment, it's easy enough to learn and understand. Anybody that picks up the language early on will be able to develop in it.

With any development language, any programming or software language available, there's always room for improvement. 

With SQL, it requires the more advanced integrated capabilities of Postgres, however, those capabilities do really come with obvious kinds of costs. For example, if SQL were to improve its functionality to incorporate the functionality that is in Postgres. Obviously, some kind of financial licensing will need to be incorporated. It's a bit of a catch-22 with a system similar to an SQL Server. If we want to avoid costs, we have to take a step back from certain integration capabilities.

From a development perspective, the solution needs to be a lot easier to understand or it needs to be easier to implement API packages for connection pooling so we don't have connection interruptions when, let's say, a hundred people simultaneously access the network on a given system, utilizing a specific or single database. Any type of connection pool or connection integration that could increase the total number of users to access simultaneously would be beneficial. That said, I also know there are some security risks involved with that type of connection pooling. However, something from SQL-side that can increase its connection access or its connection stability for multiple user access to a single database system would be great.

I've been using the solution for the past six months or so.

The solution is extremely stable. It's got an amazing backup repository system, a fail-safe system for if any type of data should it be lost. It's got a backup system that stores everything on a day-to-day basis or an hourly basis as well. Depending on the backup and storage drive that you're using or the capacity of the server it is installed on or the local machine, you can pretty much back up any type of critical data, any recent data, or any archive-based data relatively fast. You can also pull that data again, based on the system restore and the server restore is fairly quick.

The solution is 100% scalable to any kind of circumstances you find yourself in. It's easy to use and ready for any type of environment you're working on. It's scalable to any environment as well as to any amount of data. The only limiting aspect of scalability is if you're working on a local system or working on a server-based system. The physical data storage capacity is the only hindrance to scalability. If you've got sufficient data storage, then the scalability is endless.

The only people, to my knowledge, that have any access to the SQL Servers would be the administration and the department of development. The numbers range from anything from 50 to 150 people at any given time.

I'm not sure if we have plans, as an organization, to increase usage.

Any technical support queries we relay to our IT administration team and the IT administration team handle it directly with Microsoft Support. I haven't actually dealt with them directly.

I have experience with Postgres.

The main functionality that I've encountered within the six months is that Postgres is capable to incorporate itself or integrate itself with any known choosing standard API. With the SQL Server, we've got to use connection strings or connection pooling to do this. The API function is not as robust in SQL Server as it is in Postgres as the Postgres user package is based on APIs. Packages based on other companies or software languages that have the communication protocols are already enabled. With SQL Server, you have to hard code those connection strings or connection poolings for the APIs, which makes it far more difficult to use. However, it is still capable of doing it, it is just a longer approach.

Due to the fact that Postgres is a fully integrated package installation, done from a single installer, with SQL Server you can do an advanced complex installation which requires a lot of IT administration background knowledge. Alternatively, you can do a stand-alone use case installation system, if you're just using it for a backup system. They've got a backup package that you install and that's the standard installation you use. Due to SQL's user-friendly approach, it's got a lot of pre-made installation packages that you can install based on the needs or necessities of the company.

The length of time that SQL Server standard installation takes obviously depends on network speed, and UT package downloads. It could take anywhere from five minutes to half an hour. This is all dependent on the network speed that you're running the server installation on. If you've got a fast enough network speed, it should take no longer than five minutes. With a home-based network speed, say a fiber line with 10 megs, it should take you about 15 to 30 minutes just for a standard installation.

The solution is very affordable. It can be used free of charge.

There are payment packages for SQL based on dollars for any level of additions. They offer enterprise, express, and production additions that are available as well as community additions and student additions, which are completely free.

Before anybody had even considered doing any kind of database access, they reviewed all possible capabilities, according to price, functionality, and integration requirements. Ultimately, they settled from the start on SQL Server.

As far as I remember, our administration team did review other options. I'm not familiar with the options that were available prior to this, however, as they stated to me, before SQL has been the one from the go ahead, the option that they chose and they've been running with it since then.

Overall, I would rate the solution at a nine out of ten. We've been quite happy with the solution so far.

Basically with any databasing system, SQL included, a company should be looking at the requirements for why they're looking for any type of databasing system. Is it for backups? Is it for storage? Is it for cross-communication between departments or inter-department communication? Who's going to have the access prior? If it's just going to be on a technical or development level, not a lot of people need to worry about integration requirements except the installation team. Other than that, companies should just look at the financial as well as system requirements that are basically needed for the project or for the company you're in. If a company needs a large scale solution, financially speaking, SQL would be a good solution, however, Postgres would be a far better solution due to its capabilities, integration and API access.