Why are there so many Database management systems? I am not an DB expert and I've never thought about using another Database other than mySQL.
Programming languages offer different paradigms, so it makes sense to choose a specific language for your purpose.
What are the factors in choosing a specific Database management system ?
Database systems offer different paradigms too. For instance, MySQL or MSSQL are relational, while db4o is object-oriented, and MongoDB is document-oriented.
Different Strokes for Different Folks:
I know next to nothing about non-relational DBMSs: NoSQL, MongoDB, db4o, CouchDB, BigTable. I'd recommend a different question to address those, since their aims are different than traditional RDBMSs.
DBMS are around for many many years and very important for the IT infrastructure in the past, nowerdays and for the future. So a lot of people tried to get into the business. There are a lot of office suites, internt browsers, etc, etc.
What are factors to choose a specific DB management system ?
There's a noticable absence of e.g. column-oriented (LucidDB), platform independent (derby), in-memory (hsqldb, although derby fits here as well) and probably other databases, as classified by their key properties.
If the paradigms are the same, it's also a market sharing issue.. (Has it been skipped?!?) Otherwise, Peter's answer is considerable.
"This answer doesn't really answer 'why', it just answers 'who'."
True, but I guess the answer to 'why' might be that there have been so many 'who' 's who all thought they could do it "better than the others".
With "better" having the significance of a fill-in-the-gaps that the particular 'who' chose to pick on :
My personal pet issue is support for CREATE ASSERTION. It's been in the SQL standard since 1992, and none of the big elephants know how to support it. I do.
For the most part, if you are writing for the RDBMS/SQLish market, the number one question you should probably ask is, "What do I already know about? What does my staff know about?" If you have an answer for that, then you should probably pick that SQL engine first. My inner database geek cringes at this answer, but the truth is that unless your developers are among the tiny fraction that really get relational databases anyway, you're going to use the same deep ruts of standard database mistakes as everyone else, and the main question is going to be whether you can get your system to go fast enough.
This is probably true if you've swallowed a pitcher of the NoSQL beverage of choice as well, since there too you have to pick the thing you understand.
If you are already in a position to understand all these differences, however, then you will understand that the answer is "it depends". The usual four dimensions come down to these: execution speed for a given workload profile (this is a matter of whether the database is excellent at the particular kind of problem: some are faster for lookup, for instance, where others are better under high concurrency writing); SQL conformance in the target areas (e.g. Oracle has funny -- i.e. wrong -- NULL handling, MySQL is all over the map, Postgres wraps unquoted identifiers to lower case); money cost both immediately and over the long haul (include hardware requirements, costs of hiring people, licenses); and maybe features you want (if you want Oracle's RAC, you have to buy Oracle).