Most database startups avoid building relational databases since that market is dominated by a few goliaths. Oracle, MySQL, and Microsoft SQL Server have embedded themselves into the technical fabric of large- and medium-sized companies going back decades. These established companies have a lot of market share and a lot of money to quash the competition.
So rather than trying to compete in the relational database market, over the past decade, many database startups focused on alternative architectures such as document-centric databases (like MongoDB), key-value stores (like Redis), and graph databases (like Neo4J). But Cockroach Labs went against conventional wisdom with CockroachDB: It intentionally competed in the relational database market with its relational database product.
While it did face an uphill battle to penetrate the market, Cockroach Labs saw a surprising benefit: It didn’t have to invent a call. All it needed to do was grab a share of a market that also happened to be proliferating.
In previous parts of this EC-1, I looked at the origins of CockroachDB, presented an in-depth technical description of its product, and analyzed the company’s developer relations and cloud service, CockroachCloud. In this final installment, we’ll look at the company’s future, the competitive landscape within the relational database market, its ability to retain talent as it looks toward a potential IPO or acquisition, and the risks it faces.
CockroachDB’s success is not guaranteed. It has to overcome significant hurdles to secure a good place among a set of well-established database technologies owned by companies with bottomless pockets.
It’s not impossible, though. We’ll first look at MongoDB as an example of how a company can break through the barriers for database startups competing with incumbents.
When life gives you Mongos, make MongoDB.
MongoDB is an excellent example of the risks that come with trying to invent a new database market. The company started out as a purely document-centric database when that approach was the exception rather than the rule.
Web developers like document-centric databases because they address several everyday use cases in their work. For example, a document-centric database works well for storing comments to a blog post or a customer’s entire order history and profile.