Follow Datanami:
June 30, 2020

Can Yugabyte Modernize the Database Layer? Bill Cook Thinks So

(WHYFRAME/Shutterstock)

It’s a conundrum that many database startups have yet to solve: Why does Oracle continue to dominate the space if its relational database is so out of step with the times? The software vendor that cracks the code will be extremely wealthy. The distributed SQL database company Yugabyte will take its best shot under former Pivotal co-founder and president Bill Cook, who recently joined the company.

At Pivotal, Cook and his colleagues helped usher in a new way of approaching application development. “[We were] helping the community and large-scale clients move to this new cloud-native world” by “showing people how to build applications in a new CI/CD, cloud-native microservices way,” Cook explained recently to Datanami.

As an EMC/VMware spinout, Pivotal was quite successful in redefining the creation of the application layer of the modern cloud stack, and Cook stayed with the company until he ferried it through its IPO and subsequent re-acquisition by VMware in 2019. At that point, with 35 years in the IT saddle, Cook could have hung up his spurs. But something was bugging him.

“I really thought the data side of that story has been underserved, meaning these applications are being moved, people [are] embracing all these technologies and new ways of building software to drive business results, but the data tier was still a bit problematic,” Cook says.

What the market demands, Cook says, is a geographically distributed SQL database that’s rock-solid, feels familiar to developers, and doesn’t lock them in. In short, it borrows the positive attributes of the eponymous Oracle database, but without the vendor lock-in, lack of horizontal scalability, and DevOps complexity.

Yugabyte CEO Bill Cook joined the company in May 2020

As Cook got to know the founders of Yugabyte–Kannan Muthukkaruppan, Karthik Ranganathan, and Mikhail Bautin–he came to the conclusion that YugabyteDB was the right database to tackle the challenges posed by the modern cloud platform.

According to Muthukkaruppan, there were three main design points that he and his fellow founders strived to meet as they were developing Yugabyte. The first design point was developer familiarity.

“The relational database paradigm, with SQL as the language, is something developers are really comfortable with,” Muthukkaruppan says. “We took that to heart. YugabyteDB…is a distributed SQL database, but it’s completely PostgreSQL compatible. The compatibility is not only at the language level, but the ecosystem and the driver level.”

Secondly, modern cloud companies run in a geographically dispersed manner, and they expect their databases to, too. “MySQL, PostgreSQL, Oracle–they’re pretty much largely designed for a shared disk, or a single-node architecture. That’s their sweet spot,” Muthukkaruppan continues. “But you need to run this as a distributed database across nodes that’s spanning zones or regions.”

Muthukkaruppan and his colleagues drew inspiration from the Google Spanner paper to form Yugabyte into an ACID-compatible, globally distributed database, developed on a C++ code base. “That sort of forms the underpinning of Yugabyte’s database architecture,” he says.

Lastly, modern companies want their technologies and tools to be open, and they want to freedom to change where they run, and not be subject to lock-in. Yugabyte has embraced this philosophy with its software.

Databases must be architected from the ground up to be distributed (BeeBright/Shutterstock)

“It’s about helping enterprises move to the cloud without lock-in, being able to run this exactly the same on their favorite cloud infrastructure, whether it’s private cloud or public cloud, and really taking a commitment to the database being 100% open source with an Apache license,” Muthukkaruppan says.

Google obviously checks some of the boxes with Spanner, including the big one: Being able to run a globally distributed database without losing data or adding so much network latency that the applications become unusable. But Spanner fails to check others. For example, Spanner is not available outside of the Google Cloud, which subjects users to lock-in. And while Spanner complies with some aspect of the ANSI standard, users have to use special drivers to connect it to their applications, Muthukkaruppan says.

Certainly, the folks at Yugabyte are not the only folks in the IT industry who have hit upon some of these truths about data and database. There are other NewSQL database vendors looking to sell next-gen transactional database systems to the industrial masses. CockroachLabs and FaunaDB could be considered direct competitors in the transactional space, while a host of other NewSQL vendors like MemSQL and VoltDB are targeting more “translytical” workloads. And when it comes to distributed scalability and developer productivity, NoSQL databases like Apache Cassandra and MongoDB certainly have something to add to the equation, respectively.

With all of these modern requirements swirling about, it’s amazing that the situation on the ground hasn’t really all that much over the years. Oracle remains atop the database heap, with a significant chunk of the market, which Gartner estimates is worth around $50 billion per year.

Cook acknowledges that Oracle has built a great company with great products. But he argues that Oracle has failed to keep up with the market demands, which has resulted in few new applications being deployed atop Oracle databases. It might be a slow process, but customers are voting with their checkbooks as they prepare for the future, he says.

“It’s not that [Oracle database] isn’t cutting it any longer. It’s that, if you look at where the future is headed in a multi-cloud, scale-out and [need] to be more cost effective, they’re looking for alternatives,” Cook says of Oracle customers. “They’re not architected the way we are from the ground up.”

Cook points out that Yugabyte co-founder Muthukkaruppan spent over a decade at Oracle, so he’s familiar with the amount of time and hard work required to build a rock-solid commercial database that companies will bet their businesses on. (Both Muthukkaruppan and Ranganathan also spent time on the technical teams at Nutanix and Facebook, where they joined Bautin, so you can surmise that they know their stuff).

Out of about 350 databases that are tracked on DB-Engines.com, Oracle has been number one for over a decade. Yugabyte, which has been at this for about six years, is ranked number 166, up more than 40 spots in the last year. When you add in the modern requirements – namely, the need to run a database in a globally distributed manner–the list of contenders quickly narrows, Muthukkaruppan says.

“People are saying, hey for my transactional workloads, that’s no longer something I can continue to do manual sharding on and put so much operational burden to run and manage these systems. I want my database itself to handle these,” he says. “It will be very hard for Oracle or MySQL to do it as a Band-Aid on top.”

Yugabyte co-founder and president Kannan Muthukkaruppan helped scale databases at Facebook starting in 2007

Yugabyte is just four years old, and it can’t match older, more mature databases in every respect. Even so, it has attracted some blue-chip customers, such as Kroger and Narvar, which powers the backend post-purchase experiences for retailers like Macy’s and Home Depot.

The addition of Cook instantly gives Yugabyte greater credibility, as well as a deep rolodex of prospects to draw from. “When we tell our story and talk about the problem we’re solving for, every one of them is asking to do a deeper dive and go to the next step,” Cook says. “And typically the reason for that [is] either they have this NoSQL need of scale out with Casssandra and they’re looking for the cloud-native patterns and the density we can drive on the availability, or they have this transactional SQL world running in Postgres single-node mode, or they have a transactional database like Oracle that, from their perspective, is too expensive and proprietary and doesn’t meet the requirement.”

Databases and data stores are proliferating like weeds these days, thanks in part to the great tools and patterns that Pivotal and others have brought to the developer world. But that still doesn’t change the fact that Fortune 500 companies do not often migrate databases, particularly for the core transactional systems that drive the bulk of their businesses.

Over time, as part of larger modernization projects for legacy IT systems, they will get to those databases, and it’s Cook plan to be there, waiting patiently, ready to make a pitch about the database that he thinks will modernize the data layer.

“We’re going to do this a step at a time,” Cook says. “You have to earn trust. You have to earn respect in the organization. You have to have proof points. We will do that with each of the organizations were working with. You have to do that. It’s a journey. It’s not going to happen over night. We’re committed to that longer-term journey.”

Related Items:

Big Data Career Notes: June 2020 Edition

Database, Data Management Upgrades Keep Coming

Datanami