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
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: YugabyteDB Anywhere, a management platform for building private YugabyteDB-as-a-Service offerings available via an annual subscription, and YugabyteDB Managed, a fully managed pay-as-you-go cloud service (currently in Beta). For starting your YugabyteDB Anywhere 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.
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.
- Main documentation start page — in particular, this links to
- Yugabyte Structured Query Language (YSQL)
- The two YSQL subsections, with lots of copy-and-paste ready SQL and PL/plSQL code examples, that I mentioned:
General, overview reading
- What is Distributed SQL?
- Distributed SQL vs. NewSQL
- Why We Built YugabyteDB by Reusing the PostgreSQL Query Layer
- Spanning the Globe without Google Spanner
- How Data Sharding Works in a Distributed SQL Database