While working with traditional SQL databases one inevitably runs into issues while scaling as these database were not conceived to run in cloud environments and the underpinning architecture was often devised 30 years ago. NoSQL solutions emerged to take advantage of horizontal scalability but required compromises like consistency. Recognizing these pain points and the reality that everything is moving to the cloud, Cockroach Labs built CockroachDB, the cloud-native open source SQL database. The company founded by a team of ex-Googlers allows scaling of database applications without compromise. The company, which works with a number of Fortune 500 companies, itself has been scaling fast, securing its latest round funding.
AlleyWatch spoke with founder Spencer Kimball about the company and their latest round of funding from a number of top tier investors.
Who were your investors and how much did you raise?
We just raised $27 million in Series B led by Redpoint Ventures, with participation from existing investors Benchmark, FirstMark, GV, and Index. Redpoint’s Satish Dharmaraj will also be joining the board, and we’re thrilled to add his expertise to the team. The funding will be used to help us continue to grow our team, invest in product, and support our customer base.
Tell us about your product or service.
CockroachDB is a cloud-native SQL database for building global, scalable cloud services that survive disasters. But what does “cloud-native” actually mean? The term implies horizontal scalability, no single points of failure, survivability, automatable operations, and no platform-specific encumbrances. It all comes down to simplicity of deployment; you can install a single instance of CockroachDB on your laptop when your app is still small, and then scale to hundreds or thousands of servers as your business grows.
What inspired you to start the company?
In the early 2000s when our founding team was working at Google, we faced a database headache all too common in the industry: application-level sharding. The challenge was, succinctly: more shards, more problems, which created customer downtime, overloaded servers, and mounting complexity.
Problems with scale gave rise to NoSQL architectures, which focused on horizontal scalability at the expense of consistency and familiar API. The simplifications inherent in NoSQL solutions lead to increasingly complex application logic to workaround missing database functionality, like transactions.
We left Google in 2012 to create a private photo-sharing platform called Viewfinder, which was later acquired by Square. Both post-Google companies faced more of the same database issues, which Google was busy tackling. We eventually were inspired to start Cockroach Labs out of both frustration with existing database inadequacies, and because of a dawning realization that the right solution could become industry standard within 5 to 10 years.
The broader problem we’re solving is the continuation of what’s been an arms race between what businesses need and what they’ve been provided. Databases have long been stuck in a cyclical struggle to become faster, bigger, and more reliable.
Traditional SQL databases, like Oracle, are difficult and expensive to scale, as they aren’t architected for running in private and public cloud environments.
Proprietary Database as a Service solutions provided by Amazon and Google are built using closed technology and introduce significant vendor lock-in. Their cost models are very expensive at scale, and offer no off-ramp for migration.
CockroachDB is open source with a dead-simple deployment model. Our 1.0 offering provides the following:
- Scalable SQL to accommodate small and large use cases alike, and scale seamlessly between them.
- Multi-active availability for always-consistent high availability.
- Flexible deployment for automatable operations in virtually any environment.
What market are you targeting and how big is it?
Our early goal was to provide the best possible open source platform for developers. Coupled with a strong enterprise offering, we are well positioned to compete in the $34B database market.
We’ve seen 100K downloads thus far, which is significant given the investment of time and energy required to evaluate new database technology. We’re also excited by the work some of our customers are doing with Cockroach, including Baidu, one of the top ten largest global internet companies.
What’s your business model?
We’re embracing the open core business model, similar to the approach taken by Elastic & Confluent. In addition to the 1.0 release of the fully open source CockroachDB Core product, we’re excited to announce CockroachDB Enterprise. The Enterprise product will launch featuring a distributed, incremental backup / restore capability, as well as enterprise-grade customer support. Over time, we expect the Enterprise product to grow to include a constellation of features primarily geared towards solving problems larger companies experience at scale. Our next Enterprise feature, geo-partitioning, helps companies build truly global data architectures; we expect that to be available in beta form later in 2017.
To give you an idea of the size of the opportunity facing us: every week we’re having conversations with another Fortune 500 company that’s seeing a light at the end of the tunnel, in terms of finally being able to shift their business off Oracle within the next five years to cloud-native technologies. Oracle used to be the only solution for mission-critical “tier 1” apps, but their solutions were architected for environments common 20-30 years ago. They’re not horizontally scalable and when configured for high availability, offer only eventually-consistent replication.
Would you tell us about how the team’s experience at Google has impacted the trajectory of your growth?
Our experience at Google was instructive. Early on, we saw the pitfalls of manually scaling traditional SQL databases. We then built distributed infrastructure and observed Google’s various efforts to re-architect databases to meet challenges around scale and reliability.
When we left Google to start Viewfinder, we were surprised and disappointed by the capabilities of open source databases. We were appalled at the cost projections of scale while using AWS’ DynamoDB. At Square, a host of new problems and various inadequate solutions finally prompted the idea of finally breaking off to get serious about building a solution.
What was the funding process like?
We weren’t expecting to raise a Series B round this early. We’re still well-capitalized from our Series A1 raise. However, we had significant interest from existing investors and investors who we weren’t able to accommodate in our Series A1. However, a favorable valuation, and the flexibility afforded by additional capital made this an opportunistic round.
That said, having Satish and Redpoint as investors was a big draw and we are excited to work closely with them going forward.
What are the milestones you plan to achieve in the next six months?
Expect to see announcements of more marquee customers making it into production. We’re looking forward to publishing case studies of successful CockroachDB deployments and how we’re helping to solve formerly unsolvable problems.
We intend to continue growing the team with top talent from senior engineers specialized in distributed systems, product designers, and more.
Where do you see the company going now over the near term?
In the business model section, I introduced geo-partitioning as an upcoming feature in our Enterprise product. This feature represents the first of many meant to tackle the challenge of how to build scalable, global services. Companies that serve customers across continents currently have only two solutions, both problematic:
- Put everything into one datacenter, for example on the East Coast of the US. This ultimately leads to problems with high latencies and data sovereignty compliance problems for non-US customers.
- Stand up a separate database, for each region in which customers reside. This adds complexity to the data architecture, affecting both application developers and devops personnel. Worse, it undermines the concept of a global data architecture. Customers routinely relocate, which requires an “extract, transfer, load” process for transferring their data; worse, use cases which involve transfers of information between customers in different regions (e.g. funds transfers, message passing, posting, etc.) must be done without the benefit and safety of database guarantees.
Geo-partitioning presents a single, logical database to application developers and database operators alike. It keeps the data next to customers, laying the foundation for data sovereignty compliance and keeping critical latencies low. This will be the first time this feature has been offered by a relational database. We already have significant customer interest around this feature, including one public company in the EU making product plans around its availability. It’s an answer to a problem they previously thought unsolvable.
What’s your favorite restaurant in the city?
That easy: L’Artusi.