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?":
Note
Spoiler alert:
A stricter adherence to standards comes at the cost of not allowing ambiguous behavior. Not allowing ambiguous behavior makes the developer's life more difficult. Making the developer's life more difficult ensures that the interpretation of the commands that the developer gives will not change later, breaking the application.
Just how lazy can you afford to be? I'm not sure how to measure this. PostgreSQL is available for no-cost future predictability, so I don't have to answer the question.
Sure, PostgreSQL also has some bugs listed. However, changes to the database core have a tendency to make the engine work like the documentation says it does, not like the documentation should have said. PostgreSQL developers don't have to say, "Oops, I didn't think of that," very often. When they do, PostgreSQL just becomes more standards compliant.