SQL Server Reviews

We use SQL Server for our application data.

As a government agency, all of our data is stored in our environment on-premises.

SQL Server is easier to use than Oracle, programming-wise.

It is the latest technology and pretty powerful in terms of the high availability of the virtual server.

We have had problems implementing a data warehouse using SQL Server. It may be because the data is too big, although it claims to be able to handle the amount of data that we have. Perhaps there are some technical issues because there is something weird going on. It cannot find the correct IP address.

I have been using SQL Server for ten years.

This product is not quite as stable as Oracle. I would rate the stability as moderate and would not rate it ten out of ten.

SQL Server claims to be good, scalability-wise, but we have had issues with it.

On the other hand, we have been using it for a lot of large applications and it has worked well in those cases. For the most part, it is good, and we have a lot of users.

Microsoft technical support is good.

I also have experience with Oracle and I find that SQL Server is easier to work with, but it is not as powerful.

Initially, it is easy to set up.

My advice for anybody who is considering this product is that it is relatively easy to set up.

I would rate this solution a nine 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 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.

Currently, I'm moving to another set of projects. One is for a small company that supports a client and is building on a different surface on the SQL server. The cloud that is used is essentially Amazon AWS.

SQL SSIS is the most useful aspect of the solution.

We find the product to be relatively stable.

The solution seems to be pretty flexible.

Due to the fact that I'm dealing with the product more as a data analyst, the SQL Server management studio is really relatively primitive compared to other more advanced tools. There are other tools on the market that are much more advanced. It would be better if they managed to give us a bit more of a user-friendly product with just a bit more meat on the bone. It's a bit basic.

There are a number of features that are lacking. Just recently I had to do something and it's not available on the SQL Server. However, it's available on another solution that's actually a much cheaper product. 

Some areas need improvement. For example, how you deal with the manipulation of data is probably not the best.

While I haven't constantly used the product all of the time, overall, I've used it for over 10 years at this point. I have quite a few years of experience with it.

The solution is quite stable. It doesn't have issues with bugs or glitches. It doesn't crash or freeze. It's good.

In general, the solution is scalable. Microsoft, compared to the others, tends to focus more on the programming ability of the solution rather than the user experience. Rather than making it more user-friendly, they tend to make it more program-friendly.

We have about 70 users on the solution currently.

It's my understanding that the client is planning to scale up to be able to take on more customers in the near future. They may therefore increase usage.

Mostly, I personally am on the analytics and new project development side of things in our organization. Therefore, I typically don't deal with technical support. I can't speak to how supportive, knowledgeable, or responsive they are. 

I typically use SQL wherever I go, however, I don't necessarily use Microsoft all the time. I also occasionally use a solution called Teradata.

I was not involved in the installation of the solution. I'm more on the side of creating metadata. Therefore, it would be difficult for me to comment on if the solution was easy or difficult to implement or how our team deployed it. I don't have any exact details on that front.

While there are costs involved in using the product, I'm not a part of the billing or payments team. I can't speak to how much the solution costs or how much our organization pays. I do not know if it's monthly or yearly and how long our contract is for, if we have one.

I'm using the 2016 or 2017 version of the solution.

There are many SQL options. I'd only recommend this one if it made sense to the individual company and their requirements.

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

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.

We are using this solution for application databases and data warehouses.

The organization was deploying SQL before I came to it, so I assume whoever selected this type of technology was really happy with it.

That question is not that easy to answer, to say that there is a feature in a database that you like more than others. When you are running a database, you expect it to do many different things, and if fails in one area, it basically takes it out of the picture completely.

Scalability is an area that needs improvement, and the deployment is difficult, which why I'm looking for an appliance to deploy it in a much more scalable way.

I would like to know how you can scale to be a large enterprise server.

I have been using SQL Server for approximately 20 years.

We were using version 16 and we went to version 19.

There are no issues with stability that are not within the norm where you deploy new versions. Microsoft is always very close. When we experience any type of glitch, Microsoft handles it and we take care of it.

It scales with a lot of effort. When comparing it to Exadata, it's easier to scale with Exadata.

Technical support is very good. We have them on-site.

They know their business very well and I would rate them a ten out of ten.

Previously, I was working with Oracle Exadata at a different company. It was great, and ran very smoothly.

The initial setup was straightforward because we had help from Microsoft.

We had help through the Microsoft team.

Our company is Microsoft SQL Server based. I used to use appliances like Exadata before I joined the organization. 

I was looking to see if there would be available technology solutions that would make Microsoft SQL Server work on an appliance to improve stability and scalability, as opposed to running or dividing into Intel-based processors and servers, and handling all of the operational issues.

Having a server that's optimized for the purpose of data warehousing and analytics, is something that I would be interested in. 

I am not sure if there is anything else available as a nice comparison.

We use SQL Server and we are evaluating Azure cloud, and Azure SQL.

I am a data person. I design data warehouses and I develop analytics.

Before implementing SQL Server, make sure that you evaluate it based on the case that you're actually planning to implement it for, and that it's not just for general purposes.

It's not built for everything and anything. You need to choose carefully.

I would rate SQL Server a seven out of ten.

We primarily use the solution as a WAP server and we have it on-premises.

It's helped us connect to our company's machines.

The pricing of the product is very good.

We've found the stability to be very reliable.

The initial setup isn't too complicated. It's pretty straightforward.

Overall, the solution could be improved in future releases. We hope to improve the way we use it ourselves in our next project.

The solution could offer better integration with other solutions - specifically Microsoft.

I've been using the solution for about five years at this point. It'd been a while.

Thus far, the solution has been quite stable. It doesn't crash or freeze. there aren't bugs or glitches. It works well for us overall and we find it to be reliable.

I'm not sure about the capability of the solution's scalability. We've never really tested its capabilities, and it's therefore hard to gauge.

We have a department that handles support. I find them knowledgeable. They respond in a reasonable amount of time. 

The initial setup wasn't complex. It was pretty straightforward. We didn't have any issues with the implementation process at all.

The licensing is reasonable. It's not too expensive. We are charged on a yearly basis, however, I don't know the exact amount we are charged. I'm not a part of the billing and payments department.

I believe we are using the 2019 version of the solution.

In general, I would recommend the solution to other organizations. We've mostly been pretty happy with its performance.

We're not Microsoft partners. We are just customers.

Overall, I would rate the solution eight out of ten. If it had better integration capabilities with Microsoft, I might rate it higher.

The primary use is to maintain my database client.

What I like best about this product is the environment.

The documentation and manuals are very good.

The pricing could be improved.

I would like to have the option to use fewer processors for certain tasks, thus reducing the licensing fee. That would be great.

I have been working with SQL Server for more than 10 years.

I use SQL Server on a daily basis.

The scalability is not very good because when you add processors to the machine, the price of the license goes up. Scaling is very expensive. We have approximately 500 people who are using it.

Technical support is very good.

We used the Oracle Database prior to SQL Server.

The initial setup is simple and the deployment took one day.

We had assistance with our deployment and the experience was very good.

This is an expensive product, especially when you need two servers, or for enterprise solutions. We pay approximately $12,000 USD per month for both the server and the license.

At this time, all of my applications are running on SQL Server. However, in the future, if the application can be migrated to Oracle or another database then I may do that because SQL Server is very expensive.

This is a good product, although my advice is that if a company can afford it then they should use Oracle instead.

I would rate this solution an eight out of ten.