We changed our name from IT Central Station: Here's why
Get our free report covering SAP, IBM, Microsoft, and other competitors of Oracle Database. Updated: January 2022.
564,997 professionals have used our research since 2012.

Read reviews of Oracle Database alternatives and competitors

Mainframe Technical Manager/Service Integration Lead at a tech services company with 10,001+ employees
Real User
Top 20
Very scalable with high availability and excellent technical support
Pros and Cons
  • "I like that its true active-active. For example, if there are two instances within a cluster, we can take one of them down and there's no failover or switch over. There's no primary and secondary, it's true active-active. We can take one side down and we can upgrade that with new maintenance or a new version, obviously testing coexistence beforehand, without impacting the business."
  • "We just want a bit more integration with Linux. That said, we are already seeing Linux more readily available on the mainframe environment."

What is our primary use case?

It's not the Db2 LUW, which is Linux, Unix, Windows. It's the mainframe. It's the active-active, high availability environment that we need for the aggressive SLAs that we've got here in Saudi Arabia.

What is most valuable?

I like that its true active-active. For example, if there are two instances within a cluster, we can take one of them down and there's no failover or switch over. There's no primary and secondary, it's true active-active. We can take one side down and we can upgrade that with new maintenance or a new version, obviously testing coexistence beforehand, without impacting the business.

In a distributed world, you've got lots of different prerequisites you've got to be managing here. Not just the database - possibly the VMs that the database is in and the OS that the database is running on, Linux or Windows, as well as the storage.

I like its high availability. It's well supported by IBM. It's used by a lot of the larger business organizations globally within banking, finance, credit cards, insurance, retail, and government.

We're proving that it's got that high availability and robustness. We can prioritize the workloads that are coming into that database management system, using the features of the IBM z/OS environment. That way, if this transaction's coming in off the network that is in and out, they will be given priority over somebody doing a lengthy query that's coming in from the network that you would consider to have more batch-like tendencies. 

We like that it's using separate specialized CPU engines to manage the locking and the sharing of data via a coupling facility. This stays on the CPU that we would be licensed for. We call them specialized engines that you don't license. They're not paying your licensing costs. Whereas, for example, in other database management environments for high availability, they communicate between themselves over an IP network. The CPU would be higher for them. There's no special process or capability that allows taking that CPU and that communication between them. It has to, if you've got four nodes of a database management system, one of them would have to lock on a row in a table or whatever, it's going to have to propagate that information to the other three nodes on the mainframe side. It would just put it into what we call a coupling facility, and the other Db2 members or instances in the same cluster would be able to check that and see that, no, we can't update that yet, we'll have to wait.

There are lots of different things we use it for. We use it for data replication, which means that we've got an always-on alternate Sysplex cluster several thousand miles away that is propagating the data to that Db2 over there using replication services at the software level rather than, if you physically replicate data and the Db2 or the Oracle environment, physically using storage replication, you've in effect got a cloned copy of that environment. It's going to fire up at the remote site, looking for the network that's at the local site. There are lots of things you would have to do there to do that. Plus the RTO time to actually get that alternate Db2 at the DR side could be 40-45 minutes depending. Whereas we can do this capability and we call it always on, where the RTO is about a minute.

What needs improvement?

The good thing is that there are improvements coming with later function levels for the z/OS Db2. I'd like it if, with the operating system that we've got, z/OS, on the mainframe, it would allow us to refresh the hardware to run Linux dockers on the mainframe. This means this might give us opportunities for different ways of coming into the Db2 environment in the future. We just want a bit more integration with Linux. That said, we are already seeing Linux more readily available on the mainframe environment.

Not only have we got the premium operating systems on OS. We can run LPARs on the same mainframe footprint that is also supporting Linux. This is what has improved and made the mainframe environment more competitive.

We're also looking at AI for Db2 as well, and machine learning for the future. We know that AI has come out, that we're going to get that, and we're going to evaluate that product next year for Db2.

That said, I haven't got any real complaints about Db2 on the mainframe. For the most part, a lot of the problems we have nowadays are to do with communication between the various teams that you would class as stakeholders.

For how long have I used the solution?

I've been working in a mainframe environment since 1991. I got involved in Db2, in the mid-nineties back in the UK. I've supported the database team regarding the system programming side of things, however, I used to be involved in it quite a lot operationally as an ops analyst lead. I've not actually worked with other database management systems on other platforms. However, some of my team support them. I occasionally have to look at these sites to understand the products and what their advantages and disadvantages are.

What do I think about the stability of the solution?

Sometimes it's how you go about system management processes within the environment, and not always the product itself. If, for example, we're going to put maintenance onto the Db2, we would do that in a sandbox environment first. We would test that the Db2 that we've put the maintenance on can exist or coexist in the same cluster as the ones we haven't put the maintenance on. That's the first thing.

We would test functionally and can regress that maintenance in case we introduce a defect, or it causes an application defect. Coexistence and regression are very important in the sandbox.

After we've signed that off, we would move it into the development environment where they've got all the different development services, integration, UAT, dev-test, pre-production, model production, et cetera. We would let the development workloads test the Db2 instance there and see that that's working. If that's okay, then we upgrade the other Db2 instance in the cluster. Finally, we put it into the production environment.

Therefore, you're not going to do a big thing. You're putting your maintenance in on 50% of the database environment so that you've got ability and capacity on the other side where you haven't made that change. And you've already proved coexistence and regression, should there be a defect identified through the application.

I like the way that Db2 allows us to do that. Certain DBMS environments, you have to upgrade them all to the same level. Some of them have to be patched quite regularly due to security. However, in the mainframe, it's not too bad.

When I first came here, they were putting the maintenance and the new release, they would do it across the whole cluster. Which, if we had a problem with some of the applications that are running in there, we would have to regress that, which would probably mean an outage. There are operational or system management processes that we've tuned and we've improved so that we're mitigating against any service disruption.

The way the IBM z/OS Db2 environment's designed does allow coexistence. It does allow us to upgrade 50% of it, or 25% of it, and leave it running alongside one that's back level - as long as we've proven our coexistence.

What do I think about the scalability of the solution?

We've got a two-way Db2 cluster at the moment. With two members in that cluster, we could have up to 32 members in that cluster. It's got outward scalability as well.

It's got the ability to have up to 32 members within that data sharing group or that cluster. So you could run one of these on a separate Z server, Z mainframe, which would give you quite a lot of CPU capacity. I don't know whether there are any environments out there that would need or have that. Some of the world's largest banks - maybe in America or in Asia - might have a configuration like that. For us, we're across multiple processes, and we've got the ability, should we enable for cloud at a later date, to be in a position where we can just scale-out with little disruption, by just adding more LPARs with Db2 members in. We just have to make sure that we've got the processing capacity on the mainframe to support the additional workload.

How are customer service and support?

IBM technical support is pretty good. We haven't had issues with them from the operating system, from the KICKS, from the MQ, from the Db2. When I compare it to, for example, Oracle tape, we don't get the same level of support there. There's a lot of collection of log information and things like that. We have to escalate that case or that incident to the second or third level within that organization. We tend to find that IBM, on the other hand, is pretty good with that. I can't comment on other areas other than experience with Oracle, which sometimes isn't that good.

How was the initial setup?

The mainframe environment does not that often require that we have to set up another Db2. If you're creating a brand new Db2 cluster or data sharing group, then there is a bit of work in that.

The IBM manuals for this and our localized documentation assist the engineers and consultants in building a Db2. I don't consider any issues regarding a build of a Db2.

The mainframe environment from a security perspective is one of the key fundamental selling points of the mainframe environment. It is relatively secure assuming that the security people that administer the RackF database, the external security database, are actually configuring it right. Then we deploy role-based access controls. When they're doing this sort of activity database, people would have to liaise with other areas within the infrastructure and support to configure that Db2. Obviously, with any Db2 you need security permissions. They would need to discuss with the storage team how much disc space they're going to need and to discuss with the performance team and capacity team to make sure that they're going to profile that environment. They would need to discuss with the automation team to make sure that the Db2 is shut down when we need to shut the system down and that it's started up properly when the system's reloaded, or if it is in an unplanned activity, that we can restart it in light mode. Furthermore, the automation tool is monitoring that Db2 instance to make sure that it's healthy. Ultimately, there are lots of different teams that would be involved in this. 

For the most part, the setup is simple. If somebody wants a new database or schema, we could just quickly do that within that environment. If we need a brand new, separate Db2 environment, that would be more complicated, however, we have the procedures and processes in place for that.

We could have just one systems programmer doing that maintenance. That said, from my perspective, I engage a lot of the teams. Once we've put that maintenance into the development environment and we leave it for a week against one member and leave the other member back level, we would do full performance analysis to see that, with all the transactions that are running there, there's no additional CPU and there's no deterioration in response time and that the Db2 member itself is looking healthy, it's not having any resource shortages, there's no virtual memory or physical memory increases or deviations or anomalies.

We'd engage with the performance and capacity team. I recently engaged with the distributed team, for example, the middleware teams, to make sure that if anything is coming off the web through the web servers, they are aware of our change so that they can monitor and support us.

While it's one person that's doing the change, he might be working with a few junior engineers to do training. We tend to engage a lot of teams across the activity to make sure that everything looks okay and we're not impacting SLAs.

Furthermore, we have a 24 by seven operations team and they do all the operational side. You wouldn't get a Db2 systems programmer in production stopping and starting the Db2. That would be done by the operators.

What's my experience with pricing, setup cost, and licensing?

In the 90s, there was a big problem with the IBM mainframe environment and there was a big push to move the middleware off the mainframe and put it on cheaper distributed hardware. What happened then was the workload was coming in over the network. This was what we called dynamic SQL coming into Db2 - which was a bit more resource-intensive to what it was with traditional legacy style workloads that were static SQL coming into the Db2 environment, that we could see the CPU on the mainframe.

In the old days, in the 90s and before that, we were charged quite expensive amounts for licensing the software on the full capacity of the mainframe they're running on.

Now, what they introduced mid-nineties/late-nineties was these specialized processes like a coupling facility. There was a Z integrated information process called a zip. This supported workloads coming in off the network from web servers coming into Db2, and we know that these workloads are traditionally resource-intensive. They're not as efficient as static SQL. This meant that in the old days, our licensing costs would shoot up as we would have to upgrade the mainframes and it would make it more expensive.

IBM introduced these specialized processes and the zip allows the workload to be dispatched on that specialized processor. Not all of it - maybe 40% to 50% of a transaction is eligible to be dispatched on a zip. This means that we don't need as much of the standard mainframe engines to support the business workload. Anything that's running on a zip, we don't have to pay licensing fees.

This was something that made the mainframe more competitive again. Furthermore, with the mainframe we have now we can have the forerunner to virtualization (VM), which is what I started on back in the early 90s, known now as ZVM. Having ZVM means that you can run virtual machines in that OS. It acts as a hypervisor. It runs virtual machines in that OS that could be separate Linux instances.

The flagship or premium operating system on the mainframe is z/OS. It used to be called MVS, multiple virtual storage. We're going to be able to evaluate next year within Linux Dockers, in them LPARs, alongside all other tasks that we've got running such as Db2, such as KICKS. It is going to make it really interesting in the future.

Which other solutions did I evaluate?

We have been comparing Oracle RAC against the z/OS Db2.

I tend to see that there's a lot of bias for people, depending on, for example, if they work for an Oracle database management system. In that case, you tend to get a lot of people that are biased towards the Oracle. Likewise, you'll get that with Db2 LUW or Db2 z/OS. They don't tend to know what the other environment can do. That said, looking at it from an infrastructure and system programming background, as my background is really system programming and storage and hardware infrastructure, it's trying to get a general view on what the database management system can offer for SLAs, high availability when it's patched, and how often it would have to be patched. I want to know, for example, if there are a lot more security defects and fixes with one environment as opposed to another so that we're not interrupting our hosted business in the environment when we're doing our maintenance and new releases of software.

What other advice do I have?

I'm a partner of IBM. I used to be an IBM employee until August when I switched over to a partner company.

I'm not would say totally biased towards IBM. We do like to look at other vendors' hardware and software. For example, we use Oracle hardware on the mainframe environment for the tape. Oracle took over Sun which took over Storagetech, which is a mainframe and distributed tape solution. We do have a mixture of IBM and non-IBM software and hardware.

I'm a technical manager at the moment, and I'm supporting a team that's running Db2 across multiple sites within the Kingdom of Saudi Arabia.

We are moving to the private cloud, however, at the moment, it's on-premise between multiple data centers dispersed within Saudi Arabia. They don't want to be looking at any cloud services from suppliers where they do not have control of the data. We are looking at maybe next year a private cloud infrastructure for the mainframe Sysplex environment.

I'd advise new users to make sure they know what you're doing. Don't guess. There's a lot of people working out there in IT that like to tell people that they know what they're doing. From my experience, they don't know what they're doing, and they can make a complete mess of it. I see it a lot over here in the Middle East. They need to be aware of what they're doing. They need to be following proper procedures and processes.

When they're upgrading to the production environment, they should be raising a high severity ticket with the supplier. For example, if we're changing the version of Db2 in our production environment on 50%, or one member, I would inform the team to raise a high severity ticket so that we've got IBM support on hand should we encounter any anomalies. I would be saying that the same to the Microsoft SQL team, to Db2 LUW, to Oracle, that sort of thing. That would mitigate risk.

They should also properly test it. They should make sure that they follow all the functional tests, which we call IVPs, which are scripted tests that you can run to prove that it looks okay. You should be engaging with the application team in non-production first to see that they're not having any problems with the application. You should try and see if there's a performance team or monitoring team that's able to look at the performance of it. You should be talking with the middleware team, like the webserver teams, the .NET, the KICKS, and making sure that all their processes are working with that database. And then you migrate it into production.

I'd rate the solution at a ten out of ten. The product, the support of the product, the high availability that it offers, the active-active, plus how we're managing it, has been great. We're having fun with it.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
HarkamalSingh
User at a manufacturing company with 10,001+ employees
Real User
Top 5Leaderboard
A stable, scalable, and easy-to-deploy solution that pretty much covers everything
Pros and Cons
  • "It is a pretty good solution. The on-premise version 2019 has many features, and they had introduced a really good and stable environment in version 2019. It has very good integration with big data clusters and other things. It covers pretty much everything that you can do with a SQL server. You can use any language to connect to it, which is not there in other solutions. They have also introduced Python, and it also has ArcScale. PaaS is a modern, scalable database. You can use Power Automate and a lot of features in this. It is very easy, and you don't have to worry about versions and upgrades. Microsoft keeps on adding new features to this solution. Microsoft is improving its connectivity on an ongoing basis. It connects well with Office 365. If you see something not working, in a couple of weeks, it is going to work because there is a team working on it. You can vote for the things that are missing, and Microsoft can work on them depending on the product that they're launching."
  • "There are a lot of improvements in the cloud space about which we open a case with Microsoft every now and then. These improvements are not in terms of features or functionality. They are more related to their own compatibility or connectivity on which they keep on working to improve the product."

What is our primary use case?

The .NET applications use SQL Servers on a very large scale. Basically, about 80% or 90% of the database platform is on SQL Server.

We are working on version 2019, but we are also now working on the cloud databases. Our goal is to stay away from versions. We are going to go version-less and move to Azure SQL or managed instance, which is version-less. This way we won't need to worry about any upgrades or any version changes because Microsoft is going to take care of these things. We will always have the latest and greatest version.

What is most valuable?

It is a pretty good solution. The on-premise version 2019 has many features, and they had introduced a really good and stable environment in version 2019. It has very good integration with big data clusters and other things. It covers pretty much everything that you can do with a SQL server. You can use any language to connect to it, which is not there in other solutions. They have also introduced Python, and it also has ArcScale.

PaaS is a modern, scalable database. You can use Power Automate and a lot of features in this. It is very easy, and you don't have to worry about versions and upgrades.

Microsoft keeps on adding new features to this solution. Microsoft is improving its connectivity on an ongoing basis. It connects well with Office 365. If you see something not working, in a couple of weeks, it is going to work because there is a team working on it. You can vote for the things that are missing, and Microsoft can work on them depending on the product that they're launching. 

What needs improvement?

There are a lot of improvements in the cloud space about which we open a case with Microsoft every now and then. These improvements are not in terms of features or functionality. They are more related to their own compatibility or connectivity on which they keep on working to improve the product.

For how long have I used the solution?

I have been using this solution for 13 to 14 years.

What do I think about the stability of the solution?

In version 2019, they introduced a really good and stable environment. Bugs are there, but bug fixes are provided by Microsoft. We have premium support with Microsoft. If we find a bug, they work on it and provide a solution.

What do I think about the scalability of the solution?

It is very scalable, but its scalability also depends on what you're using. If it is on-premise, you have to do everything on your own to scale it out. It is easy, but you have to get the infrastructure ready to scale it out. It is a manual process. If you're on a cloud, then it is pretty much easy and straightforward if your cloud has those availabilities. It also has a Hyperscale, where you can put the upper and lower limit, and it can scale up and down as per the use case and the compute that you need.

We have a lot of users. Everyone is connected to this. We have business users, technical users, application users, and integration users. We have 17,000 instances of SQL Server here with a lot of databases. 

How are customer service and technical support?

We use Microsoft's Premium Support. They're good. I would rate them an eight out of ten. For on-premise, you design your infrastructure. When you change something or customize a few things, it is hard to get support because the issue can be from either side. When you have a critical issue, which is not straightforward, you have to go between two different vendors, and they start finger-pointing to each other. They say that the issue is not at their end, and there is nothing wrong with their configuration. The issue is because of storage or network. These are the few things for which you have to fight for support. I don't know how they will improve this. It only happens sometimes for an on-premise solution. We don't run into those issues on the cloud because it is their own setup.

A cloud solution is pretty much on their site. They are managing the infrastructure, so they have to provide the solution, and they are good at it, but when you have on-premise, you decide what storage to use. Sometimes, you ignore Microsoft's recommendation, and you don't want to use what they are suggesting. When we run into issues on the DB side or the application side, they can point out to different vendors or causes for issues. 

Which solution did I use previously and why did I switch?

We also have Oracle, Db2, and MongoDB databases here. We also have some NoSQL apps, but comparatively, SQL Server has a bigger footprint, and it is better than the others. 

Other systems are more complex to configure. When you configure a cluster on the SQL itself, it is easy to configure because you've got more resources, whereas, when you have to configure Oracle or Db2, you have to have a SPEC process because they have to configure that on Red Hat Linux or Unix side. A few companies don't have special admins for Linux because the footprint is not that big. You might have two or three applications running on that system. When you run into a problem, you need to hire someone who can implement it for you, whereas most of the companies, almost 80%, are Microsoft shops. They already have the talent and resources available. You also have offline help and support. You have a lot of blogs or online help available when it comes to Microsoft, but when you go to other solutions like Oracle, sometimes it is a challenge. You really need the right person there, and not everyone will be able to do it. 

The capability of a solution also depends on your needs and configuration. If you configure things wrong, any system will fail. When I'm testing something, I always believe in the functionality because Microsoft and Oracle test their products thoroughly. I never question their functionality, but we also check it according to our plan. You have to customize things based on your needs. If you're not getting the results, you have to consult the tech support and bring them in to configure it. These are the things that you run into when you are in your own data center. If you are not getting the throughput from the storage itself, you need to get the storage admin or storage vendor in there. When you move to the cloud, everything is taken care of.

How was the initial setup?

It is straightforward. There is no complexity. It is all automated, and we do un-attended install. We are not sitting and doing it. We just include it with the server build itself. When the server is built, we provide them the un-attended scripts to run, and everything is configured. They can use the media provided by Microsoft. Everything is done in one step. We just need to do auditing. We need to check at the right place, and we just keep checking it.

What's my experience with pricing, setup cost, and licensing?

Cost is a major derivative for any organization. It has a reasonable cost value, and its cloud support is also better than others. Comparatively, Oracle can do the same things or is even better in certain areas, but it is expensive. The cost along with the support are the plus factors for SQL Server.

What other advice do I have?

You need to know the concepts and the business logic before using this solution. It is not straightforward. You need to know what your application needs are and only then you can work on it. You also need to know about the product and how it works.

I would probably advise others to move to the cloud version, which is a modern database. If you want to use SQL Server, Azure is the best because you get the hybrid benefits. You can bring your own license, and you can save costs. You can save 55% of the cost. With AWS, you have to buy your license, which makes it expensive. If you are using SQL Server and your company is more on the Microsoft side, Azure is easier, and there is no change in it. You can also get more out of it. You don't have to put a lot of complexity in supporting or administrating it because Microsoft does that for you behind the scenes. Therefore, it is good to move to Azure SQL or to manage instances where you have more control. Both of these are PaaS solutions. There is no need to go into IES. It is better to stay on-premise than on IES because it creates more complexity. This is because you still have to build the servers, and you have to still manage them. If your application is compatible to be used with PostgreSQL or MySQL, you can also move there.

It also depends on the kind of talent you have in your company. You have to consider the talent that you have. You can choose other technologies, but you need support from your teams. If they're .NET developers and you have to build the knowledge base, it is smoother to stay with SQL Server because you have to change less on the coding side.

I would rate SQL Server a ten out of ten.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Head of Department at a transportation company with 10,001+ employees
Real User
Top 5Leaderboard
Quite stable and flexible but not very innovative
Pros and Cons
  • "So far, we do not have a lot of issues. It's pretty problem-free."
  • "The solution really doesn't add new features very often."

What is our primary use case?

We primarily use the solution to store some customer information in our database. Basically, this customer information will be used by all the applications that are in our company.

What is most valuable?

The solution is quite stable and reliable. We use it mainly due to its general stable nature.

There's a lot of flexibility for us to create a DB schema. 

They provide some replication for us - XDR, or something like that.  

So far, we do not have a lot of issues. It's pretty problem-free. 

What needs improvement?

The solution really doesn't add new features very often. Other solutions are much more actively pushing out upgrades and improvements. Informix just isn't extremely innovative.

Something we are looking for is, for example, data reduction. We want to do masking and it doesn't give a lot of flexibility. Oracle already has something to support us and can set out a policy for the data reduction and then you just simply set up and then you can use it without any writing of functions - plus, it's easier to do masking.

For how long have I used the solution?

I've been using the solution for more than 20 years at this point. It's been two decades. I've used it for quite a long time.

What do I think about the stability of the solution?

We've found the solution to be pretty stable. It doesn't crash or freeze. There are no bugs or glitches. It's been good.

What do I think about the scalability of the solution?

The solution scales well. If a company needs to expand it, it can do so without too much difficulty.

How are customer service and technical support?

We do have a support contract with this vendor. 

From the marketing you get, IBM seems to really push that you get more from them than Oracle. They've been aggressive in selling their product to us. Oracle hasn't been as aggressive. They seldom come to us or approach us. Typically, it's our company that goes to Oracle.

IBM is much more aggressive in selling their product as opposed to Oracle. They're always checking in.

How was the initial setup?

Our team wasn't directly involved in the installation process. Therefore, it would be difficult to comment on how complex or straightforward it is.

We instructed a team to set up a database, a blank database, and then we created a schema and all of these kinds of things. While the server installation was handled by another team, the creation of the database is done by us.

What about the implementation team?

We had another team set up the solution for us.

We are professional services providers. Basically, we review some applications on the Informix DB, and then the application, and we will roll out to production. We have another team to support the second level of support. The first level of support would come from the help desk.

What's my experience with pricing, setup cost, and licensing?

We have a corporate license with IBM. We also have a global account. We have a contract of a few years with them. 

Which other solutions did I evaluate?

We're currently looking at Oracle as an option to replace this solution.

With IBM, we're finding there aren't a lot of new features coming out. Oracle, in contrast, always seems to have something new. 

In terms of data security, we see some improvement in Oracle, however, we don't see a lot of new things coming from Informix. While both have data replication, in terms of bi-directional replication, both vendors are still not that good, especially when there's a very huge volume of data replication. Right now, we have to use a third-party data replication by SharePlex.

What other advice do I have?

We are using the latest version of the solution in our organization.

I was in the company for almost 20 years. Initially, we had quite a lot of databases. Basically, most of our big database was using Informix. And then, 10 years ago, we started the first migration to Oracle due to the licensing costs. On the first attempt, we changed to Oracle due to the fact that we got a very good deal from Oracle. Then, we moved one of the applications to Oracle. This year, the company direction is to go completely over to Oracle. That said, we still have one application, which until today we still use Informix for. That's why there's the intent to also migrate to Oracle, so that our company will focus on Oracle only, instead of multiple kinds of application databases.

I look at the current market trends. It seems like IBM Informix is a little bit behind compared to other big vendors like Oracle. Competitors invest a lot in new features, such as in-memory and those kinds of things. We don't see a lot from Informix. 

In general, I would rate the solution at a six out of ten. It's an okay solution, however, if a company is looking for something more innovative, there are other options on the market.

Which deployment model are you using for this solution?

On-premises
Disclosure: My company has a business relationship with this vendor other than being a customer: Implementer
COO at a tech vendor with 1-10 employees
Real User
Top 20
Cost-effective, good performance, easy to use, and the cross-platform capabilities are nice
Pros and Cons
  • "What I've been most pleased with is the cost point, performance, and ease of use."
  • "The analytics features are in need of improvement."

What is our primary use case?

The primary use case is as a reporting solution, data collection, data manipulation, and similar tasks. We install MySQL on Linux and Windows machines for testing our enterprise application.

We are a solution provider and this product is part of our offering to our clients.

How has it helped my organization?

MySQL hasn't really affected our organization, specifically because we primarily use it in a consulting model.

What is most valuable?

All of the databases basically have the same set of features.

What I've been most pleased with is the cost point, performance, and ease of use.

It is very easy to configure, it's easy to deploy, and it's cross-platform capabilities are quite nice.

What needs improvement?

The analytics features are in need of improvement. They aren't as far along as the capabilities that you have in terms of analytics for SQL Server and Oracle.

For how long have I used the solution?

I have been using MySQL for about five years.

What do I think about the stability of the solution?

I've had no problems with stability and its recovery processing, error processing, and things along those lines have been fine.  We always use Java applications and the JDBC drivers work fine.

I haven't had any issues at all with its reporting or its transaction processing, or anything else. 

What do I think about the scalability of the solution?

For our use-cases, the scalability is fine. We haven't seen any issues and we're processing probably hundreds of millions of rows each day. We're not into the billions or tens of billions, so we're probably a medium-to-low use case.

Most of our instances are single-instance databases, so I haven't had to deal with its clustering capabilities or distributed database feature set.

Our clients vary in size, although we generally operate as a small system inside a major organization.

How are customer service and technical support?

I have never had to utilize technical support. There was never an issue that I had to call in.

Which solution did I use previously and why did I switch?

I use a lot of databases including MySQL, Microsoft SQL Server, Oracle, and PostgreSQL. 

The performance of SQL Server and Oracle is better than MySQL. The two alternatives have other features, as well.

How was the initial setup?

The initial set up very straightforward. MySQL is easy to deploy and very easy to configure. We can literally bring up instances in minutes.

What's my experience with pricing, setup cost, and licensing?

This product has a good price point.

Which other solutions did I evaluate?

We had been on SQL Server and Oracle, and a subset of our customers wanted us to switch and use MySQL. We explored what that transition would take and then implemented it.

What other advice do I have?

My advice for anybody who is looking into implementing MySQL is to start by carefully evaluating their use cases. One of the things that we found is that MySQL didn't necessarily have all of the flexibility for JSON and XML processing at the time. I know that they've improved it, although it's not quite the same as what you see specifically in Oracle. So, the customer has to evaluate that. For straight-on basic transaction processing, it's worked out just as well with few issues from SQL Server to MySQL or from Oracle to MySQL.

For my use, I'm fine with what they have. I'll be interested in what they'll provide in analytics, as well as JSON and XML processing if that's even on their roadmap. For right now, it's really not an impact on my use case.

If I were rating SQL Server or Oracle then I would rate either one a nine out of ten. The only difference is that they do perform better than MySQL, although they don't perform so much better than it's relevant.

I would rate this solution an eight out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Vice President at a energy/utilities company with 5,001-10,000 employees
Real User
Top 20
Stable and scalable
Pros and Cons
  • "The solution is easy to scale."
  • "Technical support could be better."

What is our primary use case?

We work with the latest update.

We use the solution as a database. We primarily use it for the SAP application. Some of the use cases involve CDS Views, which provides a quicker processing of the report and the application.

What is most valuable?

The in-memory database is a good and valuable feature.

What needs improvement?

Since we use BW, we are required to use an SLT tool to carry out the data for generating the reports. But, when it comes to in-memory database in respect of the realtime reporting, I do not see why this report cannot be made available from the system itself. This would allow for some partitioning of the database, so that there would not be a need for the EMP in respect of the realtime data.

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle Database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for ensuring that this replication works as it should. It is at this point that the solution becomes stable. 

Technical support could be better. When we have requested this, the tendency has been to instruct us to implement a note and keep them apprised. In reality, there is no one who helps us with actual troubleshooting of the problem. 

The pricing is a bit on the high side. 

While I would definitely recommend the solution, I would caution that one should employ the proper resources that are geared towards the system. Unfortunately, SAP does not provide a structured training program, which means a person must rely on multiple system integrators and some service providers.

For how long have I used the solution?

We have been using SAP HANA for more than three years.

What do I think about the stability of the solution?

The stability is very good and we have encountered no issues regarding it. 

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle Database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for for ensuring that this replication works as it should. It is at this point that the solution becomes stable.

What do I think about the scalability of the solution?

The solution is easy to scale.

How are customer service and support?

Technical support could be better. When we have requested this, the tendency has been to instruct us to implement a note and keep them apprised. In reality, there is no one who helps us to actually troubleshoot the problem. 

Which solution did I use previously and why did I switch?

We had already been using SAP when we switched from it to Oracle, because all of the innovations were taking place on HANA. 

How was the initial setup?

The initial setup was complex. I am talking about how the data is replicated to the site. We had an Oracle database and did replication to the VR site. Yet, when it comes to HANA, we are forced to work out the method for for ensuring that this replication works as it should. It is at this point that the solution becomes stable.

The deployment lasted six months. 

What about the implementation team?

We deployed with the help of a vendor.

No real maintenance is required. Data volume management is needed and all the reports are available, based on which the maintenance is easy. 

What's my experience with pricing, setup cost, and licensing?

The pricing is a bit on the high side. 

The use of hardware does not incur additional costs. 

What other advice do I have?

There are 40,000-plus users making use of the solution in our organization.

I rate SAP HANA as an eight out of ten. 

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Get our free report covering SAP, IBM, Microsoft, and other competitors of Oracle Database. Updated: January 2022.
564,997 professionals have used our research since 2012.