Follow-up: Postgres Conference Webinar – Introduction to YugabyteDB

Technical Product Manager

May 18, 2020

I delivered the webinar “YugabyteDB: a distributed PostgreSQL database” last week. It was hosted by Postgres Conference in a series that they’d arranged so that the speakers who’d been selected to speak at their big annual conference in New York City in March could reach their audience. COVID-19 brought that event’s cancellation. This brief post tells you where you can find the edited videorecording and the PDF version of the slides that I used. It also gives me the chance to answer the couple of questions from attendees that shortness of time prevented me from answering during the webinar.

A big thank you to Postgres Conference

Before getting to the substance, I want to take this opportunity to thank the Postgres Conference, and in particular Joshua Drake and Lindsay Hooper, who organized the webinar series and my event.

Thanks also to all those participants who, after the webinar’s nominal finish, stayed on into extended time to join me for questions and answers.

Webinar recording and slides

Here is the recording.

Here are the slides that I used.

Answers to unanswered questions

Attendees submitted questions by chat during the webinar. Lindsay read out all but a couple of these questions when I was done with the fifty minute talk. I answered all of these during the next twenty-five minutes. Here are my answers to the remainder.

How do client programs connect to a YugabyteDB cluster?

The answer is indicated on slides #28 and #30. I wish I’d had time to explain this important notion carefully. A client program can connect to a YugabyteDB cluster in these three ways:

1. Using a standard PostgreSQL client driver without a load balancer. With this approach, the client explicitly specifies the particular node of the multi-node YugabyteDB cluster to which it connects. This brings perfect functionality because all YugabyteDB nodes are equivalent and each one can accept client requests for all the data in the cluster. (This honors the “no single point of failure” principle that I mentioned during the webinar.) The node that the client chooses will internally route the requests, collect the results, and respond to the client with the results. This approach might, though, have sub-optimal performance because other nodes in the cluster that could better take the load might be underutilized.

2. Using a standard PostgreSQL client driver with a load balancer. (Examples are HAProxy, NGINX, or a cloud-specific load balancer.) With this approach, the load balancer abstracts the cluster’s many nodes as a single IP address. The client connects to the load balancer and this, in turn, chooses which cluster node, among all of them, is the currently optimal connection destination. As of this post’s date, Yugabyte recommends this approach for production deployments.

3. Using YugabyteDB’s smart JDBC Driver. (This is currently Beta.) With this approach, no load balancer is needed because the driver itself is cluster aware. Even if a single node is specified as input, the driver automatically discovers the remaining nodes even as the cluster configuration changes with new nodes being added or existing nodes removed. Making the driver tablet aware is on the roadmap. This will ensure that the driver becomes even more efficient by directly connecting to the nodes that host the relevant tablets without any additional inter-node hops.

How is YugabyteDB priced?

Customers can choose from three offerings–the open source YugabyteDB and two commercial managed DBaaS solutions: Yugabyte Platform, a management platform for building private YugabyteDB-as-a-Service offerings available via an annual subscription, and Yugabyte Cloud, a fully managed pay-as-you-go cloud service (currently in Beta). For starting your Yugabyte Platform trial, please fill out the Contact Sales form on the website, along with information about your use case and details on both the read and write patterns of your application.

What’s next?

Join our Slack channel and star us on GitHub

Check out these other resources

One of my slides had the title “meta-meta-meta demo: SQL Feature Depth”. I very rapidly went to a couple of sections in the YugabyteDB documentation and to a list of my blog posts. Then I copied-and-pasted a few code examples into plsql and then ysqlsh. You saw (if you didn’t blink) that the outcomes in PostgreSQL and in YugabyteDB were identical. I encouraged you to try what I did in the comfort of your own homes. Doing so will convince you, far better than watching me do demos, that SQL and PL/pgSQL behave the same in the two environments. The links are listed, among the others, here.