From Ingres to EnterpriseDB

From Ingres to EnterpriseDB

Summary: Oracle is not universally beloved, and is at serious risk of seeing its market retire as more andmore systems decision making falls to younger people whose first loyalties might be toMicrosoft 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.

TOPICS: Software
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.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Cheaper perhaps but not very innovative

    It would be much more interesting to see an open source implementation of the ideas for the future of relational systems put forward in Date and Darwen's "Third Manifesto". However we need the courage to abandon SQL. (Glad to see Quel getting a mention in the article by the way).

    The practical improvements in terms of view updateability, strong typing and more consistent methods of handling unknown values seem compelling.

    So far "D" has only been implemented in the .NET environment. It would be great to see an open source version.
    • Completely agree


      I completely agree. An open source database engine supporting "D" would be great. It's unfortunate that replicating Oracle, warts and all, is more important for commerical success.

      It would seem that given 20-30 years of experience and lessons learned one could get a database engine closer to the relational model.
  • Firebird's Fyracle better than EnterpriseDB

    Google for "Fyracle". Firebird's oracle-mode is much more advanced than EnterpriseDB.
    • Advanced in what sense?

      More compatible with Oracle or more "advanced" in some other way?
      • Fyracle is more compatible

        Fyracle is more compatible. Even PostgreSQL luminary Josh Berkus admits as much:
        Or Robin Bloor:
        Or Paul Richter:
    • Will check this out

      Thanks for pointing me to firebird.

      Oracle compatibility isn't an issue for the work I'm doing and Firebird wasn't a starter when I did the work the first time (2nd half of 2002) but I'll look closely at firebird this time around and consider the issue of oracle replace-ability at another time too.
  • How this project got sidetracked....

    ...sounds like a story in itself. And it's a reflection on what I wrote today, although not a direct one.

    Paul talks here of control being reasserted after it was lost to some corporate types, and that's interesting.

    I for one would love to learn more about that, not about the specific case but about the process of gaining and losing control over a project.
  • RE: From Ingres to EnterpriseDB

    Take a look at

    As with any research this project initially of academic interest, but with the profusion of tools and OR mapping layers shifting the persistence language from SQL to something closer to the application's model could be viable.

    Bill Maimone