Day 1

We’ve been trying to scale PostgreSQL since forever. What ways have people come up with? How do they work? Where is that now? Will review all known architectures, comment on ones that are no longer available and review ones that are still around and in use. Comments on scalability of various workloads, query consistency, ACID, BASE and other topics.

You’re woken up in the middle of the night to your phone. Your app is down and you’re on call to fix it. Eventually you track it down to “”something with the db,”” but what exactly is wrong? And of course, you’re sure that nothing changed recently.

Knowing what to fix, and even where to start looking, is a skill that takes a long time to develop. Especially since Postgres normally works very well for months at a time, not letting you get practice!

In this talk, I’ll share not only the more common failure cases and how to fix them, but also a general approach to efficiently figuring out what’s wrong in the first place.

The SQL standard is not standing still. SQL:2016 introduced the
latest round of features, and a new standard is expected in 2020.
What does that mean for PostgreSQL, the most SQL-conforming relational
database system?

Let’s take a look what new features recent SQL standard releases have
brought. One of the main features of SQL:2016 is JSON support.
PostgreSQL has been a leader of JSON support among relational
databases, and PostgreSQL 12 and beyond will bring the SQL standard
interfaces on top of existing JSON support. Other features in
SQL:2016 being considered for future PostgreSQL releases include
row-pattern recognition and several new functions and data types. A
number of new features are being worked on for SQL:2020, among which
graph database functionality is the most notable.

We’ll discuss some of these past and future features, the relationship
with other SQL implementations, the SQL standardization process and
adoption in PostgreSQL.

Have you ever encountered a transient performance issue, that was hard to
investigate only from the database point of view? On top of how many layers of
abstraction your database is working? What is the difference between running
your database on a bare metal, VM or inside a container?

PostgreSQL does not work in the vacuum, it heavily relies on functionality
provided by an underlying platform. And sometimes to answer these questions
above one needs to step back and look at a problem not only from a database
point of view. In this talk we will discuss how to achieve that, how to tame
such tools as strace, perf or eBPF to troubleshoot intricate issues and stay
curious.