Britton-Lee, which I first visited in 1983, basically had a very early client/server system, based on a handful of Z80s (Zilog’s Z80 was a technically worthy competitor to Intel’s microprocessor family, back before it was obvious Intel would conquer the world). Bob Epstein, previously head of the Ingres project and later CTO of Sybase, was involved. Britton-Lee also owned an unrelated software vendor named Altergo, as some kind of financial play. (For a company that at various times had both Richard Currier and Vaughan Merlyn working there, Altergo never amounted to much. Of course, Richard was long gone by the Britton-Lee days.) Fine entrepreneurs though they no doubt were, neither Dave Britton nor Geoff Lee really seemed to quite fit the enterprise software or hardware CEO mode, and the whole thing never really achieved ignition.

Teradata may have come more out of the Tandem tradition, via Citibank. (Teradata’s official company history credits CalTech but not Tandem.) I first visited Teradata in 1984 (when they started shipping product), meeting Chief Scientist Phil Neches.and a CEO out of Amdahl in whose office I saw golf tournament trophies for the first time in my life. Cocky young stock analyst that I was, grilled them about their lack of support for standard tools, such as SQL (they were a QUEL shop) or fourth-generation languages. I distinctly remember going to a blackboard or white board (I forget the detail as to which), and holding forth about the features of a competitive 4GL, with Phil taking copious notes. The basic product architecture in those days was a tree of microprocessors (I think Intel 8086s), with each parent node talking to two children, until it got down to the lowest-level nodes that actually talked to disk. (This is what was called Ynet.) The architecture meant that almost exactly half the microprocessors talked to disk, and 50% wasn’t necessarily bad overhead at all.

And that’s most of what I recall about database machines or data warehouse appliances before the mid-1990s, so I’ll stop right there.

So with no further ado, here some observations of and about Ingres through the years.

• Ingres was of course the first of several DBMS companies spun off from UC Berkeley’s INGRES research project, and one of several started with Mike Stonebraker’s involvement. I wrote about that history briefly in my now-defunct Computerworld blog.
• Ingres (then called RTI) and Oracle (then called RSI, for Relational Software Inc.) were of course arch-rivals. As a general rule, Ingres was first to market with new features such as a 4GL or a truly distributed DBMS. Oracle, however, was the first to market with the features customers most cared about, at a level of completeness they found acceptable. Eventually, when Sybase was a factor too, Ingres was always betwixt and between — everybody’s second choice, but not the first choice of enough buyers to keep on prospering. (Later on in the 1990s, Gupta took over the Ingres role in the low-end market — the product was broader than Powersoft, but who cared?)
• Ingres was eventually merged into ASK Computer Systems. While surely a distraction, that’s not what killed it. Each predecessor company had its own problems, and they pretty much stayed out of each other’s way, at least in product strategy. What killed them is that neither side of the business managed to stay fully competitive in product.
• Ingres’s fatal technological mistake was whiffing on parallelism. And it did so in the most painful of ways. Ingres had a joint development project going in the Portland, OR area with Sequent, to develop a parallelized version of their DBMS. They pulled out due to expense, and Informix stepped in. And that’s how Informix managed to be competitive with Oracle in parallel processing, while lack of competitiveness in that area is what doomed Sybase and Ingres. Ouch!!!
• A second Ingres failing probably wasn’t as big as I thought at the time. This was an inability to offer abstract datatypes, aka object/relational, aka UDBMS (where the “U” is for “universal”). I thought this feature would be hugely important, and my opinion on that score probably was a big part of influencing Informix to overpay for Illustra. But Microsoft has never had the feature, and it doesn’t seem to have suffered all that much in the marketplace for its lack.
• ASK was doing even worse on the product side than Ingres — it never came out with a decent GUI version of the product, although they did get a license to resell Baan’s code — and the whole sorry mess was eventually sold to CA. CA has a well-deserved reputation for slashing development costs and profiting from slowly-dying software products. But I watched this acqusition from the inside, and to this day I think they really wanted to make the product competitive. But there was one not-so-little problem …
• CA ran off all of Ingres’s engineers right after the acquisition. CA’s policy upon acquiring companies was requiring employees who wanted to keep their jobs to sign non-compete agreements. In Ingres’s case, however, that policy was a spectacular failure. Oracle, Informix, Sybase, and much of IBM’s DBMS development were all located in the Bay Area. Finding another local job for these guys (and gals) was EASY. Competitors went into a feeding frenzy hiring Ingres engineers, and there was essentially NOBODY left. In my judgment there was a reasonable chance CA could revitalize development with an aggressive investment strategy, but they ultimately blinked. And with very limited ongoing development, the product obviously faded quickly as a mainstream competitor.

I think I’ll go write about the rest of the story over in the DBMS2 blog.