SQL Server Reviews

We are a solution provider and SQL Server is one of the products that we implement for our clients. People use SQL Server primarily for business intelligence.

If you have Navision or Dynamics AX, and you need a data warehouse to be able to improve the performance of your business, then that is what our company does.

For this review I will describe one of our clients. They are a large company that owns convenience stores, and they do several billion euros a year in business world wide. The convenience stores are located in large travel hubs like airports, train stations, office buildings, and large supermarkets. Everyone who flies/travels a lot has shopped in their stores. In Romania, they have 300 stores and sell between 300,000 and 500,000 items a day across the network.

This customer is very mature and we have provided a lot of features. The most important is forecasting. When the store manager comes to the store in the morning they receive an order proposal dashboard from us. We will have taken the data from the close of business the night before, then built a forecast for the manager to help decide what to order the next day. This a very important application. We are able to calculate the orders across the network better than the ERP can.

Another use case has to do with the actual items in convenience stores. They sell products such as cigarettes, drinks, sandwiches, magazines, and more. In Eastern Europe, there's still a high percentage of people that smoke cigarettes, and what you want to do, as a retailer, is negotiate your contracts with the large vendors.

There are people called buyers, and they sign contracts with the major suppliers. Our use case provides a tablet with a very rich dashboard to show everything that is going on between the buyer and the vendors that they buy from. In those negotiations, especially when dealing with very larger vendors, you sell millions of euros of goods, such as cigarettes, each year. The goal is that you are trying to get the vendor to give you a lower price. At the same time, the vendor is trying to get you to pay a higher price. That's business.

In that discussion, the person with the best data gets the best price. Naturally, it's a high-conflict discussion and you have to have a way of taking out the conflict and replacing it with a more logical, rational argument. The person with the best data wins the argument and gets the best price. That capability is worth a lot of money. Although only a dozen people use it, it's one of the top applications used by that customer.

One of the most valuable features is partitioning because it helps to distribute the workload. Consider that you sell 400,000 or 500,000 items each day, and there are 10 years worth of history stored in the data warehouse. That is a lot of transactions. Partitioning allows you to split it up into smaller pieces so that the machine can be easily deal with it.

By default, SQL Server has relatively poor partitioning, and it only works properly if you buy the Enterprise Edition, which costs about $14,000 USD per core. Partitioning was only introduced in 2005 and because we were working with it from before that time, we had to do partitioning manually. With Standard Edition, the list price is $3,700 per core. So we still do partitioning manually.

With SQL Server SE, for a $50,000 USD or so license, we can get a 16 core server and manage data warehouses in the 15-20TB range. It runs really well.

By comparison, we had a large telecom client in 2004. We used an 18CPU Sun Server running Oracle and 15TB of EMC disk. That cost us nearly $2.5 million USD. Nowadays, we can do a great deal of what we did back then with $100,000 USD. This is amazing because in places like Eastern Europe where you have constrained budgets SE is a really good option. It's actually cheaper than running MySQL.

SQL Server is very popular in this region because of the price.

From version 2014 to version 2016, the performance really improved. We also moved to new hardware, resulting in a four-times speed-up of the processing. Now we can supply a 16-core, 15TB, data warehouse loading hundreds of thousands of transactions per day for $100,000 purchase or cheaper via hosting partners. The price of SE for the features it provides is why we use it so often.

There are a lot of things that it doesn't do in terms of business intelligence. However, you can live without a lot of them.

A lot of people want AI/ML features, but SQL Server does not really support that space. R is included but it's kind of clunky. That said, you're not going to do AI/ML with SQL Server because you're going to use Synapse, Databricks, or another similar tools.

SQL Server doesn't have proper bitmap indexing, a proper columnar database version, or proper implementation of materialized views. For example, if you want to do a materialized view, you can only do one on the base tables. You can't do a materialized view on top of another view. For us that makes materialized views useless.

I have been working with SQL Server for approximately 25 years. We began working with SQL Server version 6.

SQL Server is solid as a rock now. It never used to be. It was quite flakey in the past.

In fact, databases as a whole have matured very well. I used to work for IBM in the 1990s and I sold DB2. We had our share of problems, that's for sure.

Many of my customers are using SQL Server 2019.

Today, a 15TB data warehouse is not very big. However, if you consider this customer has 300 stores nationally, selling up to half a million items per day, then that's a fairly substantial customer.

There are bigger customers that you need to worry about. They want more products and more speed, but they have more money. 

The bottom line is that SQL Server is still an SMP database. Because we're only talking about data warehousing, there are some fairly simple rules to apply to get it to scale up quite well.

You can put two billion rows in a partitioned table. This customers largest partitioned table is more than three billion rows. That is 10 years of stock history. We use that for forecasting. That's quite a lot when you're only paying $50,000 for the database license. A similar machine, 15 years ago, would cost approximately $2 million.

Clearly, you can't compare how well a $100,000 SQL Server running on Windows compares with a shiny new million-dollar Yellowbrick server. They are completely different classes.

Ultimately SQL Server SE is most suitable for a small to medium-sized business. In a data warehousing scenario, you can do a very passable job with SQL Server SE for enterprises up to half a million transactions per day.

The technical support that Microsoft provides is great. They have forums and things like that, and you can talk directly to a Microsoft SQL Server engineer on their forums if you have a problem. But we very rarely have serious problems. I have only spoken with a Microsoft engineer with a serious problem once in the last 17 years. That is amazing really. On one project I did in 2000 we actually had a paid microsoft engineer on site we had so many problems! 

Positive

I have been working in IT for 40 years and I've worked with all of the major databases for BI. These include Oracle, IBM Db2, Netezza, Sybase IQ, PostgreSQL, and MySQL.

PostgreSQL and MySQL are available to use free of charge. However, there is more to do in order to get things to work on those databases. This extra work costs money. Over a five-year period, SQL Server SE is cheaper.

I used to sell a lot of Sybase IQ to telecoms. The only choices were Oracle, Teradata and Sybase IQ at the high end. Oracle and Teradata were very  expensive. Sybase IQ would run on a bunch of different platforms and we were charging $50,000 USD per core. We sold a lot of IQ.

Nowadays, we can do a lot of what we used to do on Sybase IQ on SQL Server SE for $3,700 per core. It's a big difference.

When you're living in Eastern Europe you can see that other databases have some better features, but you've still got to talk to the chief financial officer and ask for the money.

Today, we're working mostly with SQL Server SE because, in Romania, SQL Server is very popular because it is cheaper than the other solutions.

If you know what you're doing then setting up SQL Server as a data warehouse is trivial. If you're setting it up properly, and know how to do so, it takes about a week to complete the deployment. The bit that takes the time is the creation of the partitions.

We implement this solution for our customers, although we do not support the hardware. The hosting companies are available for that. When we move to cloud-based deployment, that will be handled by companies like Microsoft with Azure.

Our customers will also have the choice of a local hosting company that is cheaper than Azure. Most of our clients host their cloud-based solutions there because it's cheaper. They also look after the hardware, operating systems, and other such things. What we see is a remote desktop sitting on top of a server, and that is the starting point for us to deploy. If we want more memory or more CPU cores then we talk to the hosting company.

Pretty much all of our deployments run on VMs.

In terms of maintenance, it's normal. SQL Server has patches and updates. The hosting company is responsible for applying those. Then, you have new releases.

When there is a new release, we have to sit down and plan for those because they need to be properly tested. Occasionally, new releases cause problems and don't work.

When automatic updates happen, we don't let the system just update itself. We have particular times where we maintain things. We have to pick a slot where we cannot have people using it, which is usually on a Sunday or something else like that. Then, we'll apply the updates.

There are many areas we get very good ROI for BI projects.  There are things that SQL Server SE is not going to do. If you want those things then you'll have to pay more money. But for up to 500,000 business transactions going in to the data warehouse per day? There is really nothing that some performance tuning will not get around.

SQL Server SE is popular in Romania because of the price.

It doesn't do everything but for the price, it's fine.

The price for the Standard Edition is approximately $3,700 USD per core. Once you include technical support, SQL Server is cheaper than PostgreSQL and MySQL.

It is relevant to consider that the query optimizer works differently between the Standard Edition and the Enterprise Edition. The Standard Edition is cheaper but the Enterprise Edition has better performance. This is something that Microsoft had confirmed when we switched from 2008EE to 2014SE.

Another thing to consider is that some applications require a certain edition of the solution. Power BI Mobile, for example, will only run with the Enterprise Edition.

Compared to other databases, SQL Server SE rates ten out of ten in price to performance and features. If you wanted to compare SQL Server SE to YellowBrick for features SE is 5 or 6 and YellowBrick is a 10. 

That said, Yellowbrick will cost a million dollars compared to $50,000 for SQL Server. It's not a fair comparison.

So nowadays we don't spend much time looking at other databases. If a customer wants PostgreSQL we will do that. If they want Oracle we will do that. But we prefer to work on SQL Server. It's also actually easier to work on.

My advice for anybody who is implementing this solution is specific to data warehousing. I would recommend implementing manual partitioning. You'll be able to use the Standard Edition and you'll save money. If you've got plenty of money, implement the database partitioning and pay the extra $10,000 USD per core. With manual partitioning, you'll get 90% of the EE performance for $10,000 less per core. For a 16-core SQL Server, that's a savings of $160,000.

Considering SQL Server SE, and what it does for the price, I would rate this solution a ten 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.

Out of all the tools in the complete SQL Server package, I'm mainly using Toolbox and SQL Profiler because I'm using SSIS packets, so we're using job scheduling a lot. And sometimes we are creating the SSIS packages, so I'm using SQL Server for MSD for maintenance purposes. SQL Server is quite user-friendly. I have experience with Oracle and PostgreSQL, so out of three, I like SQL Server a lot.

They could increase the intelligence of SQL Server. That would be good for us.  There are some good intelligent features in SQL Server. However, they need to increase the intelligence because people switching to SQL Server from other solutions are not so familiar with it. I've been working with SQL Server for the last six years, but people are coming from MySQL or Oracle, so it will take one or two months to adjust. Still, they could add some intelligent tools to convert Oracle into SQL Server something like that. 

And sometimes when I'm writing a function, there is already a predefined structure available. So if they defined their structure more precisely, that would be good for us. And the last thing I would like to add is that SQL Server should handle queries more like Oracle does. For example, you submit a query in Oracle, and the whole table comes up. In SQL Server, you go to the table, right-click, and it lets you see the first 200 rows. Then on top of that, you can add 200 more rows.

So in place of those 200 rows, if I can update all my table records or search my table record without a new search query, it'll be very beneficial. That functionality exists in Oracle, but this feature is not available everywhere in SQL Server. So if SQL Server had the feature, it'd be great because SQL Server is lacking only on this point. For example, one of my clients is a semi-technical person, so I have to train them to file a query in SQL. And they say that Oracle is much better. Say, for example, that I wanted to query a particular employee from a list of all staff. So the query output comes, and they can directly filter out the data by just applying the filter. They don't have to use the drop-down menu and search for all the employees with a given name. 

I've been using SQL Server for the last six years. I'm working with SSIS, SSRS, or MDS. These tools are part of SQL Server, and the back-end queries are developed in SQL Server. 

SQL Server is stable. SQL Server has crashed only two times in six years, but it wasn't a major system error. 

It may be a licensing issue, but sometimes its operating speed becomes slow if we have multiple users. It's lacking some performance, but it's acceptable because we have a heavy load. And I would like to add that we're running SQL Server and SSIS at the same time. So while I've found that SQL Server is quite fast, SSIS is a part of SQL Server. It is just for data testing in India. But if a person knows SSIS, then they usually have very little knowledge about SQL and vice versa.

I know both of them. I found that maybe it's a bad habit, but I'm using SSIS packages. And in the SSIS package, I'm using Toolbox from SQL Server to improve the latency. Implementing both together takes a little time. And one more point is data handling. I am just forwarding the error names, and there are multiple errors in the SQL Server tool, but what if a person comes to work under me and has only one or two years of experience?  Sometimes it might be difficult for them to understand what the errors mean. For example, when joining data, it's easy to implement the inner joint. In the inner joint, there are two columns, so when there's an output error, someone who is inexperienced with SQL Server might not understand. Error messages should be a little more precise and defined, so it's easy to understand.

Setting up an individual SQL Server is pretty straightforward, but when you are implementing multiple tools, it's more complicated. In terms of maintenance, for the DBA part, there are two based in my company because I am on a master device, so they don't allow me to maintain the server part. So one person is from South Korea, and the other is from China. They are handling my SQL Server. So maybe there are multiple teams, but I am contacting these two guys, the DBA. And I'm MDS, so I'm a single person. There are two people on my team, and I have one junior staff member. So I have a three-person team, and there are two DBA sites because I'm discussing my master team. I am deployed on the business side, and there are more than 80 people who are end-users of SQL.

If you're using SQL Server along with SSIS and SSRS tools, it works pretty smoothly and all. When working with Oracle SQL, PostgreSQL, MySQL, etc, there are a few problems with the connection.

Overall, SQL Server is good, but sometimes, optimization becomes a little bit tricky when you're using SQL Servers in place of Oracle. For example, while I was implementing two queries one time, the SQL Server gave me the wrong results. This wasn't because of their internal modules. So there may have been some missing data, but SQL Server failed to identify those issues. SQL Server needs to improve there.

For example, say there is a line with a value of 136 or 137. The second value is a space, and the third value is null. And the last one is space. So a space means this is also null. So you are comparing these four values, and if you don't have any idea about data, it's a little problematic. So cases like this, we can deal with such queries using syntax, but if a person has no idea how to deal with this, they'll face an issue.

Here's another example. Say there's a team query that means we are erasing data from the teams, and some people are just analyzing the string. So I see data from it, which means the calling system is there. In the calling system, we receive the data to call anyone, and that type of wire call setup is there. So I am receiving a full-text format from the file I have to upload in the SSIS package. And some cells have a null value. It's a text file, so you can understand there are blanks in some places. I don't know the file type, so I am just trying to dump it into our SQL Server. But when I have time to get to that table, I realize that some values are null, space, and blank. So these four values make problems for me.

I rate SQL Server nine out of 10. I would recommend SQL Server to anyone because you can use cloud-based services, so it's very beneficial. If you install SQL Server on-premise and on the Azure cloud, it is much more advantageous for you. 

We use Microsoft SQL Server as our main database. We implement our solutions to the client site, providing the machines and the SQL Server license depending on their requirements.

The SQL Server is being deployed on-prem. Most of our clients are from the pharmaceutical industry. If there is a physical database, they want a self-hosted server always on-premises. However, the market is slowly adapting to cloud servers. Scalability and security have increased, so now people are going with cloud servers like AWS, Azure, and Google Cloud. Most of our clients are hosted on-premises and they have their own server, so we don't go with any cloud server. However, we are planning to move ahead with cloud servers for many of our clients.

The replication feature, user interface, reporting services, and notification services are really good. They are providing SQL Profiler and sqlcmd as their integrated software, so we don't find it difficult to integrate any of our third-party applications with MS SQL because all of them support MS SQL very clearly. As a part of optimization, it is good for processing huge amounts of data.

Performance could be improved. There could be more support toward PHP-based websites and toward providing direct plugins for connections, and the related services or application services could be improved. The user interface could be improved so that someone with less knowledge could easily integrate and use that particular module software.

In the next release, I would like to see a separate tool provided to schedule backup or implement backup solutions on any of the servers that Microsoft has installed. This would be a small utility which I could open and point out the backup parts as well as the type of backup I want. Once I decide the time and set it up, it should be able to connect everything and then accordingly run that back up on an automated basis. 

Right now, people are making their own utilities to do that same thing, but it would be helpful if we could get it directly from Microsoft. Apart from this, it would be helpful to have small plugins or API-based connections, which could be used for integrating MS SQL with different platforms.

I have been using MS SQL Server for 11 years, from the very first day of my job. MS SQL is widely used because its compatibility is good, especially with the .NET Framework because most are Microsoft products. The integration and the response are good, especially if you have huge amounts of data.

Now in the market, there are NoSQL options like MongoDB and Hadoop. Previously, there were pretty much three main databases: MS SQL, Oracle, and MySQL. MySQL was mostly used for small software, but many enterprise software were using MySQL because of the configuration, the compatibility, and the performance.

If you're using platforms like ASP.NET and C#, then you will want MS SQL Server because enterprise-level Microsoft provides many features like analytics services, reporting services, notification services, and now they're providing Microsoft Azure integration services.

MS SQL is very stable. However, the corruption of databases needs to be handled more accurately. If I'm using MS SQL Server and my server accidentally restarts or one of my machines restarts accidentally, then usually the MDB or the MDF file is corrupted. That corruption of files should be handled more efficiently because the client loses most of the data. Of course, the backup plan should be more efficient, putting less load on the server. That needs to be improved and more optimized.

Scalability is good. We have worked on almost 25 loads of data and 35 loads of records in a month. Most were working fine, but after time the process slows down a bit. In MS SQL, the initial 70% would work fine, but when the database starts and the load gets full, it causes slow processing. But considering the cost, features, and compatibility with Microsoft, it's a very stable database.

I have not been in a situation where I required help directly from MS SQL Server because we have our own service team that handles those issues.

Initial setup was a bit complex, but it's doable because it has improved a lot. Previously, it was very hard to install MS SQL. If I had the 2016 version already installed, it allowed me to install 2018 as well. The report features were distributed between two services, and that's where it causes problems.

We implement our solutions to the client site.

For personal websites and personal software that isn't used by more than 100 people, I will always go for MySQL for two reasons: MySQL is free and the enterprise is very low in cost.

Oracle Enterprise is another option, but the cost is high when you consider that MySQL is free.

I would rate this solution 7 out of 10. 

Microsoft's modules are really good. The syntax used for running the query is really easy. Their options for concurrency and locking are good, as well as their prices. They have created separate models such as distribution services and replication services. They are really good options so that if I want to take that service, I pay for it. If I don't want to, then I don't install it and I don't use it. Modular installation is something that I like about MS SQL Server.

If you have a lot of knowledge about MS SQL Server, you will be able to handle huge amounts of data very efficiently. However, you should make sure that you have regular backup protection. 

The servers which you have to purchase for installing, implementing, or managing MS SQL Server need to be optimized in a better way so that you get optimized performance from MS SQL.

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 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.

It has all of our data. Our company sells contracts when you buy a car. We sell aftermarket insurance for the tyre, wheel, ding, dent, windshield, etc. When somebody buys a contract, we capture all of that data into a legacy database PostgreSQL, and my task is to incorporate that into our financial platform using T-SQL. So, I write queries, procedures, and views. I use SSIS, and I use SSRS. My job is to get the data into our financial system so that we can process claims, payments, cancellations, and refunds. 

In terms of its version, we're up-to-date. We have version 2019.

This is the heart of the whole company. SQL Server is where all of our financials are. It has all of our data.

I've been using SQL Server for 20 years, and there is nothing that it can't do. It is awesome.

When we are talking about event space architecture, scalability generally comes into play. For example, I might have a hundred thousand transactions a second, and then all of a sudden, I build something that everybody in the world wants. The next thing I know is that I have a million transactions a second. So, to be able to process the throughput, I'd have to scale up, and then when the holidays are over, I'm again down to a hundred thousand transactions, and I want to scale back down. SQL Server is not going to do that. In this way, it is not very scalable. One of the reasons why they want us to use Kafka is so that if we need to, we can do that, but our base program is on SQL Server. So, this is where we would use a Kafka event stack so that if I need more servers, I can just write a command, and I can have more consumers, more brokers, and more producers, and when the holiday season is over, it scales right back down again. SQL Server is not going to do that.

I have been using this solution for 20 years.

We do clustering. If one SQL Server goes down, it automatically goes to another one.

I don't ever need tech support. If it breaks, I can just rebuild it.

They're now using a different database for contracting called Road Runner. I don't know what that is, and how it stores data. I don't know anything about it. 

There is also Postgres. I like SQL Server more than Postgres. That's only because I know SQL Server. I don't know Postgres as well. So, I can't say which one is better because I don't have the same amount of experience in both.

I can bring up a SQL Server in an hour or so and set it up.

In terms of maintenance, the number of people required depends on the need. 
We have a team of DBAs, developers, and UA analysts. We probably have 40 people in our IT area who are maintaining our solution. I'm just the developer. I'm the guy who makes the magic happen, but without other people collecting the information that I need to make the magic happen, I'm stuck. Without the guy who is an expert in permissions, partitioning, and performance tuning, I'm stuck. So, it's definitely a team effort. You can do it all, but you don't want to do it all because then you're running your head off, and you don't really get good at anything. It would be a jack of all trades, master of none type of scenario.

You will seldom find a database that was designed correctly. Just because you got a poor-quality database doesn't mean that you're going to get a better database anywhere else. You rarely get to build a thing on your own. Usually, you inherit somebody else's stuff. So, the challenging thing is working with what you have while trying to implement a better solution. My only advice is to be patient.

I would rate it a nine out of 10. I wouldn't give anything a 10 because I don't have that kind of knowledge, but right now, it does what I need it to do.

We use it for the banking database. It is for banking software, accounting software, and human resource software that we develop to run our bank.

In our production environment, we are using SQL Server 2014 Enterprise, but we also have an installation of SQL Server 2019 for our development environment.

It is secure, and it is fast. For our present database size, we are using the Always-On feature on SQL Server so that our transactions are replicated among three servers. If one server goes down, we can find the data from other servers. We have benefited from this feature.

We use SQL Server Reporting Services, and it is very good. We use scheduled jobs to transfer reports from one server to another server. 

It needs to be improved to handle big data for large volumes of transactions for big industries. As compared to Oracle Database, SQL Server is not suitable for big data or large organizations where the database size could be more than 100 GB or more. In our country, for a large database and a large volume of transactions, we normally use Oracle Database. Most of the large banks are shifting from SQL Server to Oracle Database because of its slowness. 

We have been using this solution since 2008.

For big organizations, like ours, SQL Server is very good in terms of reliability and security. It has the Always-On feature and many more features. I appreciate its reliability.

I don't know whether SQL Server can support large organizations where the database size is more than 100 GB. It might be because of SQL Server, or it might be because of the programming of the software vendor, but a lot of people think that it is a problem with SQL Server. It can't handle a large amount of data or large data size.

In terms of its usage, about 90% of our applications are running on the SQL Server database. We have around 1,600 users for our software, and all the applications are connected to the SQL Server database.

So far, we didn't ask for any technical support.

We used a flat-file database earlier, and since 2008, we have been using SQL Server. We started with SQL Server 2008 edition, and later on moved to 2012, 2014, and 2019.

We switched because there were many problems in the flat-file database. There was so much inconsistency. Some files were updated, and some files were not. There were big network issues. SQL Server has eliminated such issues, so either all transactions happen or nothing happens. This is a Relational Database Management System, and this is at another level compared to the flat-file database.

SQL Server is very user-friendly and very simple. It is very comfortable for us. We have been using it for a long time, so it is not a problem at all.

The deployment of our production server took less than 15 days.

It was done in-house with the help of our vendor. They have Microsoft-certified people. I have also worked on SQL Server for a long time, so we have an idea of how to migrate from one database to another. It was not a big issue for us.

At present, we have five people for its maintenance.

We are using licensed software for our environment. We have the Enterprise license, and we have a standard additional license.

As compared to Oracle Database, SQL Server is less expensive. For mid-sized organizations, SQL Server is completely all right, but people say it can't support large organizations with more than 2,000 users.

Before implementing SQL Server, you need to learn the concept, design, architecture, and data types of a relational database. You can learn it from YouTube. It is step-based, and you can install it. After that, you can migrate your existing SQL Server to the new SQL Server, depending on the size of the data, data architecture, and data type. 

I would rate it an eight out of 10 because I'm satisfied with SQL Server. It is working fine.