Chapter 2. Server Programming Environments

You've had a chance to get acquainted with the general idea of using PostgreSQL, but now we are going to answer the question of why anyone will choose PostgreSQL as a development platform. As much as I'd like to believe that it's an easy decision for everyone, it's not.

For starters, let's get rid of the optimistic idea that you choose a database platform for technical reasons. Sure, we all like to think that we are objective, and we base our decisions on a preponderance of the technical evidence. This preponderance of evidence then indicates which features are available and relevant to our application. We will then proceed to make a weighted choice in favor of the most advantageous platform, and use a balance of the evidences to create workarounds and alternatives where our choice falls short. The fact is that we don't really understand all the requirements of the application until we are halfway through the development cycle. Here are some reasons why:

That is, unless you're one of the fortunate few who has a Research and Development department that writes the alpha version, throws it out the window, and then asks you to write the next version based on the lessons learned. Even then, you really don't know what the usage patterns are going to be once the application is deployed.

What we generally see in the PostgreSQL community—when new users start asking questions—is people not looking to make a decision, but rather people who have already made a decision. In most cases, they are looking for technical justification for an existing plan of action. The decision has already been passed. What I am going to write about in this chapter is not a TPC benchmark, nor is it about the relative merits of PostgreSQL functions versus stored procedures. Frankly, nobody really cares about these things until they have already made a choice and want to justify it.

This chapter contains the guide that I wish someone had written for me when I chose to use PostgreSQL back in 1998.