IBM Db2 Database Reviews

We use the solution for handling retail customer information. We use it as an integration broker. It stores all the vendor information.

We rely on it for our data transfers. If we need to send an invoice, for example, we'd use this product. 

The solution is very stable and reliable. It's a very mature product.

If you have specialized support, it's fine in terms of getting assistance.

The solution can scale. 

IBM gives us tools that help us 

When I look at Microsoft SQL Server, SQL Server provides me with better tools for database management. IBM is missing things like data permissions and backups, et cetera. Microsoft has a very user-friendly interface that IBM lacks. The user interface from IBM is not great.

I've used the solution on and off for the past ten years. 

It's a stable solution. It's been around for quite some time and is very mature. It's reliable. There are no bugs or glitches, and it doesn't crash or freeze. 

It's quite scalable. We haven't had any issues. We can reuse DB2 mainframes, et cetera. We haven't had issues. 

We're not increasing usage. We're pushing towards the cloud and Azure systems. 

We are a big customer of IBM and have some sort of specialized services. We have an elevated support agreement that helps. In general, it's not the greatest. That's only at a personal level.

Neutral

I am familiar with the Microsoft SQL Server, which is more user-friendly and has more user-friendly features. We're also exploring moving away from this solution to more cloud-based Azure services. 

The setup wasn't part of my job. We had a team that handled it. However, my understanding is it was straightforward. 

I don't deal with the pricing. I can't speak to its exact cost.

I'm not a database person. I'm a programmer. 

I'm using version nine in the company.

If a person wants to use the solution from a user perspective, I'd suggest they actually look at cloud programs, not IBM or on-premises. Cloud simplifies a lot of things. If I were starting from scratch, I'd go right to the could.

The reliability is excellent, and therefore I'd rate the solution eight out of ten. I only have issues with the user interface.

We work with a few use cases suggested by the IBM Watson Library. All the data is inside the event processor, we can extract it with a query. There are multiple use cases already in the IBM marketplace.

It's easy to search and extract data from the warehouse using queries.

The queries can be difficult for beginners because there are so many. I would like to see more use cases for flow analysis that enable us to correlate the flow with events. Adding this feature in a QI format would be good for beginners.

I have used Db2 for around two years.

I rate Db2 eight out of 10 for stability. 

I rate Db2 nine out of 10 for scalability. We have more than a thousand users. 

IBM's technical support is excellent. They provide a solution in 24 to 48 hours. 

Setting up Db2 is straightforward. Most IBM products I've used aren't complex to integrate or deploy. We deploy it on-premise and in the cloud.

I rate IBM Db2 two out of 10 for affordability. It's expensive but not much more than other tools. There are also cloud-based solutions like Elasticsearch. 

There are multiple competitors like Oracle, but Db2 is the best for our use case.

I rate IBM Db2 nine out of 10. It's more expensive, but it's better than the competing solutions. I have to deduct a point for license costs. Everything else is excellent. We recommend Db2 to many clients, but few adopt it due to the high price tag. If a project has strict budgetary restraints, we typically don't recommend Db2. 

I am currently using IBM Db2 for z/OS. It is used to manage a huge amount of structured business data and provides DB services for many different applications.

Its performance is great. In my case, half a million transactions per second are using the DB services of the Db2 mainframe. So, it provides a great ability to support logical units of work.

For every big organization or big site, such as a bank or a credit card company, the most important asset is data. An organization puts all its business data and manages it in Db2 because it trusts that Db2 will be able to provide all the necessary services, such as:

• Business continuation
• The ability to process a large amount of data
• The ability to maintain a large amount of data
• The ability to execute DB services in a fraction of a second

Its functionality and availability are valuable. Its availability is great. It is available 99.99% of the time. 

Its security is great, and there is also the ability to execute very complex SQL statements. It provides the developers the ability to get the functionality using great tools like SQL and many other additional features.

The management of Db2 should be simplified because there are not too many specialists in this area, and the learning curve of Db2 specialists is very long. After the courses, probably it takes one and a half or two years to get to the point when you are using the product properly in the production systems. So, the complexity is very high, and the most important thing is to simplify the management of the product, including self-maintenance. They should simplify the installation, management, and monitoring to simplify the product. It takes too long for a person to be a specialist in this product.

The price should also be adjusted a little bit. IBM is quite expensive with respect to the product.

I have been working with this solution for 34 years.

It is very stable.

It is absolutely scalable. It is hard to count the number of users. For example, in a bank, each and every customer of the bank uses the product. There are hundreds of thousands or, in my case, even millions of customers. There are also people who are not customers but access the website of the banks to look at something. Those people are not registered, but they're using the product as well. So, there could be millions of users. In the banks where I work, the business is growing. With the growth of the business, the number of users is also growing every year by a small percentage.

If Db2 is properly used, an organization can build a database with thousands of tables, and it can provide the exact information for the applications within a second. We have 500,000 transactions a second, and each of them needs to get some information from the database to perform a show, insert, or delete operation for different users. In the banking or finance domain, there are a large number of transactions. Even in a small country, there would be a large number of transactions every minute or seconds of the day. Db2 is capable of providing services for each and every transaction.

Currently, technical support is concentrated in IBM's main supporting facilities and laboratories. Years ago, each and every country had its own engineers who provided technical support, but today, it is concentrated in a few hands through the support centers of IBM, and their support is good.

Positive

Before Db2, we used IMS. It was years ago, and currently, in addition to Db2, the same organization is using Oracle, MSSQL, MySQL, and even NoSQL databases, such as MongoDB. During the past five years or so, the NoSQL databases are getting in as well. So, we are using a few RDBMSs and NoSQL databases as well in parallel.

When I compare IBM's mainframe Db2 for z/OS with other relational database management systems, this one wins against almost each and every other database in terms of abilities and performance. Optimizing the scales or optimizer for creating the access process is probably the best in the world. In many aspects, Db2 wins against almost each and every other RDBMS, including Oracle, Microsoft, MySQL, and NoSQL ones. However, in the area of complexity and maintenance, probably the others are better.

It is quite complex. It is not a simple installation. If the installation is done by a specialist, it takes a few hours.

It was implemented by our own in-house team. For deployment and maintenance, in a big organization, probably two DBAs are required to be on the safe side, in case one of them is on holiday or something like that. Two people are sufficient to maintain the product.

It is expensive. The price depends on the size of the machine on which you are installing the Db2 and the features you are using. It also depends on the country. IBM has different policies and different options for payment for this product. 

IBM Db2 manages a huge amount of structured business data and provides DB services for many different applications in banking, military, logistics, and other areas. Big organizations that are using IBM mainframe are using Db2 Database for providing the database services for various applications. Thousands of organizations in the world are using Db2 for managing their data—their most important asset. By using Db2, they can manage this huge amount of data by building an enterprise-wide data model, consisting of thousands of entities and tables. When built with a proper methodology, Db2 is a great asset for each and every organization.

IBM mainframe Db2 for z/OS would probably be the best platform if you need a database that is not limited to one specific area and can provide you with the following:

• Different DB services
• Different functional and application areas
• Parallel processing abilities with a big amount of relational structured data

It will be difficult to find a better solution for such a business.

I would rate it a nine out of ten. It is very good.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I use the product to audit databases, SQL statements, and user activities. I am currently working on migrating the on-premise database to IBM Docker.

The solution helps secure the database. We can encrypt the data and mask the tables using the solution.

When we enable audits on our database, there is a server overload. The product needs to improve its configuration and storage.

I have been using the solution for six months.

The tool is stable. I rate the tool's stability an eight out of ten.

I rate the product’s scalability an eight out of ten.

The support team didn’t give me a quick response to the issue I raised.

Neutral

The initial setup is complex. Since the database has various types of data, we must integrate it with the audit server. An expert in Linux can easily manage the integration.

It takes three to four days to deploy the solution. We needed help from IBM to implement the solution. We need only one person to maintain the product.

The solution costs less than other products. I rate the pricing an eight out of ten.

Guardium can be used in confidential environments. There are many customization options available in Guardium. We purchased the solution in 2018. I will recommend the product for auditing. Overall, I rate the solution an eight out of ten.

I use IBM Db2 Database for an application that we use in the marketing sector.

I was a consultant.

When we use IBM Db2 Database, we are using a simple SQL server. I didn't use all of the features. It's mainly because when I worked, they used to set up Db2 for DB.

The most valuable aspect of this solution is its stability. We have never had any problems and have never had to contact technical support.

The scalability could be improved, but the problem was that it was something in the legacy of the application where I work.

The problem was not the DB itself, but there were certain limits regarding the application, and the DB was the final component, where we worked. We weren't too concerned with the DB.

It's expensive, but it's not for every client. 

Also, the website could be more intuitive. I didn't find it easy to find documentation on the website.

I have been working with IBM Db2 Database for one year.

IBM Db2 Database was stable, we didn't have any issues.

IBM Db2 Database is not scalable.

We have approximately 8, 000 clients.

We didn't have any issues with IBM Db2 Database. It was stable for us. We did not have the need to contact technical support.

I have some experience with Terraform, from HashiCorp. 

It's a tool for infrastructure, for building automation similar to Jenkins, or Bamboo.

I worked with Bamboo a year ago.

I have worked with databases such as MySQL, IBM Db2, Oracle DB, and some NoSQL databases like MongoDB. We use the threat procedures when we used Oracle DB.

When I worked within Db2, I didn't set up the Db2. I just used it. I didn't do any tuning or anything like that. I only performed some database management.

Clients are required to purchase a license.

I would recommend this solution to others who are interested in using it.

I would rate IBM Db2 Database a seven out of ten.

It is installed on the mainframe that we use for our applications.

It's the best solution in terms of security, performance, and availability because the system is available 24/7.

The problem with this environment is that any software that you install is very costly because there are no free tools for this environment.

The environment itself comes at a very high cost because the mainframe machine is very costly, and the licensing cost is very high as well.

I've been using IBM Db2 Database for the past 22 years.

It's very stable, and the performance is very good.

We use IBM technical support for the big bugs related to the operating system and the database. We haven't faced any problems with the database. Sometimes, with the operating system we need some fixes, and technical support has sent us those. On the application side, our team develops the application and solves any problems related to it.

Previously, we used COBOL with a database sold by Computer Associates. We didn't have lot of choices for mainframes at the time. The best database that can run on the mainframe is the IBM Db2 Database, and we have stayed with Db2 from 2000 to the present.

The initial setup was quite simple because we've been working in this area for more than 40 years.

It took about a year and a half to develop and deploy the whole application.

We developed the application, and we deployed it using a solution strategy. We have an IBM partner who gave us all the software that we needed, and we implemented it ourselves.

We had three system engineers, two people for the database, and two people for the application.

Our ROI is big because we earned about 100 billion in our currency.

It's very expensive for West African countries like ours.

We are currently in discussions with IBM concerning the reduction of licensing costs. We have a license based on the capacity of the machine and are looking into a license based on usage.

There weren't a lot of choices for mainframes at the time.

If you're going to use it for the first time, you would need lot of training and some technical support. You would need support during development as well.

I would rate this solution at nine on a scale from one to ten.

We primarily use the solution as the main data store warehouse for the corporation.

It's great as a backend database system utilized to store the data for the entire corporate structure.

Due to the fact that we're going to go with the hardware-specifics of the fact that it's bundled in IBM i, it's exceedingly reliable, as the architecture of the IBM i just does not go down.

It runs very well. It runs very solid. It does everything that I expect it to do. It offers all of the standard RDBMS functionalities and capabilities. I consider Db2 to be a direct competitor with Oracle and SQL servers any day of the week. The difference is what flavor of Db2 you're going to run. You're going to run the Linux Unix, are going to run the IBM i version, and then it comes down to, for me, the IBM i, due to the fact that the architecture does not fail. It does not go down. It does not get hacked. There's never been a successful hacking of an IBM i architecture. You're looking at an environment where your data is extremely secure, compared to a lot of the other RDBMS systems.

The solution is configurable and has what you would consider to be a desktop management configuration capability too. You can partition it off, and you can set up different instances of it and such. The interface is more than adequate. There's nothing great about it, there's nothing poor about it. It's more than capable of doing what you need to do if you do need to do DBA maintenance kind of work to it.

It's going to be a much smaller marketplace for this product, and most significantly, IBM doesn't target marketing to that marketplace. Their view of it is they're maintaining it, they're continuing to upgrade it, they're continuing to grow it, however, they don't go out and try and sell that as an architectural solution the way they do Linux and Unix. That's because once you get inside of the IBM architecture, up until about six or eight years ago, it was not open source. You were tied to the development language of either COBOL or the development language of RPG if you wanted to develop on that platform.

Now, it now supports Java and PHP, and it does open source, but for those reasons, IBM was never looking to market or push that as a viable solution. They didn't push the IBM i as a direct competitor to Oracle, they pushed their Linux Unix versions of it, their IBM Z series against Oracle and SQL server, as it's a more direct head-to-head comparison. The IBM i architecture is the one-off if you will. You're not going to see a lot of people looking at it.

I've been using the solution for 25 years at this point. It's been a while. 

The solution is stable and reliable. The hardware does not fail, the software does not fail, and so the reliability is there, however, the reliability isn't necessarily Db2, it's the fact that it's the IBM i that has the reliability. Db2 is inheriting that, and again, is staying up and running because of that.

The system scales very well. It runs the new power nine chips and it's about to run the new power 10 chips that IBM is releasing as well. For that reason, the current systems out there are 16 CPU Power 10 processors that can have terabytes of memory associated with them. It performs extremely well in the environment. 

The system is very scalable to very large magnitudes. There are some very large Fortune 10 and Fortune 15 companies that run Db2 systems and can attest to the scalability

IBM's technical support is fine and their people are good. When you give them a call they get after it. We're satisfied with the level of service provided. 

The initial setup is very straightforward. Due to the fact that it's bundled inside of the system, you don't have to do any special implementation. As soon as you have the system up and running, and the operating system running, Db2 is already running. There was an instance of it running on the architecture at that moment. There's absolutely zero setup in that environment.

It's hard to separate out the exact pricing. It's bundled; you can't compare head-to-head against Oracle and SQL server at that point, as the costing is embedded inside of the purchase of the operating system software.

We're not a software provider, we're an end-user.

When you start talking about Db2 on Linux and Unix, the current version is version 17.3 or 17.4. The IBM i, the versioning doesn't work the same way, it has to do with the operating system levels that you're running, as to which version of Db2 you're in. It's integrated in with the system, operating system. It's not actually an independent version of Db2, it's integrated in with the operating system on that platform.

Db2 is different in our architectural world than standalone Db2. It's not like standing up an instance of Db2 would be the same as it would in Oracle, or a Microsoft SQL instance, on a Windows 10 server or a Windows 2008 server or whatever it may be. It's the fact that it's bundled in with the software, with the operating system, with the hardware, when you buy that machine. Since it's all bundled inside of it, we're having to go out and independently do things with it. It's inherent, it's bundled. It's probably not the best example of Db2, because even when IBM goes out and talks about Db2, they talk about Db2 zOS, which is the Linux Unix installation. You very rarely see them talking about the IBM i installations. In fact, in even the documentation I was reading in the comparisons, it was comparing the Linux Unix IBM Db2 against Oracle, and against the Microsoft SQL Server.

If you're looking at an alternative to Oracle or to Microsoft SQL server, look at Db2, and then once you're in Db2's world, take a look at IBM i against the IBM Z, and compare the two of them. The stigma that the IBM i has, is that RPG language barrier. Since that barrier has now been removed, you can do everything that you can do on the IBM Z as well. The stability of the platform is what people need to look at. There is a trade-off of uptime and never been hacked operating system against versus Microsoft and Oracle in the news every single day. Microsoft cloud just made a comment in the last 48, 72 hours about their cloud services being hacked. That's just something you do not see happening with that IBM series architecture.

Since Db2 rides inside of very secure architecture, people should probably give it a very good, hard look, compared to Oracle and Microsoft, and say, "Hey it might not be as popular. It might not be as big a deal, but if my data is more secure, and I don't have downtime and I have performance, is it something that we should be looking at?" 

I've been at companies that have looked to move off of that, and when they've looked at the Oracle solution, and, no matter how you power it, and no matter how you scale it, whether you scale it up or you scale it wide, the performance is simply just not there compared to what the IBM systems offer through their Db2, whether it be the i or the Z through what they offer internally in their performance capabilities. Your iOS, your throughputs, your performance cycles, you cannot touch it with Microsoft or with Oracle scalability-wise. That is far and away the most scalable systems and the highest performing systems of the set of them.

I'd rate the solution at a ten out of ten.