Should Red Hat Buy or Build a Database?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

For a decade, at least, observers of the company have speculated about whether Red Hat would or should enter the database market. The primary argument, one made in this space eight years ago, has historically been that Red Hat is de facto leaving potential dollars on the table by limiting itself to operating platform and immediately adjacent markets. In a more recent piece, analyst Krishnan Subramanian adds that Red Hat is at risk because databases represent a control point, one that the company is effectively ceding to competitors such as AWS or Microsoft.

Even if we assume for the sake of argument that both of the arguments in favor are structurally sound, however, the case against Red Hat investing in database markets seems clear. Here are five issues that would discourage such a move.

  1. The Window Has Closed: Arguably there was a window of time in which the acquisition of a database by Red Hat would have made sense. If, instead of Sun, Red Hat had acquired MySQL in 2008, it would have cemented its control of the highest growth relational database on the market at that time. The acquisition also would have predated PostgreSQL’s latter day resurgence, and more importantly the Cambrian explosion of non-relational database technologies. It undoubtedly would have impacted the company’s relationships with key partners, most notably Oracle, and the appetite for commercial open source databases was not then what it is today, but Red Hat would have had the opportunity to go to market with a pure open source stack, one which included a database. Today, however, this window is closed. As the database market has seen more market entrants, the relative opportunities for each have commensurately declined. A database market with three players is more potentially commercially lucrative than a market with thirty players. MySQL is not just one of a large number of database options, it represents but one style of database. Which brings us to the second problem.

  2. Narrowing the Funnel: Unlike customers a decade or more in the past, who more or less always chose a relational database and typically only picked between two or three commercial products, customers today are likely to employ not just a single database but multiple styles in service of a single workload. Relational databases remain a trusted workhorse, but they’re frequently complemented by in-memory, columnar, document and other types of datastores. This means that by definition a Red Hat that embraced a database market would be embracing only a narrow subset of that market; it might capture some of the relational market, but it would (absent multiple investments) not have access to other adjacent, growing markets. It also would mean that Red Hat’s stringently neutral go to market would be potentially compromised. The company finessed this well in the middleware market, to be fair, following the acquisition of JBoss, but there’s no guarantee this success would be replicated with the more distantly related database market. There is also the question of whether Red Hat would have the ability to access the fastest growing segment of the database market, which brings us to the next issue.

  3. The Cloud Providers: There has been a great deal of change in database markets in recent years, but one of the clearest shifts has been in the manner in which databases are acquired and consumed. For most of the market’s lifespan, of course, databases were obtained in the manner of all enterprise software: installed, run and managed on customers’ premises. Today, the real growth from this category is coming from so-called Database-as-a-Service (DBaaS) providers, whether those are wide catalog hyperscale cloud providers such as AWS, Google or Microsoft or on premise vendors with a cloud based offering such as MongoDB with Atlas. Encouraging Red Hat to invest in this category implies two things, then: first, that they would be comfortable substantially ramping up a cloud based business and second that they could successfully compete with both single purpose database cloud platforms and hyperscale cloud providers. Red Hat has stated on multiple occasions, and its behavior has validated this, that it has no intention of becoming a major cloud provider. Even if you assume, then, that Red Hat could outengineer the likes of the hyperscale providers on a database basis, it seems improbable that they would choose to enter a market where the majority of growth is coming from services, not traditional software.

  4. The Company DNA: If you believe that a company’s DNA matters and impacts its ability to execute, it is necessary to question whether Red Hat could be successful, at least in the short to medium term, operating a business so materially different from its traditional platform businesses. Red Hat has spent its entire existence refining its ability to sell a particular type of software to a particular type of customer. This buyer, importantly, is not always or even frequently the same one who purchases database services. Which means that Red Hat would have to rapidly build out its ability to introduce new messaging to buyers they may or may not have access to at present. At the same time, Red Hat would have to be careful not to compromise its existing platform with businesses who chose against whatever hypothetical database Red Hat would offer. If it offered PostgreSQL services, for example, your messaging for MySQL customers gets more complicated. That’s a very fine line to walk.

  5. The Cost Versus the Benefit: Like all businesses, Red Hat would (and presumably has) evaluated its options within the database space according to some basic math in terms of the projected costs weighed against the potential benefits. Unless Red Hat was able to tap the high growth DBaaS markets that hyperscale providers currently have uniquely differentiated access to (see, for example, the size of the AWS Neptune beta pool), the potential upside to any database market entry would be limited. Compare this against the cost of an acquisition – MongoDB, as one common suggestion, is currently valued at more than double what MySQL sold for – and the risks described above that would accompany such a move, and it seems difficult to make the case for a database market entry by Red Hat. It would inarguably offer additional revenue opportunities, and potentially give the company greater control of its accounts. But all of that would come at a high cost in dollars and risk, one that it seems unlikely the company would deem worth paying.

Disclosure: AWS, Google, Microsoft, MongoDB, Oracle and Red Hat are RedMonk customers.

One comment

  1. […] response to my post on Red Hat’s blind spot on databases, Redmonk Analyst Steve O’ Grady posted explaining why Red Hat couldn’t (or shouldn’t) enter the database market. He posed a set of 5 […]

Leave a Reply

Your email address will not be published. Required fields are marked *