Computer Associates Sells Ingres DB Tech

Christopher B. Brown writes to tell us Network World is reporting that Computer Associates is selling their Ingres database technology to a private equity firm called Garnett & Helfrich Capital. From the article: "CA released Ingres last year as an open source project, reviving interest in the dormant software. Still, databases have never been a core part of CA's portfolio. CA CEO John Swainson cast the Ingres sale as part of CA's larger effort to streamline the vast collection of applications it amassed through a decade of heavy acquisitions in the 1990s. Ingres came to CA through its 1994 buyout of ASK/Ingres"

Comments

I think it's pretty safe to say...

[Sheetrock]

That these acquisitions of modular lightweight technologies appear to be part of a larger dynamic approach to enterprise-class offerings. I can't imagine it stops with an RDBMS and network clients -- I wonder if there are any underappreciated server hardware platforms that they've got their eyes on.

Why bother?

[HermanAB]

I don't get it. Since PostgreSQl is the successor to Ingres and is properly funded by DARPA - why would anyone bother with the older version? It feels like Linus making a big whoopdedoo about a release of kernel version 1.0 under a BSD license...

Re:Why bother?

[buckhead_buddy]

HermanAB wrote:

Since PostgreSQl is the successor to Ingres and is properly funded by DARPA - why would anyone bother with the older version?

Please note that this company is not specifically a technology company; their focus seems to be on investing. My guess is that they're going after the Intellectual Property and need the ownership of the proprietary code to set up a basis for sales, licensing, or litigation.

Perhaps they have other interests. Though they don't appear to be, they might be the Investor equivalent of Sanford and Son and see the Ingres code as having future value even if it isn't developed further. I don't see the appeal, but someone surely saw something in it. Their strategy may not be clear, but they certainly didn't buy it out of nostalgia.

Re:Why bother?

[Anonymous Coward]

prep themselves to pull a SCO and start trying to charge every company...

CA has already 'been there, done that' and I figure the metaphorical moose has been milked like the one in the 'Ernie'/'Piranha Club' comic strip moose-milking contest storyline of many years ago (if you didn't see the comic, the moose looked horribly emaciated and in shock from the experience. Imagine Bill The Cat as a moose).

CA's early 1990's management ran a policy of buying out software companies and 'maximizing' license renewal revenue from the legacy apps like Ask and Ingres. I was managing a MicroVAX running a 2-user Ingres legacy database around that time and, while I don't remember the exact renewal cost, I do remember nearly fainting from its magnitude, well above 10 times the prior year. We didn't renew and, if memory serves, the app was retired in favor of a small shell script or some such thing.

I wonder if anybody running Ingres during that period is still running it (and paying for support). More likely the Ingres base is now mostly those who picked it up under CA's more conciliatory management team.

Too little too late

[Mensa Babe]

It might have been a good idea in the bad old days but today when we already have a stable, production ready, rock solid, ACID-compliant open-source relational database management system of choice, Ingres will never truly succeed in "reviving interest in the dormant software". It's the same mistake that the record industry has made in the early nineties all over again. They missed the train. Sad but true.

Re:sad attempt...

[Anonymous Coward]

You have no tools available in the Open Source market that compare with Ingres. If you think otherwise you are deluding yourself.

Ingres is an RDBMS used by large organisations and small, and has a very good technical support system behind it with actual people you can talk to - some even local.

Try that with MySQL, Postgres, etc - the only way you can get equivalent support for them is if you live in the same city as the developers. Computer Associates have offices with support people around the world.

Compatibility.

[CyricZ]

Compatibility.

Many large corporations have massive amounts of data stored in system backed by Ingres databases. This is often very important data, and cannot be corrupted.

While a system like PostgreSQL is often more than capable, in a technical sense, it may not offer the 100% compatibility that is needed by serious users. Thus it is often not an option.

Target audience

[jd]

SQLite is good if you want an embeddable SQL engine, but it isn't exactly a heavy-duty workhorse. To serve dynamic content for a single-user website, where Big Iron Databases would look stupid and do nothing extra, this is exactly what you want.

If you want something that'll do a bit more, but retain a lot of the speed and also keep the footprint down, MySQL is probably the best bet. It has a lot of the functionality of the really large databases - perhaps rather more than is good for a lean, mean database machine - but still gives good balance between function and performance.

PostgreSQL is much more powerful than MySQL, but at the cost of being bigger and generally not as nimble. If you're dealing with mid-sized Enterprise-level databases, I frankly wouldn't care about per-transaction performance as much as I'd care about maintaining good performance for respectable databases for a few hundred simultaneous users. MySQL would be hammered long before PostgreSQL for this kind of work. For GIS stuff, where you've some fairly tricky topographical information to manipulate, you'll notice that PostgreSQL has a far bigger following.

This leaves Ingres, which has a reputation for being good for Big Corporate Data Warehousing. Data warehousing is a very different problem from regular relational database handling. The problem-space is typically orders of magnitude greater, the database generally isn't going to be normalized and the mappings are generally altered to be less I/O-bound - which usually means more work for the CPU.

The problem-spaces solved by these databases are all very very different. I would love to see a database that had pluggable components such that different components were optimized for different types of workload and that different functions could be loaded/unloaded as needed, so your footprint was always the lowest for what you were doing, not what the database was capable of.

The fact is, no such database is in wide use - assuming it exists at all.

And we're only talking about the SQL Relational model. The "pure" relational model (as discussed on Slashdot many times) is different again, as are the Object-Relational and the Object-Oriented models. Absolutely none of these could be used with Xanadu's ZigZag data structures (the relationships are essentially permutations and order-independent, whereas formal databases use relationships that are either one-way or follow a specific ordering). They generally don't distribute well, either, as data is bulkier than code, forcing you to load-balance rather than distribute logically.

(That last part can be solved for some cases - it is fairly common to have a mix of tightly-coupled and loosely-coupled data, so it is possible to split the problem-space in a way that keeps communications down and takes advantage of a parallel architecture. It just isn't easy.)

Ingres is important as a database, because PostgreSQL can't (yet) cut it in the Really Big Database World. As good as PostgreSQL is, I would not want to replace extremely large-scale Informix or DB/2 databases with it. Maybe someday, but not today. Ingres - I'd give it a maybe. It does have the reputation of being able to handle it.

The multitude of engines out there are also important, because there are many, many different problem-spaces out there and NONE of them - not one - is good at even a few, let alone many, and certainly not all. And there are many problem-spaces for which there are no databases at all. At least, none worth mentioning.

This is a fixable problem, but not until someone goes out there and fixes it. That isn't happening. So, until then, I'll use RRD, SQLite, MySQL, PostgreSQL, Ingres, Sleepycat DB4, ZopeDB, OpenLDAP, CUPS*, Shadow*, Postfix*, Reiser4*, ...

*These all have databases in them. The password file, the print spooler, all the fancy file-access features of Reiser4... And because they're all working in subtly different ways, you WILL have a database engine for each, until or unless someone produces a system that can do all of these as well as each of the specialized solutions.

Re:sad attempt...

[jadavis]

Do you have any evidence to back up your claims? Are all CA employees supposedly wizards with Ingres that can solve any problem at a moment's notice?

Many companies around the world provide very high quality support for PostgreSQL. To say that support for Ingres is better you're going to need to provide some evidence.