Red Hat Nixes Database Acquisition Strategy

Published: June 6, 2006

by Timothy Prickett Morgan

It wasn't more than five or six seconds after Red Hat announced it was acquiring open source Java middleware and application development tool provider JBoss a few weeks ago that the entire IT industry starting wondering what Red Hat might do next. The most obvious thing for Red Hat to do now would seem to be to go farther up the software stack and deliver its own database. But don't count on Red Hat doing that any time soon.

Or rather, don't count on Red Hat repeating its past. For those of you who have a good memory, you will recall that in September 2002, about six months after Red Hat announced its Advanced Server enterprise edition of the Linux operating system and started going after Unix workloads in a big way, it announced Red Hat Database 2.0, which was based on the open source PostgreSQL 7.2.2 relational database. RHD 2.0 was a commercialized version of this database, including installer software, documentation, and graphical database tools created by Red Hat to make it easier to administer the PostgreSQL database. Red Hat Database 2.0 was supported on Red Hat's Linux 7.3 and Linux Advanced Server 2.1 at announcement, and was based on PostgreSQL rather than the rival MySQL database because PostgreSQL had many features--stored procedures, triggers, and so forth--that databases from Oracle, IBM, Sybase, and Microsoft already had and that MySQL was lacking until MySQL 5 was launched in 2005.

Technically speaking, Red Hat initially backed the right open source database horse when it picked PostgreSQL, but the bet didn't pay off because MySQL has become wickedly popular and has matured. Moreover, companies with closed source databases--even those that run on Linux--have chosen to stick with them because they have deep experience with their databases, which are woven deeply into their applications. Finally, the costs of converting data and stored procedures from one database to another is very high, unlike making the transition from Unix to Linux has been for many customers. Administering a Linux system is very much like administering a Unix system, but there is a world of difference between an Oracle, DB2, or SQL Server database and PostgreSQL or MySQL--as indeed there are big differences between all databases, whether or not they are open source.

At the Red Hat Summit last week in Nashville, the database question was on everyone's mind, and the top brass at Red Hat did their best to dismantle any expectations that the company would acquire an existing provider of support for an open source database or try to create one itself.

Over some drinks in front of the Grand Old Opry as a local band was blaring out some tunes, I pressed Tim Yeaton, senior vice president of enterprise solutions at Red Hat, about the database question. Yeaton, like many of the top techies at Red Hat, hails from the former Digital Equipment, so he knows a thing or two about integrated systems like VMS and its long-time competitors, IBM's OS/400 and Hewlett-Packard's MPE.

The launch of Red Hat Database nearly four years ago used the same kind of thinking that these legendary three minicomputer stacks used: You rolled the operating system, middleware, and databases all into one stack, and you sold it as a complete, integrated set. By getting customers to take the whole system, you exercised a lot of control. But, the exclusivity of the integrated platform also meant that Digital, IBM, and HP were also locked out from supporting a broader set of customers, who might want to use other middleware or databases on VMS, OS/400, or MPE. VMS was clearly more open when it came to databases, but customers generally chose Digital's own RDB database, an Oracle variant, or sometimes Sybase. Suffice it to say, Red Hat is not thinking about creating an integrated, exclusive stack--at least not yet. (I would argue--and I did with Yeaton twice during the summit--that if you had asked Red Hat the same question about middleware and application servers two years ago, the company would have said the same thing: Red Hat was not interested in picking one platform, as it essentially has done when it sought to acquire JBoss.)

Yeaton explained the reality of the situation is that customers had deployed all kinds of databases already, and the real problem was that 85 percent of the data stored by enterprises was in an unstructured form, sitting outside of databases. "Our notion of a stack will never parallel Microsoft's notion, or OS/400 or VMS," explained Yeaton. "It is more important to provide federated access to data in any form, and we feel that this is the most important problem for us to solve. In so doing, you don't have to choose one data source." As for picking JBoss, Yeaton said he believed "that the market had voted," and it would be pretty hard to argue that JBoss has not, in a few short years, come from nowhere to dominant mind and deployment share; IBM, Oracle, and BEA Systems might rake in more revenues with their WebSphere, Application Server, and WebLogic middleware, but as JBoss catches on, this could change. Most people think the middleware layer will, like operating systems, commoditize. That doesn't mean a vendor should not be in that business. It just means they will have to go high volume to make their numbers.

In an interview last week, Matthew Szulik, Red Hat's chairman and chief executive officer, made it pretty clear that Red Hat was not interested in buying or otherwise controlling a database product. "We already have dominant providers in that market, and the space has largely been commoditized already by very established players," Szulik said. "We will look elsewhere for places where we can add value. We have an immense amount of work to do in the infrastructure space."

There are usually at least two ways to look at any issue. The same arguments could have been applied to operating systems and middleware as Red Hat is applying to the database layer. With $14 billion of very profitable database sales every year, there is money to be had in databases. And there might just be another way to pursue this opportunity than perhaps Red Hat is thinking about. One of the big problems in business is the way we store data: in decentralized systems and largely in unstructured form. Imagine if Red Hat were to come up with what I will call a database file system, whereby all information is stored in an object relational database format, whether it is a traditional database or a collection of files.

For those of you who know about IBM's System/38 and AS/400 minicomputers, this idea will be particularly funny, because IBM created such a database file system in these machines many years ago. The only way to store information--whether it was a picture, an ASCII file, or a database record--on these machines was inside a database. In 1995, in order to facilitate ASCII files, IBM gutted OS/400 and made the database a separate structure, as is the case in all other operating systems. Red Hat wants to wrap around, embrace, and interface with all kinds of information, no matter where it is stored. And this is a valid thing to do. But it might also be equally valid--and valuable to customers--to create a database that is compliant with Oracle, DB2, MySQL, and SQL Server formats and that can be used just as easily to store unstructured data used by PCs and other decentralized machines in central, secure repositories.

RELATED STORIES

Oracle's Ellison Ponders Owning a Linux Distro

Red Hat Buys JBoss--Your Move, Novell

Red Hat Debuts Linux 8.0, Database 2.0