July 11, 2014

20th Century DBMS success and failure

As part of my series on the keys to and likelihood of success, I’d like to consider some historical examples in various categories of data management.

A number of independent mainframe-based pre-relational DBMS vendors “crossed the chasm”, but none achieved anything resembling market dominance; that was reserved for IBM. Success when they competed against each other seemed to depend mainly on product merits and the skills of individual sales people or regional sales managers.

IBM killed that business by introducing DB2, a good product with very good strategic marketing from a still-dominant vendor. By “very good strategic marketing” I mean that IBM both truly invented and successfully market-defined the relational DBMS concept, including such conceptual compromises as:

In the minicomputer world, however, hardware vendors lacked such power, and independent DBMS vendors thrived. Indeed, Oracle and Ingres rode to success on the back of Digital Equipment Corporation (DEC) and other minicomputer vendors, including the payments they got to port their products to various platforms.* The big competitive battle was Oracle vs. Ingres, about which I can say for starters:

*Ingres actually had more ports than employees, when both totals were in the 40s.

The next big RDBMS showdown was Oracle vs. Sybase, my views of which can be summarized as:

The Oracle vs. Informix battle was similar: Informix had a good architecture story, but eventually screwed up development strategy, specifically in an over-ambitious plan to integrate several disparate DBMS.

Through all this, Teradata prospered in its RDBMS niche, namely large-scale data warehousing. That story can be summarized as:

Teradata’s success is particularly noteworthy because it survived being owned by two ponderous behemoths, AT&T and then NCR.

Progress Software also had some niche RDBMS success. Noteworthy aspects included:

Object-oriented DBMS never got off the ground, Intersystems Cache’ eventually excepted. The core problems were:

Considering the subsequent popularity of object-relational mappings and NoSQL, this can be viewed as a major strategic or execution failure. There should have been a way for OODBMS to prosper.

And that brings us to the end of the millennium, which is a good place to take a break. A companion post covers more recent developments.


8 Responses to “20th Century DBMS success and failure”

  1. 21st Century DBMS success and failure | DBMS 2 : DataBase Management System Services on July 14th, 2014 1:37 am

    […] The list turned out too long for a single post, so I split it up by millennia. The part on 20th Century DBMS success and failure went up Friday; in this one I’ll cover more recent events, organized in line with the […]

  2. 21st Century DBMS success and failure | Sebans on July 14th, 2014 5:39 am

    […] The list turned out too long for a single post, so I split it up by millennia. The part on 20th Century DBMS success and failure went up Friday; in this one I’ll cover more recent events, organized in line with the […]

  3. Judging opportunities | Strategic Messaging on July 16th, 2014 11:59 am

    […] 20th Century DBMS industry successes and failures […]

  4. David Brower on July 22nd, 2014 4:57 pm

    There was never a time when Ingres had more ports than employees — I was #185, and we were maybe 10 machines at the time. In 1984, when I joined, Ingres has just done something like $35M in business, and Oracle had just done $60-some million, IIRC. Never got closer.

    I disagree with the conclusion that parallelism had much to do with Ingres’ business failure. That wasn’t a big deal at the time things went south. The real cause was the several year side-step to do a decent SQL, while re-architecting everything else at the same time. Both Ingres and Oracle had survival issues with their re-architected V6’s, and Ingres didn’t make it. The major reason seemed to be that Oracle used financial strength to strangle Ingres. Arguably, Ingres worked better and with less problems right up to the demise, with the sole exception of multi-versioning/concurrent read.

    Your account of the “non-compete” running everyone off is mostly accurate. I ended up at Oracle, being tired of working for the losing side.


  5. Curt Monash on July 23rd, 2014 2:24 pm

    I was told there were over 40 ports back when the headcount was in the 40s as well. Is it possible that the majority of those were so minor as to be abandoned?

    Hmm. Maybe we should fact check this with Gary Morgenthaler or something. 🙂

  6. David Brower on July 25th, 2014 2:40 pm

    The only way I’d belive 40/40 is if someone were counting independent ports of the university Ingres code as well as those by RTI — or maybe if every version release was counted separately. In 1984, Ingres 2.0, 2.1 and 3.0 was on: VMS, VAX/BSD, VAX/SV, 3B5/15, Sun, Burroughs/Convergent Megaframe, CCI, Sequent, Pyramid, nascent 370/VM and not much else that I remember. The platform explosion came 85-88 when there were more people, post move to Alameda with more space in the machine room.

    Dave Kellog’s account also makes sense, though I think he misses the pressure the 5->6 rearchitecture took on resources for features (like row locking, which was eventually done 92-94 for Openingres 1, a/k/a 6.5).


  7. Curt Monash on July 27th, 2014 2:14 pm

    How about Fortune Systems?

    In general, that was the era of the first round of UNIX boxes.

    And who supported Prime when?

  8. David Brower on July 29th, 2014 3:51 pm

    I don’t recall there was ever an RTI Ingres on Fortune, or Prime/Primos Almost certainly an Oracle on both. Fortune blew up quick; there might have been an Ingres on Prime later, if they ever had a UNIX.

    Ingres only really did VMS, UNIXes and VM, and much later the HP proprietary one whose name escapes me. Oracle was always much more amenable to the minicomputer vendors who had proprietary OS’s (eg: Prime, Data General).

Leave a Reply

Feed including blog about software history Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.