Yugabyte’s Mission to Make Postgres Even Better

Yugabyte sells a Database-as-a-Service version of PostgreSQL that supercharges the open source database with a range of modern, cloud-style features, and they just got better.

This is no small feat, as the now 27-year-old database software has been steadily improving, and is now the fourth most popular (according to DB-engines.com), and the second most popular open source database. It supports more than a basic relational SQL model, with robust graph and spatial database implementations.

It’s also my favourite database software, just so we’re clear on where my biases lie.

Yugabyte has taken these foundations and added a host of useful features on top, while retaining Postgres-like parity. It can distribute data widely, providing enhanced resilience and scale-out performance. It has built-in connection pooling. It supports the OpenID Connect (OIDC) protocol for authentication and a range of security enhancements like password strength checks and key rotation.

But Yugabyte noticed that some customers didn’t actually want a fully distributed database system, at least, not straight away.

“Some customers needed Yugabyte to behave the same as Postgres on smaller databases,” said Karthik Ranganathan, co-founder and CTO of Yugabyte. “Yugabyte looked mostly the same, but there were some differences.”

For example, some customers were used to low-latency access to a single database. Distributed databases have a host of benefits, but they come with trade-offs around latency of access, particularly for applications that aren’t designed with distributed data access in mind.

“Latency can be higher with distributed systems because they’re distributed,” said Ranganathan. “Co-located data access reduces the latency for applications that were built expecting the database to be nearby.”

This is why Yugabyte added a co-location feature that could turn off distributed access paths for customers that wanted Yugabyte to look more like a single-node Postgres installation. Customers still receive all the benefits of distributed data resilience, but database access happens close to where the application is deployed. For customers, it makes Yugabyte latency look more like the single Postgres database that their applications are expecting, which helps migrations go more smoothly.

Yugabyte has also added other features to make customers feel more at home. “We added read-committed, wait-for transaction semantics,” said Ranganathan. Subtle differences in transaction semantics and behaviour would sometimes require changes to applications moving to Yugabyte. Removing friction for these new customers was the driver behind the improvements.

Which highlights an important aspect of dealing with established enterprise organisations: they don’t really want to change much. What they have works. Moving from one approach to another already involves a lot of risk—IT projects tend to fail a lot—so the benefits of any change need to be substantial.

By reducing the amount of change required to get started, Yugabyte makes itself more attractive to people trying to get the benefits of distributed DBaaS without having to significantly rebuild their applications. This is no small feat.

Very close compatibility means lift-and-shift of existing databases is possible with lower risk. It helps organisations make the first of what are likely multiple changes as they adopt cloud systems.

Rather than requiring an organisation to rebuild their application and database before they can move, Yugabyte is trying to make the transition as seamless as possible. Greater compatibility will help customers to move things first and get some of the benefits immediately. Then, they can reinvest the savings into further improvements. It’s a more incremental, progressive approach to changes, and less of a “big bang” project that might fail catastrophically.

Which is what cloud operations are supposed to be all about: continuous deployment of incremental improvements. On reflection, it’s downright weird that established systems should need to change dramatically before they can even start migrating to a cloud approach. It feels like a failure of imagination or engineering skill from those asking customers to give up working and familiar systems for something new.

Yugabyte has built something that feels more like what we should be aiming for: a system that provides plenty of benefits for completely new builds, but that also offers a clear and (relatively) undemanding migration path for established, working systems.