I've been reviewing database choices as part of the lead up to a small miracle - a project from some years ago is being resurrected by users who've wrestled some small measure of control back from the IT group that was supposed to take the ideas from my Cocoon demo to production.
Sometime over the next few weeks I'll be able to try out some code against both the database I used last time, PostGresSQL, and a couple of competitors. Right now, however, I'm betting on PostGresSQL.
When Dr. Michael Stonebraker founded Ingres at UC Berkeley in 1977 he'd been at Berkeley for about six years, been influenced by personal relationships with all the key Unix players, and done considerable work on the theory behind Codd's relational models. With Ingres (Interactive Graphics and Retrieval System) he took Codd's ideas beyond the COBOL data types to include more complex forms such as text and imagery. Ingres spread through the Vax/Unix community almost as fast as jokes about its performance (How do you stop a two ton Vax? Set range not null.) and became the basis for the commercial relational database management product CA is now rumored to have offered Sun and other players essentially for the cost of taking over support.
Despite becoming a commercial success in its own right, Ingres was a first draft: an early experiment with ideas that would take another 20 years to work out. Thus, the next generation at UCB, still under Dr. Stonebraker's direction, became known as PostGres in part because it shared no code with Ingres.
Initially, PostGres research focused mainly on object storage in an attempt to actually enable the plugin processing envisaged for Ingres, and on further developing QUEL -- a non SQL query language that I always envisaged as a direct pipeline to the data. A key spin-off from that work was another commercial product ultimately known as Illustra -- the first truly object relational database that let developers add their own data types, complete with code to handle the requisite indexing and processing, to meet whatever unique requirements they might have.
Illustra was barely off the ground when it was sold to Informix, unfortunately just as that company joined the NT bubble in a highly successful attempt to commit corporate suicide by abandoning the technology-driven Unix market for the Microsoft money mirage. Today, IBM owns what's left and has been gradually adding some of the technology to DB2.
UCB PostGres developed into a slow but powerful open source database and research tool that formed the basis, via its BSD license, for a number of commercialization projects --most of them focused on abandoning QUEL for the more commercially popular SQL. The PostGresSQL team, in particular, initially focused on SQL but then moved, with release of the 7.1 product in 2001, to improving performance and administrative tools.
More recent work on things like improving the usefulness of having PERL integrated into the server; Joe Conway's statistical integration engine (proving that much of the Ingres dream has been realized in PostGresSQL) and slony (enabling on the fly replication) is so cool that I think PostGresSQL may now lead the field.
Red Hat didn't make much of a success with it, but the people behind enterpriseDB seem to have a pretty fair shot at hitting the market's hot spot. Their shtick is to go one step beyond replacing the query interface to incorporate specific functionality aimed at making their version of PostGres directly compatible with Oracle's primary RDBMS product suite through incorporation of the PL/SQL interface extensions.
Oracle is not universally beloved, and is at serious risk of seeing its market retire as more and more systems decision-making falls to younger people whose first loyalties might be to Microsoft or open source, instead of to IBM or Oracle. That's the market enterpriseDB is going after, and by all reports I've seen so far, they might well have the product to do it.