SQL Server Reviews

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.

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.

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.

SQL Server is a highly stable solution.

The pricing and quality of the product could be improved.

I have been using SQL Server for more than 40 years.

I rate SQL Server a nine out of ten for stability.

Our clients for SQL Server are usually enterprise businesses.

I rate the solution an eight or nine out of ten for scalability.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing a seven out of ten.

Since SQL Server was one of the most commonly used products initially, it was very easy to use. I'm moving away from the solution because there are now better data storage tools. SQL Server was used for the postal service in the Netherlands, where the postal buses on the street were analyzed. SQL Server is always deployed on the cloud.

Data recovery and backup are sometimes hard with SQL Server because of the data store size. Based on the data structure, I would sometimes recommend the solution to other users.

Overall, I rate the solution a seven out of ten.

The solution is used primarily for medium companies in vertical accounting applications. We use the solution as a good general-purpose database.

I value the ability it gives me to test on small machines and easily scale up to larger devices for live applications.

When we run into problems, it's usually during installation, and finding answers to the problem has been a nightmare because the documentation is terrible.

Likewise, I find the business reporting rather poor, and the solution doesn't work well as a data warehouse product. When I tried to use it as one, I did not find it very satisfactory.

I've used SQL Server for about 20 years, probably. I've used a number of different versions, including 2010 and 2007.

We have never had a stability problem.

We rarely have more than a few hundred users. It's more about the person using it since we don't have heavy, continuous use.

We've never had a sensible answer from technical support.

I have generally found implementing the solution easy. But when it comes to the time we took to implement the solution, the problem's always been the application and not the database. The solution is usually easy to implement because we use standard facilities. If you need something special, you run into all sorts of trouble because SQL Server gives you an awful lot of ability to change the settings.

We've used it as a development tool, and it's very cheap as a development tool. Besides, someone else has paid for it for my use, so it's a question of whether the cost suits the end user. The solution has a good midrange price for the applications in which we've used it. Oracle's pricing would raise more eyebrows, but SQL Server's pricing has proven satisfactory for our market range.

We mainly use SQL Server because it's cost-effective for our applications. We've occasionally tried other databases for various reasons. We've used the Sybase database, but the Sybase database is very close to SQL Server. We've also tried MySQL, but that was more of an exercise in porting than anything else. However, it's not a fair comparison because we had done the development on SQL Server and then used that as a porting exercise.

The solution's generally been easy to use for the general cases we've used. The solution has been satisfactory for the sort of applications we've used.

We've been very much middle of the road in using SQL Server. We don't use specialist, and we've tried to keep to standard SQL as far as possible. We don't use the clustering facilities or try to use any of the specialist facilities. We could drop it and switch to MySQL or another database if we had to. We are using SQL Server, not for the particular services it's got, but using it as a middle-range product. We're taking advantage of the fact that it runs on all sorts of platforms, and it's a good value development product that works very easily for us. We're not using it for some of the things Microsoft clients find particularly useful for. We're not high-intensity users. For people like us, it fits in very easily.

For our purposes, SQL Server is just about ideal. It's easy to use and fit. Some of the later versions, in particular, have been easy to use. We have had installation problems on some of the later versions, and the documentation is poor. I'll rate SQL Server a seven out of ten.

We use the product as a database for the applications. 

The tool helps us by being available always. 

We don't encounter any issues with the solution. 

The tool is expensive.

I have been using the product for the last ten years. 

The solution is stable. 

The tool is scalable. 

The tool is easy to install. 

We have seen ROI with the tool's use. 

I would rate the tool's pricing a six out of ten. It is not extremely cheap but also it's not the most expensive product. 

I would rate the product an eight out of ten. 

We use this solution to extract data. We have a partnership with Microsoft and I'm a solutions architect. 

This is a user-friendly solution. It's great that I can extract the data from the SQL server and store it in my local data source for BI purposes.

I think that performance could be improved and SQL presents some challenges for us.

The stability is good. 

We haven't faced any scalability issues. We have over 200 users. 

I interact with multiple data sources, multiple customers and their ERPs. It can be Oracle, SAP or MongoDB among other solutions. MongoDB, for example, is a little more complex than the SQL Server and we often have more of a challenge establishing a connection with MongoDB.

The initial setup is not a problem. 

This solution is moderately expensive. 

I can definitely recommend this solution to smaller and midsize organizations. I rate this solution eight out of 10. 

We use this solution to store our data and for running queries, simple select queries that enable me to create the views I need and report from those views. I'm an ESM specialist and we are customers of SQL Server. 

I like the stability of the solution, the fact that you have two, three, four nodes replicating at any given time at different locations, and they're all synchronized; if one is lost it automatically moves to another. The other advantage here is that when it comes to application maintenance, you switch onto another node while you maintain another server and there's no downtime. 

The solution could have additional security. 

The solution is easily scalable because of its flexibility.

I don't do the installation, but it appears straightforward according to those who carried out the implementation. These days deployment takes about an hour. We have 1,200 or so users. With the onboarding of more customers, we'll be increasing our use of SQL Server. For now, we have one person dealing with maintenance. 

I rate this solution nine out of 10. 

We use SQL Server for developing systems.

The most valuable feature of SQL Server is the performance.

I have been using SQL Server for years.

We have approximately three people who are using this solution.

The technical support from Microsoft has been good.

The initial setup of SQL Server is straightforward.

We have two administrators that did the implementation of the solution.

The price of SQL Server could be reduced, the license is expensive. We have an annual subscription.

I would recommend SQL Server to others.

I rate SQL Server a seven out of ten.

I'm a web developer, and I use SQL for the backend.

The most valuable aspect of the solution is its ease of use.

It's a pretty stable solution.

We found it to be quite scalable. 

While using it, we really didn't experience any pain points. It doesn't need any additional features. 

I have a couple of years of experience with the solution so far. 

The stability and performance are good. It doesn't crash or freeze. it's not buggy. there are no glitches. It's pretty reliable. 

The scalability has been good. If a company needs to expand it, it can do so.

I've never used technical support. I can't speak to how helpful or responsive they would be. 

I'm not sure which version of the solution I'm using. 

I'd rate the solution at a nine out of ten. We've been satisfied with its overall capabilities in general.