For the most part, if you are writing to the RDBMS / SQLish market, the number one question you should probably ask is, “What do I already know? What do my employees know?” If you have an answer to this question, you should first select this SQL engine. My internal database blowing is compressed in this answer, but in truth, if your developers are not in the tiny fraction that really gets relational databases anyway, you will use the same standard error rates of standard databases as everyone the rest, and the main question will be whether you can make your system go fast enough.
This is probably the case if you swallowed a jug of NoSQL drink of your choice, since there too you have to choose what you understand.
If you can already understand all these differences, then you will understand that the answer is "it depends." The usual four dimensions come down to the following: execution speed for a given workload profile (this is a question of whether the database is different for a specific problem: some are faster to search, for example, when others are better at high concurrency records); Matching SQL in the target areas (for example, Oracle has a funny - that is, incorrect - NULL processing, MySQL - all over the map, Postgres wraps unquoted identifiers in lower case); cash costs, both immediately and in the long run (including equipment requirements, costs for hiring people, licenses); and maybe the features you want (if you want Oracle RAC, you need to buy Oracle).