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:
- Ted Codd’s 12 rules, not that anybody — even IBM — actually followed them all.
- SQL as the standard, rather than the probably superior QUEL.
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:
- Oracle won. 🙂
- Oracle was generally more energetic and aggressive, top to bottom.
- Oracle used SQL; Ingres used QUEL; this was important.
- In general, Ingres tried to give customers what they should want; Oracle tried to give them what they actually wanted.
- Both companies did a poor job on product quality, but somehow Oracle succeeded in seeming more mature, stable, complete and enterprise-ready.
- Rarely has a company grown as quickly as Ingres and still been an embarrassing “failure”.
*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:
- Sybase was a late enough entrant to be at a significant disadvantage, but gave Oracle a good scare even so.
- Sybase’s core strength was messaging. In particular, Sybase assumed the mantle of client-server architectural leadership. One unfortunate side effect was that Sybase persuaded the industry to rely heavily on stored procedures; maintenance nightmares ensued.
- Sybase also had aggressively successful field execution.
- Sybase would up losing because of a particularly terrible product release — Sybase System 10 –and delusionally bad development execution in general.
- But Sybase managed to long prosper anyway in certain markets, especially Wall Street (where client/server was a particularly good fit) and China (where comeback CEO John Chen had cultural ties).
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:
- In its niche, Teradata had massive architectural superiority.
- Only a limited number of large accounts cared, so Teradata could get by with good sales execution, and didn’t need much marketing visibility.
- Teradata was non-religious, switching from QUEL to SQL sufficiently early, and later minimizing the proprietary nature of its hardware, in both cases to obviate customer objections. (Ironically, Teradata’s biggest competitive problems later on came from Netezza and Exadata.)
- Teradata products for a long time were cool (best performance on the biggest jobs) but not weird (standard RDBMS).
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:
- Progress led with its eponymous application development tool, while its RDBMS was a bit secondary, a strategy that made sense in the era.
- The RDBMS focused on “zero DBA” operation.
- Progress’ main niche was companies developing applications to sell to small/medium businesses.
- Progress had a large secondary niche in large-enterprise applications that were meant to be deployed to large numbers of remote locations.
- Progress’ non-glitzy persona was a good match to its customers. Even so, Progress’ extreme lack of marketing was costly.
- Informix was very competitive in Progress’ market, but refocused on the admittedly much larger large-enterprise general-purpose RDBMS sector. (I criticized the decision at the time; Informix’s low-end business was too good to just give up.)
- Progress defocused too, using its core business as a cash cow for various enterprise software ventures, which didn’t work out well.
- Progress was slow to address its core customer base’s need to switch from on-premise to SaaS (Software as a Service) delivery.
Object-oriented DBMS never got off the ground, Intersystems Cache’ eventually excepted. The core problems were:
- OODBMS were weird (very different application development paradigm) but not very cool (they had fizzled before object-oriented development got popular).
- OODBMS always seemed incomplete.
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.
Comments
9 Responses to “20th Century DBMS success and failure”
Leave a Reply
[…] 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 […]
[…] 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 […]
[…] 20th Century DBMS industry successes and failures […]
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.
chers,
-dB
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. 🙂
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).
-dB
How about Fortune Systems?
In general, that was the era of the first round of UNIX boxes.
And who supported Prime when?
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).
Hey! Ι juѕt wanted to assk if you eᴠer haѵe any pгoblems ѡith
hackers? Mу ⅼast blogg (wordpress) was hacked andd I endеd
up losing a feew monrhs of hard work dᥙe to no back
up. Do Ò¯ou hve É‘ny methods tÖ… protect É‘gainst hackers?