In the age old argument about the imperitive vs. the declarative5 programming models, it occurs to me that declarative programming is just imperative programming in a thin disguise. Each declarative token in a database query language ultimately maps to one or several algorithms which apply the declaration in imperitive terms. Thus, the impedance mismatch defined by Henrietta is ultimately in the mind of the developer. That is, if the developer would think exactly like the database function programmer thinks, then there would be no mismatch.

So how could a declarative model ultimately be better than an imperitive model, given that one is just a calling feature of the other? Glad you asked, because that brings me to my point.

The PostgreSQL developers are smarter than you. I don’t mean that to be facetious or coy. Literally thousands of contributors have made millions of contributions to the PostgreSQL project, many of them as improvements to the contributions of others. The chances that whatever you thought up on the top of your head is better than what has already been implemented is very low. And, even if your thoughts were better, you should contribute them to the PostgreSQL project for the benefit of all, thus raising the bar for everyone else.

So, what makes PostgreSQL so wonderful then? Worldwide mindshare without corporate considerations. Thousands of developers are working hundreds of thousands of hours to make better algorithmic choices. So your software gets better every release, most usually without having to do anything in particular on your part.

Isn’t that the nature of software in general, you say? Well, yes. But not to anywhere near the extent that it is when the entire world is involved in your project. PostgreSQL enjoys a very prominent place in the open source community. Commercial vendors will never be able to keep up with the rate of change that an open source project can provide at this level. The migrations to open source (and particularly PostgreSQL) are here to prove it.

The features keep rolling in. There are very few things left that commercial vendors can point to as a distinct advantage. Among those things are SMP support, bi-directional replication and external tools. Guess what the community is working on now, and will very likely release in the next few years?

Extend PostgreSQL any way you like

PostgreSQL has a vibrant community of authors that write ancillary software. This includes plugging in any language that you like, and using it to extend PostgreSQL in any way that seems helpful. Do you happen to like perl string handling? Ok, then use that. How about Python map support? Sure, just plug in python and go to town. Want to write web services using a PostgreSQL back end? That’s awesome, and PostgreSQL will help. JSON? Ok. XML? You bet. PostgreSQL has direct support for all of that and infinitely more. If you can think of a language that does it well, then plug that in to PostgreSQL and you can have it on the server side.