Most of the comments are right. Define your needs, fit the definition with the tool that fits best.

However, there is one thing that is mostly missing from almost all of the posts that ought to be very heavily emphasized

In most cases, when you first create your application, stick to only ANSI standard SQL. Stay away from the proprietary stuff from the database. Unless you want the pain of changing over at some time in the future (or the pain of being stuck with what you have). There are situations where this is the wrong path, but those situations tend to be self-evident (like must use Brand A ERP in same db engine, or your DBAs are incapable of handling a simple DB)

I normally start with a mysql database (its free, runs great and provides most everything a project needs) unless transactions were required (though that may no longer be a problem since transactions are included in some MySql table types). Then we do the project. Lower entry cost is a wonderful thing. If the needs of the project change in the future (never seen an exception unless the project dies), then you can reevaluate the situation and switch. If you have coded using non-standard stuff, then you will have big issues.

Now, I use MySql because it is what I am most comfortable with, but PostgreSQL does a darn good job as well. I just am not as experienced with it.

So unless you have a standard in company to work with (as mentioned above), I start with a freebie and build a project from there to minimize costs. Once a project starts showing its value, then I might look at a non-free db if there are issues that are not being handled.

I wish you luck!