What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I've been using the solution for the past six months or so.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.