SQL Server Reviews

Most of the application what we use today are SQL-based applications. If you take a Microsoft ecosystem, there are many tools that connect easily with SQL - especially when it comes to reporting and analytics. Power BI is one of the good examples which can easily connect to SQL and then you can pull any report you want. SQL itself has its own tools like reporting services and transformation services. It also helps you to generate reporting and analytics and data transformation.

Overall, it helps our organization a lot. Again, it depends on what requirements and company has, and for what purpose you are using it. However, from an application relational database point of view that we are using today, it helps due to the fact that it comes with all that we need. Also, from a performance point of view, it configures well.

When you use the solution with Azure, for example, you get very good scalability. You can scale fast, whether it is horizontal or vertical.

If we use the product as a PaaS, Platform as a Service, it comes with all the security features you need - including against DDoS attacks.

The product offers good bloc storage, which you can buy at an additional cost. This allows you to have large object storage if you need it.

Over a period of time, their split engine has evolved and in the latest version, they've done a lot. Even from the management tool perspective, a lot of things have been done. A lot of functions have been added.

The initial setup is pretty straightforward.

Technical support has been good.

The solution has the capability to scale.

The pricing isn't as high as other options.

SQL is very easy to use. That's a very good thing about it in general.

Microsoft doesn't have active-active load balancing scenarios. It's always a failover cluster. There is no active-active cluster, which other tools, other database providers like Oracle, provide. If Microsoft can consider or probably come up with an active-active cluster, then it would be good. It will be more powerful in a scenario like that.

The pricing, while not the most expensive, is still quite high.

They have something called Parallel Queries, however, I don't know how it works. I've never tested it in a horizontal way. I'd like to understand a bit more about it and be able to use it horizontally.

I'm new to my organization and have only been using the product for three or four months here, however, previously, I worked with SQL for a long time.

In terms of direct users, there are only a few. However, there are applications that are using SQL and those application's users are 100 plus, or maybe 300 to 400 plus users.

This company is in the phase of growth. If it grows as expected, then definitely the chances are high in terms of the number of users - which means we will scale up a bit.

We have direct support from Microsoft. We have Microsoft partners as well. I don't see any problem with technical support, as we ourselves are capable of troubleshooting. I'm a certified BBS developer. If there any related issues, we take care of them internally. If not, we raise a ticket from Microsoft and we get support from them. They are helpful and responsive. We are satisfied with the level of service they provide.

The solution is very straightforward. It's not too complex. A company shouldn't have an issue implementing it. Once you install everything and get it configured as per your requirements if you are an SQL professional and an administrator, it's very straightforward.

It's doesn't take too long to set up. Within a week you can get it deployed. If you do a standalone module, a week likely is not required. If it is in a cluster module, of course, within a week you can set up a cluster and then get things done.

SQL pricing is slightly high compared to where it was before. That said, compared to other products like Oracle, they are still cheap. It's not overly expensive in comparison to others.

The final price you can expect all depends on your requirements. A standard version of SQL is always cheaper than an enterprise. If you're going to go on a cluster, it's particularly expensive. However, when it comes to the value and what is provided, that is also important.

It all depends on what you need. I cannot just blindly say that it's expensive or cheap as it all depends on your requirement. Comparatively, SQL is cheaper than other products like Oracle. Oracle is really expensive compared to SQL. 

We are customers and end-users.

I'm certified in SQL. I have a pretty good understanding of the product.

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

Whether or not it would work well for a company all depends on what purpose it is being used for. However, SQL is simple to use and simple to configure, and very powerful in terms of relational database and the SQL language and functions it comes with. If you configure it well and then use it well, the outcome will likely be very good.

We use SQL Server for our internal applications.

Working with SQL Server, it is quite convenient to use the SSMS tools to write a profile. I also like the profiling tools.

I like that the new version has a memory-optimized table to improve the performance.

We had some difficulty doing the performance tuning when we migrated from the 2008 version to the 2016 version. We experienced a drop in the performance. We could not understand or figure out what caused the drop in performance. We did not change any settings to cause this effect. We tried to keep the same settings.

We feel that when running the 2008 version, it was much quicker in terms of performance. 

That is an area of SQL Server that can be improved. Moving to a new version, you shouldn't have to change the configuration.

We have not been able to utilize it fully because it is not straightforward.

I would like to see the performance improved. Migrating should be easier and the scalability needs improvement.

I have been using this solution for many years. 

We are using version 2016.

It's a stable product.

In terms of scalability, it has some room for improvement.

We have 20 people in our organization who are using this solution.

We don't usually get support from Microsoft. We get it from our software vendors or we try to do it ourselves.

We are somewhat satisfied with the support that we have received from the vendor, but not fully because of the issue we faced when we moved to a newer version. But in other areas, it's okay.

We have used SQL Server from the beginning.

The initial setup was moderate. It was not easy but it was not difficult.

I would rate SQL Server a nine out of ten.

We use this Relational Database Management System for Line of Business systems, including Enterprise Resource Planning, Data Warehouse, Web Applications, and Business Intelligence.

Solutions are procured, built, and enhanced in the REIT industry, FMCG ERP, distribution and warehousing, manufacturing systems, knowledge workers such as workflow and portals, web applications, custom developments areas, enterprise reporting and analytics for internal reporting, and decision support systems.

Integration solutions provide robust integration to various and disparate third-party systems.

This is a simple to deploy, own, and manage RDMS.

Skills and support for this product are widely available. The security and vulnerability management are well-managed through the vendor. Lifecycles are greatly improved in recent releases, to make upgrades easier.

A license buys enterprise-grade data integration, reporting, and analytical capabilities as well.

It has broad adoption and support for integration with leading software brands such as SAP and Sage.

Data availability and security is well taken care of for the enterprise and is the backbone of first-class business continuity plans.

Support and adoption are important because skills are available to lower the total cost of ownership. 

High availability, read-only copy synchronization, and data integrity mean that it is relatively easy to ensure data security, availability, and integrity. Lower tier SKUs offer high-end features.

Data integration is available, as SSIS offers a flexible data integration platform with rich features including .NET integration for web-service integration, or bus architectures.

SSAS analytical DBs are powerful yet easy to develop and own.

SSRS offers enterprise reporting that is reasonably user-friendly.

It is easy to deploy cloud/on-premises hybrid implementations with a familiar and consistent toolset.

It is costly to implement high throughput systems, beyond millions of transactions per second. The hardware to run the systems, especially for high availability deployments is expensive, i.e. more resources to run.

Linux-based editions are not yet proven to be on par with Windows deployments.

Row-level security is obscure to implement.

Running cloud offerings are expensive; for example, the Instance as a Service offering.

Third-party tooling is required to manage code version control.

Managing BLOB data is not equally simple to implement.

The engine that implements query plans was updated in the 2012/2014 refresh that could necessitate a costly rewrite of queries.

I have been working with SQL Server for 21 years.

I have a very high opinion of the stability of the solution. It is one of the most mature products available.

Best practice setup is important to consider but when implemented correctly, it just runs.

The vendor is excellent and their relationship with Microsoft has proven invaluable. The 2008 > 2012 and 2012 > 2014 upgrades had specific issues that made them costly. Recent upgrades have been relatively painless.

We have tried using different technologies, depending on the use case. This is not the best tool for document-oriented or unstructured data.

It is relatively simple to run. We spent a good amount of time preparing the requirements for a high-availability cluster that paved the way for a reasonably straightforward implementation.

We had assistance from our vendor. We consider our vendor nimble and best in class. They contributed greatly to the stable running of the platform.

It is a positive ROI, especially in that we leverage many of the features in the offering.

With recent releases, the Standard Edition (cheaper) SKU has some of the earlier version Enterprise features. SQL Express has some limitations.

The Azure Platform as a Service option remains relatively expensive, at least in South Africa, compared to on-premises, but it is worth exploring.

Some baseline comparisons were made around 2012 to Oracle, with MS SQL Server coming out to have a lower total cost of ownership.

It is a first-class enterprise RDBMS and will continue to enjoy favourable sentiment from developers and DBAs.

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.