CockroachDB, the database that just won’t die

There is an art to engineering, and sometimes engineering can transform art. For Spencer Kimball and Peter Mattis, those two worlds collided when they created the widely successful open-source graphics program, GIMP, as college students at Berkeley.

That project was so successful that when the two joined Google in 2002, Sergey Brin and Larry Page personally stopped by to tell the new hires how much they liked it and explained how they used the program to create the first Google logo.

Cockroach Labs was started by developers and stays true to its roots to this day.

In terms of good fortune in the corporate hierarchy, when you get this type of recognition in a company such as Google, there’s only one way you can go — up. They went from rising stars to stars at Google, becoming the go-to guys on the Infrastructure Team. They could easily have looked forward to a lifetime of lucrative employment.

But Kimball, Mattis and another Google employee, Ben Darnell, wanted more — a company of their own. To realize their ambitions, they created Cockroach Labs, the business entity behind their ambitious open-source database CockroachDB. Can some of the smartest former engineers in Google’s arsenal upend the world of databases in a market spotted with the gravesites of storage dreams past? That’s what we are here to find out.

Berkeley software distribution

Mattis and Kimball were roommates at Berkeley majoring in computer science in the early-to-mid-1990s. In addition to their usual studies, they also became involved with the eXperimental Computing Facility (XCF), an organization of undergraduates who have a keen, almost obsessive interest in CS.

How engineers fought the CAP theorem in the global war on latency

CockroachDB was intended to be a global database from the beginning. The founders of Cockroach Labs wanted to ensure that data written in one location would be viewable immediately in another location 10,000 miles away. The use case was simple, but the work needed to make it happen was herculean.

The company is betting the farm that it can solve one of the largest challenges for web-scale applications. The approach it’s taking is clever, but it’s a bit complicated, particularly for the non-technical reader. Given its history and engineering talent, the company is in the process of pulling it off and making a big impact on the database market, making it a technology well worth understanding. In short, there’s value in digging into the details.

Using CockroachDB’s multiregion feature to segment data according to geographic proximity fulfills Cockroach Labs’ primary directive: To get data as close to the user as possible.

In part 1 of this EC-1, I provided a general overview and a look at the origins of Cockroach Labs. In this installment, I’m going to cover the technical details of the technology with an eye to the non-technical reader. I’m going to describe the CockroachDB technology through three questions:

  1. What makes reading and writing data over a global geography so hard?
  2. How does CockroachDB address the problem?
  3. What does it all mean for those using CockroachDB?

What makes reading and writing data over a global geography so hard?

Spencer Kimball, CEO and co-founder of Cockroach Labs, describes the situation this way:

There’s lots of other stuff you need to consider when building global applications, particularly around data management. Take, for example, the question and answer website Quora. Let’s say you live in Australia. You have an account and you store the particulars of your Quora user identity on a database partition in Australia.

But when you post a question, you actually don’t want that data to just be posted in Australia. You want that data to be posted everywhere so that all the answers to all the questions are the same for everybody, anywhere. You don’t want to have a situation where you answer a question in Sydney and then you can see it in Hong Kong, but you can’t see it in the EU. When that’s the case, you end up getting different answers depending where you are. That’s a huge problem.

Reading and writing data over a global geography is challenging for pretty much the same reason that it’s faster to get a pizza delivered from across the street than from across the city. The essential constraints of time and space apply. Whether it’s digital data or a pepperoni pizza, the further away you are from the source, the longer stuff takes to get to you.

“Developers, as you know, do not like to pay for things”

In the previous part of this EC-1, we looked at the technical details of CockroachDB and how it provides accurate data instantaneously anywhere on the planet. In this installment, we’re going to take a look at the product side of Cockroach, with a particular focus on developer relations.

As a business, Cockroach Labs has many things going for it. The company’s approach to distributed database technology is novel. And, as more companies operate on a global level, CockroachDB has the potential to gain some significant market share internationally. The company is seven years into a typical 10-year maturity model for databases, has raised $355 million, and holds a $2 billion market value. It’s considered a double unicorn. Few database companies can say this.

The company is now aggressively expanding into the database-as-a-service space, offering its own technology in a fully managed package, expanding the spectrum of clients who can take immediate advantage of its products.

But its growth depends upon securing the love of developers while also making its product easier to use for new customers. To that end, I’m going to analyze the company’s pivot to the cloud as well as its extensive outreach to developers as it works to set itself up for long-term, sustainable success.

Cockroach Labs looks to the cloud

These days, just about any company of consequence provides services via the internet, and a growing number of these services are powered by products and services from native cloud providers. Gartner forecasted in 2019 that cloud services are growing at an annual rate of 17.5%, and there’s no sign that the growth has abated at all.

Its founders’ history with Google back in the mid-2000s has meant that Cockroach Labs has always been aware of the impact of cloud services on the commercial web. Unsurprisingly, CockroachDB could run cloud native right from its first release, given that its architecture presupposes the cloud in its operation — as we saw in part 2 of this EC-1.

Scaling CockroachDB in the red ocean of relational databases

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-size 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 market. All it needed to do was grab a share of a market that also happened to be growing rapidly.

Cockroach Labs has a bright future, compelling technology, a lot of money in the bank and has an experienced, technically astute executive team.

In previous parts of this EC-1, I looked at the origins of CockroachDB, presented an in-depth technical description of its product as well as an analysis of the company’s developer relations and cloud service, CockroachCloud. In this final installment, we’ll look at the future of the company, 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 profitable place for itself among a set of well-established database technologies that are owned by companies with very deep 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

Dev Ittycheria, MongoDB CEO, rings the Nasdaq Stock Market Opening Bell. Image Credits: Nasdaq, Inc

MongoDB is a good example of the risks that come with trying to invent a new database market. The company started out as a purely document-centric database at a time when that approach was the exception rather than the rule.

Web developers like document-centric databases because they address a number of common 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.

Build a digital ops toolbox to streamline business processes with hyperautomation

Reliance on a single technology as a lifeline is a futile battle now. When simple automation no longer does the trick, delivering end-to-end automation needs a combination of complementary technologies that can give a facelift to business processes: the digital operations toolbox.

According to a McKinsey survey, enterprises that have likely been successful with digital transformation efforts adopted sophisticated technologies such as artificial intelligence, Internet of Things or machine learning. Enterprises can achieve hyperautomation with the digital ops toolbox, the hub for your digital operations.

The hyperautomation market is burgeoning: Analysts predict that by 2025, it will reach around $860 billion.

The toolbox is a synchronous medley of intelligent business process management (iBPM), robotic process automation (RPA), process mining, low code, artificial intelligence (AI), machine learning (ML) and a rules engine. The technologies can be optimally combined to achieve the organization’s key performance indicator (KPI) through hyperautomation.

The hyperautomation market is burgeoning: Analysts predict that by 2025, it will reach around $860 billion. Let’s see why.

The purpose of a digital ops toolbox

The toolbox, the treasure chest of technologies it is, helps with three crucial aspects: process automation, orchestration and intelligence.

Process automation: A hyperautomation mindset introduces the world of “automating anything that can be,” whether that’s a process or a task. If something can be handled by bots or other technologies, it should be.

Orchestration: Hyperautomation, per se, adds an orchestration layer to simple automation. Technologies like intelligent business process management orchestrate the entire process.

Intelligence: Machines can automate repetitive tasks, but they lack the decision-making capabilities of humans. And, to achieve a perfect harmony where machines are made to “think and act,” or attain cognitive skills, we need AI. Combining AI, ML and natural language processing algorithms with analytics propels simple automation to become more cognitive. Instead of just following if-then rules, the technologies help gather insights from the data. The decision-making capabilities enable bots to make decisions.

 

Simple automation versus hyperautomation

Here’s a story of evolving from simple automation to hyperautomation with an example: an order-to-cash process.

Q3 IPO cycle starts strong with Couchbase pricing and Kaltura relisting

Today we have new filings from Couchbase and Kaltura: Couchbase set an initial price range for its IPO, something we’ve been waiting for, and Kaltura’s offering is back from hiatus with a new price range and some fresh financial information to boot.

Both bits of news should help us get a handle on how the Q3 2021 IPO cycle is shaping up at the start.

TechCrunch has long expected the third quarter’s IPO haul to prove strong; investors said as 2020 closed that quarters one, three and four would prove very active in terms of public market exits this year. Then the second quarter surpassed expectations, with more companies going public than at least some market observers anticipated.

With that in mind, you can imagine why the newly launched Q3 could prove an active period.

So! Let’s start with a dig into the filing from NoSQL provider Couchbase, working to understand its first price range and what the numbers may say about market demand for technology debuts. Here’s our first look at the company’s value. Then we are taking the Kaltura saga back up, checking into the pricing and second-quarter results from the technology company that provides video streaming software and services.

Frankly, I’ve been waiting for these filings to drop. So, let’s cut the chat and get into the numbers:

Couchbase’s IPO price range

In its new S-1/A filing, Couchbase reports that it anticipates a $20 to $23 per share IPO price. With a maximum sale of just over 8 million shares, Couchbase could raise as much as $185.15 million in its public offering.

The company will have 40,072,801 shares outstanding after its IPO, not including 1,050,000 shares that are reserved for possible release. The math from here is simple. To calculate Couchbase’s possible simple IPO valuation we can just do a little multiplication:

  • Couchbase simple valuation at $20 per share: ~$802 million
  • Couchbase simple valuation at $23 per share: ~$922 million

If you want to include the company’s reserved shares, add $21 million to the first figure, and $24.2 million to the second. Notably, TechCrunch wrote before it priced that using a historical analog from the Red Hat-IBM sale — both Couchbase and Red Hat work in the OSS space — the company would be worth around $900 million. So, we were pretty close.

3 data strategies for selling to developers

Yes, developers are a tough crowd. They hate being sold to, and it’s pretty easy for traditional marketing campaigns to fall flat with them because they’d much rather get a recommendation from a colleague. Failed campaign after failed campaign has led many software company executives to throw up their hands and declare all sales and marketing to be pointless.

And that’s just wrong. Selling to developers isn’t impossible — it’s just difficult. I cover why it’s difficult and offer examples of exceptional developer-focused marketing in my new playbook. Part of selling to developers involves balancing two things: building out a strong organic marketing function and targeting your audience with the right message at the right time throughout their buyer journey.

Selling to developers isn’t impossible — it’s just difficult.

Easier said than done, right?

Yep. I see it all the time. Part of what’s blocking marketers from widening the top of the funnel (driving more developers to sign up for their free tools) for their developer-focused businesses is ensuring they have the right data and measurement capabilities in place to understand how much impact their activities have on the business.

That’s mostly because these marketers, community managers and developer relations experts have the most luck with organic marketing. In this industry, organic marketing is one of the most challenging to measure.

Organic marketing means investing in channels like referrals, organic search, organic social (community) and direct traffic to your website (brand). New users from paid marketing, banner ads, events or sales reps (the most measurable channels) don’t count as organic. We measure the fruits of these efforts with a new metric called Natural Rate of Growth.

In a digital, multi-touch-point world, it’s getting more challenging to measure which users hear about your brand from which channels. That’s why tools like Orbit, Tribe and Mighty have gained traction so quickly.

That’s all good, and it’ll be a huge boon for community managers in time, but these tools still don’t solve some of the core data strategy issues I see developer-focused software companies fighting. These quick tips should help your team align around what needs to be done and what’s just a “nice to have” so that selling to developers feels less like a battle.

 

  1. Treat data like a product where a core end user is the go-to-market side of the team.
  2. Map your customer’s journey from discovery to expansion and track it religiously.
  3. Don’t overthink it.

Treat data like a product

3 issues to resolve before switching to a subscription business model

In my role at CloudBlue, Fortune 500 companies often approach me for help with solving technology challenges while shifting to a subscription business model, only to realize that they have not taken crucial organizational steps necessary to ensure a successful transition.

Subscriptions scale better, enhance customer experience and hold the promise of recurring and more predictable revenue streams — a pretty enticing prospect for any business. This business model is predominant in software as a service (SaaS), but it is hard to find an industry that doesn’t have a successful subscription story. A growing number of companies in sectors ranging from automotive, airlines, gaming and health to wellness, education, professional development and home maintenance have been introducing subscription services in recent years.

Legacy companies accustomed to pay-as-you-go models may assume shifting to a subscription model is just a sales issue. They are wrong.

However, businesses should be aware that the subscription model is much more than simply putting a monthly or annual price tag on their offering. Executives cannot just layer a subscription model on top of an existing business. They need to change the entire operation process, onboard all stakeholders, recalibrate their strategy and create a subscription culture.

While 70% of business leaders believe subscriptions will be key to their future, only 55% of companies believe they’re ready for the transition. Before talking technology, which is an enabler, companies should first address the following core issues to holistically plan and switch to a recurring revenue model.

Get internal stakeholders involved

Legacy companies accustomed to pay-as-you-go models may assume shifting to a subscription model is just a sales issue. They are wrong. Such a migration will affect nearly all departments across an organization, from product development and manufacturing to finance, sales, marketing and customer service. Leaders must therefore get all stakeholders motivated for the change and empower them to actively prepare for the transformation. The better you prepare, the smoother the transition.

But as we know, people naturally do not like change, even if it is for their own good. So it can be a formidable task to secure the cooperation of all internal stakeholders, which, depending on the size of your company, could number in the thousands.

How much to pay yourself as a SaaS founder

“If you’re the founder of a seed-stage [company and] you’re worried about your electricity staying on this month, then your salary is too low. If you’re saving $10,000/mo, then your salary is probably higher than necessary,” investor Leo Polovets wrote in a Twitter thread.

Ultimately, a good test is to ask how you’ll feel if your startup fails: Will you wonder if your salary contributed to its fall? Or will you regret sacrificing more than you can recover?

This tweet is just one of many in a now burgeoning conversation about how founder pay needs to change. The startup and investor communities are beginning to realize that many founders can’t go without pay for months.

Founders of SaaS startups are at an advantage in this scenario as the sector now has many companies generating revenue almost from day one, sometimes without needing to raise any funding at all.

However, the success still doesn’t tell founders how much to pay themselves, or what others are doing. To help with this, we’ve gathered insights from founders and VCs and narrowed down the most important factors and benchmarks to guide your decision.

A framework for compensation

Founder compensation is often referred to as a “founder salary,” but anchoring the conversation around the salary framework can create the wrong expectation. For example, you could try to establish a correlation between what you plan to pay yourself and your past or current value on the job market. Instead, the data we gathered indicates that founders typically take a pay cut from their previous salaries.

Chris Sosnowski is an interesting example: Before he “took the plunge” at the beginning of 2020 to work full time on his water data management startup Waterly, he used to earn “well over” $100,000. But he says his previous salary wasn’t a key factor when he set his compensation. “I decided to pay myself based on what I thought it would take to keep the company running,” he wrote to TechCrunch.

That brings to mind deferred compensation, which will be familiar to anyone who owns equity. Having put his own money into the company and owning the majority of it, Sosnowski is set to be compensated for his efforts if all goes well. “For the record, I do hope to pay myself back [a] salary for the year or so [it is] reduced like this,” he said.

What does Red Hat’s sale to IBM tell us about Couchbase’s valuation?

The IPO rush of 2021 continued this week with a fresh filing from NoSQL provider Couchbase. The company raised hundreds of millions while private, making its impending debut an important moment for a number of private investors, including venture capitalists.

According to PitchBook data, Couchbase was last valued at a post-money valuation of $580 million when it raised $105 million in May 2020. The company — despite its expansive fundraising history — is not a unicorn heading into its debut to the best of our knowledge.

We’d like to uncover whether it will be one when it prices and starts to trade, so we dug into Couchbase’s business model and its financial performance, hoping to better understand the company and its market comps.

The Couchbase S-1

The Couchbase S-1 filing details a company that sells database tech. More specifically, Couchbase offers customers database technology that includes what NoSQL can offer (“schema flexibility,” in the company’s phrasing), as well as the ability to ask questions of their data with SQL queries.

Couchbase’s software can be deployed on clouds, including public clouds, in hybrid environments, and even on-prem setups. The company sells to large companies, attracting 541 customers by the end of its fiscal 2021 that generated $107.8 million in annual recurring revenue, or ARR, by the close of last year.

Couchbase breaks its revenue into two main buckets. The first, subscription, includes software license income and what the company calls “support and other” revenues, which it defines as “post-contract support,” or PCS, which is a package of offerings, including “support, bug fixes and the right to receive unspecified software updates and upgrades” for the length of the contract.

The company’s second revenue bucket is services, which is self-explanatory and lower-margin than its subscription products.