One of the questions I get on a regular basis is some variation of "how can I choose what DBMS is the best"... so I'll try to offer some high-level guidance for posterity here in my blog.
This is actually a very interesting question, but the problem and the answers to it take on many different forms. For example, should I answer it based on you having no existing DBMS and you're just looking to buy one for the first time? That is a valid, though not too common, situation. On the other hand, you are more likely asking something like "Which of the several different DBMS platforms that we already have should we use for Project X?" This is also a valid question. So, let me try to answer both -- at least in some fashion.
First of all, if you are brand new to DBMS it would be a very wise course of action to hire a database consultant (or two) to help you with your selection process.Yes, consultants with specialized DBMS knowledge can be expensive, but not as expensive as purchasing or selecting an inappropriate DBMS for your project. A couple of days to a week of a consultant's time will be money well-spent if you do not have the internal expertise to make an informed decision on a DBMS platform.
But you came here to read my thoughts on this topic, so I will not just tell you to hire a consultant and not give my opinions! So what do I think about this topic?
Well, there are several very good choices out there. My preference is that new users should generally choose from the market leaders, and that means one of the big three: IBM DB2, Oracle, or Microsoft SQL Server. Of course, you also have other options such as an open source DBMS like MySQL or PostgreSQL. These are up-and-coming platforms and they can be used for some types of production work (mostly lower-end or simpler web-based development projects). For high-end mission-critical applications, stick with the Big Three.
OK, which of the big three? Well, if you work for a large organization with a mainframe and want to run your DBMS on that mainframe, you really should go with IBM DB2. Oracle has a mainframe version of their database server, but IBM is far and away the market leader here. Other mainframe DBMS choices are legacy hierarchical (IMS) or CODASYL (IDMS) system. For Unix and Linux installations, your choices are Oracle and DB2. Oracle is the market leader on those platforms, though IBM has a nice presence there, too. For Windows development, all three are viable options, but Microsoft (as might be expected) is the leader on Microsoft's OS.
What about other options? Well, Sybase, Informix, and Teradata are the next biggest players in the market. Sybase has lost ground in the market, but their DBMS is still solid and they are firmly entrenched in many financial institutions. Informix, which was purchased by IBM, is still being maintained and marketed, but DB2 is obviously IBM's primary DBMS – so I personally would not choose it for new work. Teradata is a high-speed DBMS that is geared for data warehousing and OLAP work -- and you might want to choose it for those types of projects. Still, though, my primary advice holds: stick with one of the Big Three as much as possible.
OK, so what if you have several DBMSs installed and need to choose between them for a new project? In that case, it is best to base your decision on internal company issues. Consider the existing support and expertise that you have in-house for each DBMS. If the project is highly visible it makes sense to go with the DBMS that is best supported by your in-house experts because they can give it the care and feeding it needs to perform optimally. Also, think about the hardware platform. For your very high availability needs go with the mainframe if you have one. After that, it is Linux and Unix... then Windows.
I haven't talked about cost yet, but it would be an incomplete answer without at least touching on that subject. When you are examining the cost of the DBMS software do not limit the analysis to just the initial cost and on-going maintenance cost that must be paid to the DBMS vendor. Look at the total cost of ownership of the DBMS. TCO should be calculated as a combination of the license cost of the DBMS, the license cost of any required supporting software (and hardware), the cost of database professionals to program, support and administer the DBMS, and the cost of the computing resources required to operate the DBMS. Also, try to factor in the reliability of the total package in terms of downtime - and factor in expected losses due to downtime if at all possible.
Determining the TCO for a DBMS can be difficult, and in many cases these type of decisions boil down to subjective opinions. Which DBMS is the favorite of the manager in charge? Or which one has s/he had experience with in the past? Whenever possible try to remove the emotional portion of the decision from the process. Reason, research, and analysis trump emotion every time...