This has been one of the most hilarious parts of my development life. I recently recommended a local company to use PostgreSQL for a reporting system. The company in question wanted to know that if they chose PostgreSQL, would anyone on staff be able to maintain it. So, I began to interview the developers to find out about their experiences with PostgreSQL.

Me: Do you have any experience with PostgreSQL?

Developer 1: Yes, I used it at the last job for a product fulfillment project, but I don't think many people have that experience. We should probably stick to using MySQL.

Me: Do you have any experience with PostgreSQL?

Developer 2: Yes, I used it at the last job for a reporting project, but I don't think many people have that experience. We should probably stick to using MySQL.

After interviewing all seven developers that were influential on the project, I found that the only person without hands-on experience with PostgreSQL was the project manager. Since...

About 2 months after Oracle bought MySQL, they announced a plan that divided the development into two camps: a MySQL community edition and a professional version. The community edition would no longer gain any new features, and the professional version would become a commercial product.

There was a vast and thunderous sucking sound in the open source community, as they thrashed wildly about to find a new platform for Free and Open Source Software (FOSS) development.

Oracle immediately (in about 2 weeks) countermanded the order and declared that things will stay as they were for the indefinite future. Those with short memories, forgiving hearts, or who just weren't paying attention went on about their business. Many other open source projects either switched to PostgreSQL or suddenly grew PostgreSQL database support.

Today, we have MySQL and MySQL Enterprise Edition. If you want backup, high availability, enterprise scalability, and the MySQL Enterprise Monitor, you now have...

This section could just as well have been titled standards compliance, but I decided against it because the benefits of standards compliance in corporate projects are not obvious. The limitations of the common databases are well-documented, and I will show you a few websites in a moment where you can make a comparison of who has the most unintended behavior. I will encourage you to read the following material while thinking about the question, "Which method of feature development is most likely to make my application break in the future?":

Oracle and SQL Server don't have a community. Please understand when I say that, I mean that the chance that you will get to talk to a developer of the core database is about the same as your chance of winning the lottery. By the time you do, it's probably because you found a bug so heinous that it couldn't be ignored and the only person who can understand your report is the guy who wrote the code in question. They have paid technical support and this support has proven in my experience to be generally competent, but not stellar. I have had to work around the problem that I originally requested help with about 40 percent of the time.

Compare this to MySQL and PostgreSQL, where just about anybody can speak to just about anybody else all day long. Many of the core developers of both the platforms can be found on IRC, met at conventions, contacted for contract development work, and for the most part, bribed remarkably easily with beer (hint, hint, wink, wink, nudge...